The Most Common XSS Vulnerability in React.js Applications
People are often drawn towards using React.js thanks to the benefits of isomorphic (or universal) rendering. That is, the ability to render your single page application on the server-side, send the html to the client and have the client become interactive without having to re-rendering the entire page.
Now, you may look at that snippet and be unsure as to why there is a security issue.
Don’t worry, you’re not alone.
I recently had a conversation with Jimmy Jia in which I realised that I had accidentally exposed an application that I had worked on to an XSS Vulnerability — despite being a highly experienced software engineer with some security training.
What’s the issue, Em?
The issue with that code snippet is in how we pass the Store state into the application. In the above screenshot, we just do a
JSON.stringify call, and assign it to a global variable in a script tag. This is the vulnerability.
When a web browser parses the html of the page, and it encounters that
<script> tag, they will continue reading until they see
</script> — which means if your redux store has a value like the following in it, then when you load the client, you’ll receive an alert “You have an XSS vulnerability!”.
bio: "as</script><script>alert('You have an XSS vulnerability!')</script>"
The browser won’t actually read until the last curly bracket, instead, it will actually finish the script tag after
How can you prevent this XSS vulnerability?
- All user input should have HTML entities escaped. When you’re using React, it does prevent most XSS vulnerabilities, due to how it creates DOM Nodes and textual content.
- When serializing state on the server to be sent to the client, you need to serialize in a way that escapes HTML entities. This is because you’re often no longer using React to create this string, hence not having the string automatically escaped.
First install the module with:
Then we can change the snippet from earlier to look like the following; In particular notice the change where we use
serialize instead of
JSON.stringify when assigning the value to
As for receiving the data on the client-side, it works just the same as before, excepting that you now just have any HTML Entities in the string escaped (they’ll look like:
\\u003C\\u002Fscript\\u003E rather than as
Remember: Just because you’re building an application with the latest technology on the market, or technology that is used by Facebook, you still have to take care of all the standard security practices you would, if you were writing an application with a Rails, Django, PHP, or older stack.
This article has been translated into Traditional Chinese by Wendell Liu.
This post was produced with the help of a conversation with Jimmy Jia who first revealed this vulnerability to me — I had originally thought the browser worked differently and was aware of content in script tags).