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.
Can CSS from the user do any harm?
The number 3 in the OWASP Top Ten web application vulnerabilities
CSP is a great way to reduce or completely remove the number 1 web app security vulnerability – Cross-Site Scripting (XSS).
How does Rails’ XSS protection work exactly
A Cross Site Scripting cheat sheet by the Open web application security project
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 %>
- 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
- 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