Cross-Site Scripting (XSS) in Rails

XSS allows an attacker to execute scripts in the security context of your web application. The OWASP Top 10 of most frequent vulnerabilities lists it as #3, with other types of injection on #1 now.

CSS Injection in Rails

Can CSS from the user do any harm?

What is Cross Site Scripting (XSS)?

The number 3 in the OWASP Top Ten web application vulnerabilities

Countermeasures

A Content Security Policy (CSP) strategy

CSP is a great way to reduce or completely remove the number 1 web app security vulnerability – Cross-Site Scripting (XSS).

HTML-safe, ActiveSupport::SafeBuffer explained

How does Rails’ XSS protection work exactly

OWASP XSS Prevention Cheat Sheet

A Cross Site Scripting cheat sheet by the Open web application security project

XSS protection in Haml templates

Haml templates support Rails’ XSS protection

Rails’ auto-escaping automatically uses the h() method to escape “unsafe” data. Don’t do the following (unless you’re absolutely sure):

  • <%= raw @flat.name %>
  • <%= @flat.name.html_safe %>

Configuration

Advanced

    • Implement a Content Security Policy (CSP)
      Primarily, CSP is a set of rules to tell the browser from what source scripts may be executed and thus the browser will not execute scripts from other sources. That means you can reduce the number of Cross-Site Scripting (XSS) vectors by, for example, disallowing scripts from other domains or inline scripts. The whitelist rules are defined server-side in the Content-Security-Policy HTTP header. More about Rails and CSP here.
    • DOM-based XSS