Server-Side Controls Stop at the Browser
Developers create PRs with review and security testing. Servers get antivirus, data loss protection, and strict access controls. Organizations know what code runs on the server. Then the page reaches the browser. Third-party JavaScript dependencies pull in code dynamically at runtime. The server-side pipeline has no visibility into what runs in the client. Attackers exploit this gap by targeting third-party vendors instead of hardened server infrastructure.
Third-Party JavaScript by the Numbers
The Web Almanac surveyed millions of websites. The median desktop page loads 680 KB of JavaScript. 98.1% of pages use JavaScript. JavaScript is the number one resource requested from third parties, beating images. The top 1,000 sites make over 100 third-party requests per page. Attackers target these dependencies because compromising a small vendor is easier than breaching a major bank. The Bybit exchange lost $1.46 billion through a few lines of injected JavaScript.
CSP Report-Only Mode Turns the Browser Into an Auditor
Deploy Content Security Policy in report-only mode. No risk of breaking pages. Declare scripts unsafe-inline. The browser reports every JavaScript dependency it finds. It sends JSON payloads listing each script URL. Collect the reports for an hour. The result is a complete inventory of first-party, third-party, and fourth-party dependencies. Add the report-uri or report-to directive to receive the data. CSP delivers 90% of its value with 5% of the work.
SRI and Integrity Policy Pin Static Files to Known Hashes
Subresource Integrity locks a script tag to a cryptographic hash. The browser fetches the file, hashes it, and compares. If the file changed, the hash mismatches and the browser blocks execution. For static third-party dependencies, this is the highest-value defense. Integrity Policy then monitors whether every suitable script tag has SRI. Deploy it in report-only mode. Any script tag without an integrity attribute triggers a report. The browser does the auditing automatically.
Signature-Based SRI Extends Protection to Dynamic Dependencies
Standard SRI requires static files. Signature-based SRI embeds the vendor’s public key in the script tag. The vendor signs each JavaScript file at build time. The browser verifies the signature on every load. If an attacker modifies the file in the S3 bucket, the signature fails. This standard is nearly finished and testable in Chrome Canary. Connection Allow List, a further future standard, will block all unauthorized outbound communications from the page.
Q&A
How do I avoid getting flooded with CSP telemetry on a high-traffic site? Inject the response header on a down-sampled fraction of responses, such as one in a thousand or one in fifty thousand. ▶ Watch (51:03)
Can third-party scripts be isolated from the DOM using sandboxes? Push the script into an iframe with the sandbox attribute so it cannot reach back into the parent context. ▶ Watch (52:13)
If I hash a file for SRI and it is already infected, have I locked in malware? Set the current state as the baseline and monitor for changes going forward. Reviewing all third-party code is impractical. ▶ Watch (53:31)
Does signature-based SRI require significant effort from JavaScript vendors? Vendors only need to sign at build time when the file changes. It is a one-off process that does not affect caching. ▶ Watch (55:28)
Notable Quotes
the median webpage for desktop browsers last year was loading 680 kilobytes of JavaScript alone Scott Helme · ▶ Watch (5:22)
98.1% of them are using JavaScript. Scott Helme · ▶ Watch (6:17)
They lost 1.46 billion dollars of cryptocurrency Scott Helme · ▶ Watch (14:47)
this is the first insight that you’re going to have that somebody else just did a code change on your site and deployed it and it probably didn’t go through any of your processes Scott Helme · ▶ Watch (29:43)
Key Takeaways
- Deploy CSP in report-only mode to inventory all client-side JavaScript dependencies without risk.
- Add SRI hashes to every static third-party script tag to block tampered files from executing.
- Monitor hash changes through CSP report-SHA-256 to detect unauthorized code deployments in production.
About the Speaker
Scott Helme is a security researcher, consultant and international speaker. He can often be found talking about web security and performance online and helping organisations better deploy both. Founder of report-uri.com, a free CSP report collection service, and securityheaders.com, a free security analyser, Scott has a tendency to always be involved in building something new and exciting.