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.
[portfolio display_types=false display_tags=false display_content=true columns=3 showposts=3 orderby=title include_tag=xss-intro]
Countermeasures
[portfolio display_types=false display_tags=false display_content=true columns=3 showposts=6 orderby=title include_tag=xss-countermeasures]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)
