We learned from the previous chapters that Cross-site scripting (XSS) is a security vulnerability that allows an attacker to inject custom JavaScript code into the content that an application delivers to a user. The severity of an XSS attack is critical when the attacker can steal our users' cookies using the injected script. With those cookies, the attacker can login to the victim's account without their knowledge. XSS-based cookie theft can be prevented by disallowing JavaScript to read cookies. We will discuss that in the next section. Even though preventing all XSS flaws in an application is difficult, modern frameworks like `React` have some built-in goodies that can help us in the mitigation process. For example `React` automatically performs HTML encoding to strings before rendering it to the page. This ensures that the special characters are treated just like normal text, instead of a piece of script to be executed. Also, from the developers' perspective, it makes us think twice before using functions like `dangerouslySetInnerHTML`. In this chapter let's learn what all measures we can take to mitigate classic XSS attacks. ## Do not allow JavaScript to read cookie information As discussed in the cookie section if a cookie is marked as [HttpOnly](https://www.owasp.org/index.php/HttpOnly) then JavaScript can't read cookie information. This diminishes the potential severity of XSS attacks by keeping the authentication token safe. Since XSS can do more than just stealing cookies, this alone won't make our users fully safe against XSS. Open `config/initializers/session_store.rb` and you will see code something like this: ```ruby Rails.application.config.session_store :cookie_store, key: "xxxxxxxx" ``` Let's add `httponly` option to this application: ```ruby Rails.application.config.session_store :cookie_store, key: "xxxxxxxx", httponly: true ``` Now the cookies can't be read by any JavaScript code. ## Do not allow hacker to execute JavaScript If a hacker is able to execute custom JavaScript code then hacker can steal cookies. There is only one way to prevent it and that is to not allow users of the application to send `
Suite #110
Miami
FL
33027
USA ``` Notice that in this case no JavaScript alert was seen. Hacker gets to see the address hacker had posted. Why is that. To answer that let’s look at the html markup: ```html John Smith<br /><script>alert(document.cookie)</script>< br />Suite #110<br />Miami<br />FL<br />33027<br />USA ``` As we can see Rails did not render the address exactly as it was posted by the hacker. Rails did something because of which `

Mitigating XSS when cookies are used