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
- Use the HTTPOnly cookie flag for session cookies (default in Rails) and for other cookies. More about the HTTPOnly cookie in Rails.
- Send the X-XSS-Protection Response Header
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
- Implement a Content Security Policy (CSP)
