CSP require-sri-for指令的防护作用及未启用时的风险技术咨询

Hey there, great questions—let’s unpack these about CSP’s require-sri-for directive clearly.

This directive enforces that all external scripts and stylesheets on your page must include a valid Subresource Integrity (SRI) attribute. It primarily guards against:

• Maliciously modified third-party resources: If a CDN or external host you trust gets compromised (e.g., a popular jQuery CDN is hacked to serve malware instead of the legitimate library), SRI ensures the browser only executes the resource if its hash matches the one specified in your page’s integrity attribute. require-sri-for makes this check mandatory, so you can’t accidentally skip adding SRI to critical resources.
• Man-in-the-Middle (MitM) attacks: Attackers intercepting traffic between the user and your server could swap legitimate scripts/styles with malicious versions. Without SRI, the browser would load and execute the tampered files. With require-sri-for enabled, the hash mismatch blocks execution.
• Cache poisoning attacks: If an attacker manages to poison a user’s browser cache (or a shared proxy cache) with modified versions of your site’s resources, SRI will prevent the browser from using those corrupted files—even if they appear to come from a trusted source.

Your confusion here is totally valid—let’s break down the scenarios where this directive stops attacks that would succeed otherwise:

First, remember: require-sri-for only applies to external resources (scripts/styles loaded via src). It doesn’t affect inline scripts (those are controlled by CSP’s unsafe-inline or nonce/hash rules).

Now, the key scenarios where require-sri-for blocks attacks:

Scenario 1: Tampering with existing trusted resources #

Suppose your site includes <script src="/app.js"></script> without an integrity attribute. An attacker uses a cache poisoning or MitM attack to replace /app.js with malicious code. Without require-sri-for, the browser loads and runs the tampered script.

With require-sri-for enabled, this script tag is invalid (no integrity attribute), so the CSP blocks it from loading entirely. The attacker can’t inject an integrity attribute here because they don’t control the original script tag—they’re only modifying the resource content, not the HTML of your page.

Scenario 2: Exploiting loose CSP rules without controlled resources #

Let’s say your site’s CSP allows script-src 'self' trusted-cdn.com, but you forgot to add SRI to resources from trusted-cdn.com. If trusted-cdn.com gets hacked, attackers can serve modified scripts that your browser would normally load.

require-sri-for forces you to add SRI to all external scripts, so even if the CDN is compromised, the hash mismatch stops the malicious code from running. Attackers can’t inject a fake integrity attribute for the modified script because they don’t have access to edit your page’s HTML—they only control the CDN’s content.

What about attackers who can inject script tags? #

If an attacker has full XSS access to inject arbitrary script tags into your page, yes—they could theoretically add a script tag pointing to their own malicious resource, plus an integrity attribute with the hash of that resource. But this only works if your CSP’s script-src allows the attacker’s domain (which is a separate issue).

In most secure setups, script-src is restricted to trusted domains (like 'self' and known CDNs), so the attacker’s malicious domain would be blocked by CSP regardless of SRI. require-sri-for isn’t meant to fix overly permissive CSP rules—it adds an extra layer of protection for resources you do trust.

内容的提问来源于stack exchange，提问作者Anders