4 ms·

Let me get this straight. The issue here is " Server side code is passing user inputted data --without sanitizing it-- for further use, which in this case is f

• pornel 9y ago
  No, it's "server-side does proper sanitization for server-side rendering" and "client does proper sanitization for client-side rendering", but when both are combined, they allow XSS, because server-side-rendered page is re-interpreted as a client-side template. The flaw is not immediately obvious, because each renderer is safe in isolation.
  • zaarn 9y ago
    I would interpret that as a server-side render being improperly sanitized since obviously data from the server is being wrongfully executed. So that means either the server has to properly escape data or take additional steps to isolate data and code.
  • rk06 9y ago
    I don't agree with it. Server knows that it is passing data for Vue templates, not html. So, it can't be considered safe in isolation. PS: I see that the article is informative. as I was not aware of such exploits. However, the headline is too clickbait-y.
• bastawhiz 9y ago
  It took me a minute to understand why this is happening, but it comes down to this: everything is escaped properly, but the Vue.js component is defined _in the HTML_. By injecting anything at all inside the component's markup, you're modifying the component's source code rather than modifying inputs to it. Even if you're using a perfectly well-built HTML escape function, the user can then write code that gets parsed and executed because it's part of the component's source template. Edit: A better approach here would have been to compile the component into a JS file and load it separately from the page itself, then pulling user input from a global variable or data attribute somewhere in the page. The same attack could conceivably be carried out on React if you're building your components inline (albeit sans-JSX) and injecting user input into the raw <script> source.