Script Vault

We don't just record the URL. We keep the code.

When a browser on your site executes a script, it reports the file's cryptographic fingerprint. We fetch that file, hash it ourselves, and keep it only if the bytes match — so what ends up in the vault is provably the code your visitor ran, retrievable months later.

Start Free Trial Documentation →
What's at Stake

The evidence you need after an incident stops existing the moment it matters.

An inventory of script URLs is a list of addresses. When something goes wrong, the question is never “which addresses did we load?” — it is “what was actually in that file on Tuesday?” By the time anyone asks, the origin is serving something else, the compromised version has been pulled, and the only copies that ever existed were in the browsers of the people affected. Fetching the URL now tells you what the vendor is serving today, which is precisely the thing you already know.

Gone by Morning

Malicious code doesn't stay up to be examined

An injected payload is typically live for hours and removed as soon as it is noticed — often by the attacker. Whatever you did not capture while it was running is not recoverable afterwards from the source.

Unprovable Copies

A file you downloaded proves nothing on its own

Anyone can fetch a URL and save the result. That copy shows what the origin served to that request, from that network, at that moment — not what a customer's browser actually executed on your checkout page.

Unanswerable Questions

“What was in that version?” ends the investigation

Assessors, insurers and incident responders all converge on the same question, and without the artefact the answer is reconstruction and inference. That is a materially weaker position than holding the file.

What Script Vault Does

Fetched, verified against the browser, and kept

Report URI already receives a cryptographic fingerprint of every script your visitors execute. Script Vault turns that fingerprint into a retrievable copy of the file behind it.

Hash-Verified Capture

Kept only when the bytes match what ran

The browser tells us the hash of the script it executed. We fetch that URL, hash what we receive, and compare. A match means the file we hold is byte-for-byte the code your visitor ran, and we keep it. A mismatch means the origin is serving something different from what browsers are reporting, and we do not pretend otherwise.

Learn more about CSP Integrity →
Retrieval

Download the exact file, long after it stopped being served

Where a copy is held, the report carries a download link. That is the artefact an investigation actually needs: not a description of what changed, not a diff against a version you assume was there, but the file itself, tied to the fingerprint a real browser reported.

Learn more about Script Watch →
Identified, Not Just Stored

Named libraries and known vulnerabilities

Each fingerprint is checked against a database of nearly thirteen million verified JavaScript files, so an archived copy usually arrives already named by library and version. Where that version carries a published advisory, the report says so — which turns a stored file into an answer rather than a research task.

Learn more about JavaScript Integrity Monitoring →
Get Started

Keep the code, not just the address. Before you need it.

One keyword on your policy. 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

How It Works

From executed script to archived artefact

Every step is driven by what real browsers report, and the archive is deliberately conservative — a copy is only kept when it can be proved to be the right one.

Step What happens
A visitor loads your page The browser computes a hash of each script it executes and reports it
The fingerprint arrives A hash we have already archived is recognised and costs nothing further
A new fingerprint is queued Only fingerprints we do not already hold are candidates for a fetch
We fetch the file Retrieved out of band, from our infrastructure, never through your visitors
We re-hash what we received Compared against the hash the browser reported
Match The file is archived against that fingerprint and made available to download
Mismatch Nothing is stored, and the pair is held back rather than retried in a loop
Architecture

One keyword. No code. Nothing in the path.

The vault is fed by CSP Integrity, which is a browser capability driven by a keyword in your Content Security Policy. Your scripts are never routed through us — the browser reports a fingerprint, and the fetch happens separately, from our infrastructure, with no effect on the page your visitor is loading.

You don't need an existing CSP. A report-only header carrying just the keyword is enough to start.

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. 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

Your scripts are never routed through us

Fetching happens out of band, not during a page load

Your site's performance is unaffected

Covers third-party code from any origin your pages load

PCI DSS 6.4.3

An inventory you can produce the artefacts for

Requirement 6.4.3 asks that payment page scripts are authorised, that their integrity is assured, and that they are inventoried. An inventory of URLs satisfies the letter of the third element. An inventory where each entry is backed by the verified file it refers to is a materially stronger artefact, and it is the one that survives a question about a specific date.

Authorisation comes from your policy, change detection from Script Watch, and 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.

Script Vault holds the code. Knowing when the set of scripts changes, deciding what is allowed to run, and requiring integrity metadata are separate jobs handled alongside it.

Script Vault does Pairs with
Keeps verified copies of executed scripts CSP Integrity for the fingerprints that feed it
Names the library and flags advisories JavaScript Integrity Monitoring for change detection
Provides the artefact after an incident Script Watch for the inventory and the alert
Backs an inventory with real files Integrity Policy for enforcing SRI coverage

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