CSP Integrity

You know which scripts load. This tells you what code.

A URL tells you where a script came from, not what it contained. CSP Integrity has the browser fingerprint every script it executes and report the hash back — so you can identify the exact file, name the library and version, and check it against known vulnerabilities.

Start Free Trial Documentation →
What's at Stake

A script inventory made of URLs tells you addresses, not contents.

Knowing that your checkout loads a file from a particular CDN is useful. It is not the same as knowing which version of which library that file actually is, whether it matches what the vendor published, or whether the copy your visitors received last night is the copy you reviewed last quarter. The same URL can serve different bytes to different people at different times, and from the outside every one of those requests looks identical.

Same URL, Different File

A stable address says nothing about stable content

Vendors ship updates to the same path. CDNs serve regional variants. A compromised host can return modified code to a fraction of visitors. Monitoring the URL cannot distinguish any of these from business as usual, because the URL never changed.

Unidentified Dependencies

You can't patch a library you can't name

Third-party scripts arrive minified, bundled and renamed, and they bring dependencies of their own. When an advisory lands for a specific version of a specific library, answering “are we running it?” means reading files by hand — assuming you can work out which files to read.

Point-in-Time Checks

What you audited isn't what your users ran

Fetching a script yourself tells you what the server gave you, from your network, at that moment. It says nothing about what executed in a customer's browser in another country, behind a login, on a page you never tested.

What CSP Integrity Does

Cryptographic fingerprints, reported by the browser that ran the code

Add one keyword to your policy and browsers begin reporting a SHA-256 hash of every script they execute. Report URI identifies the file behind each fingerprint, names the library, and checks it for known vulnerabilities.

Script Fingerprinting

A hash of exactly what executed, from the client that executed it

The 'report-sha256' keyword tells the browser to compute an integrity hash for each script it runs and send it to your reporting endpoint. This is the file your visitor actually received — after any CDN, any proxy, any regional variation — rather than the file your build server believes it published.

Learn more about CSP Integrity →
Verified Files

Nearly 13 million fingerprints, matched by name and version

Each reported hash is checked against our database of verified JavaScript files. A match names the library and version, so your third-party inventory reads as software rather than as URLs — and a file presenting itself as one library while fingerprinting as another becomes immediately obvious. Where we hold an archived copy, you can download the exact file that was reported.

Learn more about JavaScript Integrity Monitoring →
Vulnerability Matching

Told when a script you're running has a known issue

Once a file is identified we search a database of known JavaScript vulnerabilities against it. If your pages are executing a version with a published advisory the report is flagged, links through to the source of the vulnerability information, and points at the version that resolves it — turning “are we affected?” from a research task into a page you can already look at.

Learn more about Threat Intelligence →
Get Started

Stop inventorying URLs. Start identifying files.

One keyword. No code. Fingerprints start arriving from your first visitor.

Start Free Trial Talk to our team →

30-day free trial  ·  One keyword  ·  No code  ·  Cancel anytime

Detection

What a fingerprint tells you that a URL cannot

Integrity metadata turns each script from an address into an identified artefact, which changes the questions you are able to answer about your own site.

Reported What it tells you
SHA-256 fingerprint The exact bytes that executed in a real visitor's browser
Verified match The library and version behind the hash, named rather than guessed
Name mismatch A file presenting as one library while fingerprinting as another
Unrecognised fingerprint A file we hold no record of — bespoke, very new, or worth a look
Vulnerability flag An identified file with a published advisory against its version
Archived copy The precise file that matched, retrievable for audit after the fact

Dynamically-generated scripts whose content changes on every request can't be archived, and a very new library may not be in the database yet — an unrecognised fingerprint is a prompt to look, not a verdict.

Architecture

One keyword. No code. No crawlers.

CSP Integrity is a browser capability, driven by a keyword in your Content Security Policy. The browser hashes what it runs and reports it over the Reporting API. Nothing of ours executes on your pages, and the telemetry describes real sessions rather than a crawl.

You don't need an existing CSP. A report-only header carrying just the keyword is enough to start collecting fingerprints, and it blocks nothing.

Minimal setup — no existing CSP
Content-Security-Policy-Report-Only: script-src 'report-sha256';
  report-to default

Already running a policy? Add 'report-sha256' to your existing script-src directive. Either way you will need a Report-To group pointing at your Report URI endpoint — the exact header is on your Setup page.

No code added to your pages

No crawler fetching your scripts

Report-only mode blocks nothing while you collect

Your site's performance is unaffected

Fingerprints what real users ran — authenticated pages, regional variants, A/B tests

PCI DSS 6.4.3

CSP Integrity and script integrity assurance

PCI DSS 4.0.1 Requirement 6.4.3 asks three things of every payment page script: that it is authorised, that its integrity is assured, and that it is inventoried with a written justification. Subresource Integrity is the mechanism the standard's guidance names first for the integrity element — and CSP Integrity is how you find out whether it is genuinely in place, by reporting a fingerprint for every script that runs whether or not anyone remembered to put a hash on the tag.

Authorisation comes from your policy and inventory from Script Watch; the wider evidence layer is set out on the PCI DSS Compliance page.

PCI DSS Compliance →
Scope

One layer in the stack. Here's how it fits.

CSP Integrity identifies the files running on your site. It does not decide what is allowed to load, and it does not require that every script carries a hash — it is the identification layer, and it works alongside the rest.

CSP Integrity does Pairs with
Fingerprints every script that executes Script Watch for inventory and change detection — knowing when the set of scripts moves
Identifies files by library and version Integrity Policy for enforcement — requiring that scripts carry integrity metadata at all
Flags known vulnerabilities Threat Intelligence for IoC matching — identifying known malicious sources
Archives the exact file reported CSP for policy control — deciding what may execute in the first place

Together, these form the client-side security visibility layer that sits between your CSP policy and your incident response process.