What does an external `<script>` element's `integrity` attribute add when the Content-Security-Policy already allows that third-party host?

## What an allowlist settles, and what it leaves open A `Content-Security-Policy` source list answers exactly one question: **which origins may this document fetch script from**. Once `script-src` names the widget vendor's host, every file that host serves is permitted — the build you reviewed, tomorrow's build, and anything an attacker who reaches that host publishes in between. An allowlisted third party is still a third party. On a long-lived classified-ads marketplace that embeds a shared listings widget from a host it does not control, the policy is the wrong instrument for the risk that actually matters: not *where* the bytes came from, but *which* bytes arrived. **Subresource Integrity** answers that second question. On an external `<script>` or `<link>` element you add an `integrity` content attribute holding one or more digests of the exact file you tested. The fetch proceeds normally; before the response is used, a conforming browser computes the digest of the **raw response body** and compares it against the metadata. A match lets the script execute or the stylesheet apply. No match, and the load fails. ## What goes in the attribute - The value is a whitespace-separated list of **hash-with-options** entries. - Each entry is a **hash-expression**: a `hash-algorithm` token, a literal `-`, and a `base64-value` encoded per `RFC 4648`. - The valid algorithm tokens are `sha256`, `sha384` and `sha512`. - An **option-expression** may follow a `?`. Options are reserved, and one a client does not recognise is ignored rather than treated as an error. - The digest covers the bytes that arrived — not source you wrote, not a normalised or minified form, and not the URL. One disambiguation is worth making early, because both things get called "the hash" and they are not the same. A CSP `hash-source` written inside a `script-src` — a token shaped like `'sha256-…'` — is computed over the UTF-8 encoding of an **inline** element's text. An `integrity` value is computed over the fetched bytes of an **external** resource. Different inputs, different values, even for content that looks identical. ## What a mismatch produces A mismatch is a **network error**, not a warning and not an unverified load. The element takes its error path: a `<script>` does not execute, a stylesheet is not applied, and nothing partially-verified reaches the document. That is the point — a pinned file either is the file you approved or is absent — and it is also the trade you are accepting. Pinning a third-party asset means the feature disappears the moment the vendor ships a new build, so the page has to survive the widget not being there. The diagnostic trap follows from the same fact: because the failure is shaped like a failed fetch, a widget that vanishes the day the vendor rebuilds looks exactly like the vendor's host being down. ## Where the guarantee can be attached | the question | what answers it | |---|---| | where may this script come from | the policy's source list | | which bytes are acceptable | the `integrity` attribute | | may the response be read at all | the CORS grant the `crossorigin` attribute asks for | The attribute is not limited to `<script src>`. A `<link>` element that pulls a stylesheet takes it, as does a `<link>` that preloads a resource, and integrity metadata can also travel on a `Link` **response header** alongside `rel=preload` — so the requirement can be attached to a preloaded file before any markup naming it has been parsed. ## What it does not give you 1. **It does not say who served the bytes.** It says what the bytes are. A file delivered by an entirely different host passes if its digest matches, and a file from the legitimate host fails if it does not. Authenticating the peer is the connection's job. 2. **It does not make a file safe.** A digest of a compromised build is honoured just as faithfully as a digest of a good one. The attribute pins content to a decision you made; it does not make the decision. 3. **It cannot pin what you cannot predict.** Anything generated per request, or served from a URL the vendor mutates in place, has no stable digest to pin. 4. **It is opt-in, element by element.** One `<script>` tag that ships without the attribute quietly reverts that subresource to origin-only trust, and the page looks perfectly healthy either way. It is also a different guarantee from the integrity fields in a dependency manifest. Those are a **build-time** property of a resolved dependency graph, verified by the installer before code reaches your artifact. This one is verified by the client at **fetch time**, on a file that was never in your build at all — which is exactly why a third-party widget needs it.