The power of guardrails: How to slash your risk of XSS in half

Colleen Dai and Grayson Hardaway from R2C open with the problem that application security teams often face a hundred or more developers per security engineer, so chasing individual bugs through testing and bounties does not scale. They argue for secure guardrails: frameworks and enforced coding patterns that make the safe choice the easy one and remove whole bug classes. They point to practices at several large companies as support for this approach.

To test the idea, the team focused on cross-site scripting, chosen for its impact and for the concrete, framework-specific mitigations it has. They wrote Semgrep rules covering Java and JSP, Python Flask and Django, JavaScript, Express, React, Go, and Ruby on Rails, then gathered roughly 140 real XSS fix commits from open source repositories. The rules were run against each fix's parent commit, and the results were triaged by hand. The rules flagged about 59 percent of the cases. Most misses involved HTML assembled inside JavaScript template strings, and dangerouslySetInnerHTML accounted for a large share of the React findings.

The speakers' takeaways include restricting dangerous output sinks, since a few simple checks covered much of the client-side risk, and recognizing that some technologies such as JSP provide no escaping by default. Their suggested process is to choose one vulnerability class, define safe patterns with alternatives, train developers, and enforce the patterns automatically through CI or pre-commit hooks. The rules and policies were released publicly.