AI
Why XSS and CSRF Keep Surviving
XSS sits at number one on HackerOne’s most-rewarded vulnerability list. CSRF and clickjacking follow. These bugs persist for two reasons: teams stay reactive, fixing the report that just landed rather than the root cause, and browsers cannot retroactively secure the web without breaking backward compatibility. Most modern browser defenses are opt-in. Developers must know they exist and choose to use them. The OWASP Proactive Controls 2024 added a new entry, number eight, specifically to address this: leverage browser security features.
Measuring Browser Security Adoption at Scale
Google published a study on how they measured browser security header adoption across hundreds of internal services. Their approach: inspect traffic at the reverse proxy layer, checking passively for signals like whether a strict CSP is present, whether Trusted Types are enabled, and whether the app uses a modern framework with output encoding by default. Each service gets a scorecard. Gmail ran this at scale and reduced XSS bug bounty reports to zero. Google then raised the XSS reward to $50,000, a signal of how confident a strict CSP makes them.
Blocking CSRF at the Proxy Layer
Sec-Fetch-Metadata is a set of request headers the browser adds automatically: Sec-Fetch-Site, Sec-Fetch-Mode, and Sec-Fetch-Destination. When a user opens example.com directly in the browser, the browser reports same-origin. When evil.example loads an image tag pointing at your API endpoint, the browser reports cross-site. One if statement in Nginx or Node.js reads that header and blocks the request. Older browsers that don’t send the header get no protection, which is fine. CSRF attacks happen in browsers, not terminals. The protection costs one line of code at the proxy level.
Why Most Content Security Policies Are Bypassable
A Content Security Policy is an allow-list delivered as a response header, telling the browser which scripts, images, and URLs to load. The problem: most CSPs allow CDN domains, which makes them bypassable. The tool cspbypass.com takes any CSP, finds CDN endpoints that host JSONP callbacks or Angular libraries, and returns ready-to-use XSS payloads. OWASP.org’s own CSP, shown in the talk, lists YouTube, GitHub, and Font Awesome, all bypassable. A strict CSP replaces domain allow-lists with nonces or integrity hashes on each script tag. That removes the CDN bypass entirely.
Centralizing DOM Sanitization with Trusted Types
Trusted Types, added to Chrome in 2020, intercepts dangerous DOM APIs: innerHTML, outerHTML, and document.write. Without it, any developer on the team can assign unsanitized HTML to those APIs and introduce DOM-based XSS. With it, you define a central policy that overrides those APIs. One approach: wrap every assignment through DOMPurify, a library that strips dangerous event handlers and JavaScript from HTML. Another: block innerHTML entirely at the browser level, forcing developers toward textContent. Firefox is implementing Trusted Types now; a polyfill covers it in the meantime.
The Evolving Browser Security Stack
The browser security stack keeps expanding. Mozilla announced a new Integrity Policy response header in July, a hash of each third-party file included in a page. If the file changes, the browser blocks it. That directly prevents supply chain attacks like the polyfills.io takeover from 2024. The reporting API is also changing: the old report-uri directive is deprecated, replaced by Reporting-Endpoints, which collects CSP violations, integrity failures, and other signals in one place. Both headers ship with report-only mode, so teams can collect data before enforcement.
Q&A
How can Sec-Fetch-Metadata be used to selectively allow cross-site resources such as images? Filter by the Sec-Fetch-Destination type in your if statement, passing image requests through while blocking document or script requests from cross-site origins. ▶ 34:32
Does Sec-Fetch-Metadata expose the specific domain making the request? No, it reports the site relationship (same-origin or cross-site) but not the requesting domain; the referrer header may carry that, if present. ▶ 35:21
How do you handle the flood of violations when deploying a strict CSP in report-only mode? Partial collection is enough; violations are repetitive, so running report-only on a lower environment with QA traffic finds the code paths that need changes without overwhelming production logging. ▶ 39:07
Should the CSP reporting endpoint be part of the main application? Run it as a separate service that can be toggled off independently, and apply a hard rate limit to control costs since the endpoint itself is not required to serve the site. ▶ 41:43
Notable Quotes
We don’t care. They just don’t profit Javan Rasokat · ▶ 14:24
you’re basically bypassable Javan Rasokat · ▶ 20:07
this web security is increasingly opt-in Javan Rasokat · ▶ 31:37
Key Takeaways
- Sec-Fetch-Metadata headers block CSRF at the proxy with one if statement and no token required.
- Domain allow-list CSPs are bypassable through CDN endpoints; only nonce-based strict CSPs hold.
- Trusted Types centralizes DOM sanitization in one policy, removing DOM-based XSS without a full rewrite.
About the Speaker(s)
Javan Rasokat is a Senior Application Security Specialist at Sage, where he joined six years ago to lead Product Security for Central Europe and now supports products globally, contributing to the standardization of security controls. He discovered his passion for security early in his career after identifying and reporting vulnerabilities as a full-stack web and mobile engineer, which led to his first security consulting role before he held any certifications.