report-sha256, report-sha384, report-sha512 in CSP

Saturday, February 21, 2026

5 min read

The 'report-sha256', 'report-sha384', and 'report-sha512' keywords in CSP script directives tell the browser to send reports with the script’s SHA hash when scripts are loaded. This helps you easily see which scripts run and use the hashes to build allowlists. CentralCSP uses these reports for visibility, vulnerability detection, and alerting.

What Are report-sha256, report-sha384, report-sha512?

In CSP, script-src and script-src-elem can include one or more of these keywords:

'report-sha256' : send a report and include a SHA-256 hash
'report-sha384' : send a report and include a SHA-384 hash
'report-sha512' : send a report and include a SHA-512 hash

Example of the report-sha256 report format

{
  "destination": "script",
  "documentURL": "https://mywebsite.com/",
  "hash": "sha256-r2hRGID3tnFVlAI+bMCPMjaKx/ovuqgaMic09dPqVCw=",
  "subresourceURL": "https://mywebsite.com/my_script.js",
  "type": "subresource"
}

report-shaXXX does not allow or block scripts; it only tells the browser to send a report to the reporting endpoint when a script is loaded on the page
Use with report-to or report-uri so reports are sent to your endpoint (e.g. CentralCSP)
For external scripts, use crossorigin="anonymous" on the script tag so the browser can compute and include the hash in reports

You can use report-only mode to collect real hashes from your site, then add them to your enforce policy. When a script is blocked, the report tells you the exact hash that would allow it.

Purpose and benefits

Build a script inventory : Reports collected allow you to build a list of scripts that run on your site and their hashes.
Script inventory and compliance : CentralCSP uses these reports to build a Script Inventory of what runs on your site and to correlate with CVE data and alerting. Hash data in reports makes that correlation accurate.
Security and monitoring : You can detect malicious or unexpected scripts and new dependencies by monitoring reports that include script hashes.

CentralCSP and report-shaXXX

CentralCSP ingests CSP violation and subresource reports. When your policy uses 'report-sha256', 'report-sha384', or 'report-sha512', the reports CentralCSP receives can include script hashes. CentralCSP can:

Process script hash reports : Store and display which scripts were loaded or blocked and their hashes, so you can decide what to allow.
Correlate with CVE detection : Match scripts (by URL, hash, or other identifiers) against known vulnerabilities and surface CVE-related findings.
Trigger alerting : Alerting can notify you when specific scripts are blocked, when new hashes appear, or when a CVE is associated with a script in your Script Inventory.

Together, report-shaXXX and CentralCSP give you script-level visibility and vulnerability management instead of only high-level violation counts.

Syntax and reporting

Using report-sha256 in script-src with report-to

Content-Security-Policy: script-src 'self' 'report-sha256'; report-to csp-endpoint;

You must also set a Reporting-Endpoints header (or use report-uri) so the browser knows where to send the reports. The CSP directive then references the endpoint with report-to <name> or report-uri <url>.

Why crossorigin="anonymous" matters for hashes in reports

For external scripts, the browser can only compute and include the resource's hash in a report if the request was made in a CORS mode. Otherwise the browser may not have access to the response body needed to compute the hash.

Add crossorigin="anonymous" (or crossorigin="use-credentials") to <script> tags that load from another origin.
That triggers a CORS request so the browser can verify Subresource Integrity and, when report-shaXXX is used, include the hash in the report.

Without crossorigin, reports for external scripts may omit the hash field. The same requirement applies when using sha-XXX allowlist values for external resources.

External script with crossorigin so the browser can include its hash in reports

<script
src="https://cdn.example.com/app.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>

How to use them

Add one report-shaXXX keyword : In script-src (or script-src-elem), add 'report-sha256', 'report-sha384', or 'report-sha512'. One is enough; use the algorithm you plan to allowlist with.
Configure reporting : Set report-to or report-uri and, for report-to, send the Reporting-Endpoints header so reports reach your endpoint (e.g. CentralCSP reporting).
Use crossorigin on cross-origin scripts : For scripts loaded from another origin, set crossorigin="anonymous" so hashes can be computed and included in reports.
Start in report-only : Use Content-Security-Policy-Report-Only with report-shaXXX to gather dependencies without blocking. Then add the dependencies to your policy and switch to enforce mode when ready.

If hashes are missing from reports, check that the script tag has crossorigin="anonymous" and that the reporting endpoint is receiving reports. Browser support for report-shaXXX may vary; see MDN script-src for current support.

Continue Reading

Understand Bitsight new Web Application Security (WAS) algorithm

Learn how to understand Bitsight new Web Application Security (WAS) algorithm. See how to avoid CSP violations & misconfiguration findings. Fix issues & prevent score drops.

2025-07-15

5 min read