Integrity (SRI)

Configure Subresource Integrity reporting to detect when third-party scripts fail cryptographic hash verification, revealing potential CDN compromises and supply chain attacks.

New to SRI monitoring? Read our Integrity violations overview to understand the benefits before diving into configuration.

What is Subresource Integrity?

Subresource Integrity (SRI) is a W3C security standard that lets browsers verify that external resources (scripts, stylesheets) haven't been tampered with. You provide a cryptographic hash of the expected file content, and browsers refuse to execute the resource if the hash doesn't match.

SRI works through HTML attributes. You add an integrity attribute containing a base64-encoded SHA-384 hash to your <script> or <link> tags. When the browser fetches the resource, it calculates the hash of the downloaded content and compares it to your expected value.

However, traditional SRI only blocks tampered resources—it doesn't report violations. The Integrity-Policy HTTP header enables violation reporting via the W3C Reporting API, giving you visibility into integrity failures across your user base.

Specification

• W3C Subresource Integrity — Official specification (includes Integrity-Policy)
• MDN: Subresource Integrity — Developer documentation
• MDN: Integrity-Policy header — Reporting header documentation

Browser Support

SRI blocking has 92.92% global browser support, but the Integrity-Policy header for reporting is newer with more limited support.

Subresource Integrity (Blocking)

Integrity-Policy Header (Reporting)

The Integrity-Policy header has ~67% global support. This is a newer feature (2024/2025) with more limited browser coverage.

Why Monitor Integrity Violations?

Integrity violations reveal supply chain attacks that are otherwise invisible to your monitoring stack:

• Detect CDN compromises — Know immediately when a CDN serves modified JavaScript, like the Polyfill.io incident that affected 380,000+ websites
• Catch supply chain attacks — Magecart and similar attacks inject malicious code into legitimate third-party scripts to steal payment data
• Distinguish attacks from misconfigurations — Know whether a hash mismatch is a security incident or just a CDN updating their files
• Meet PCI DSS 4.0 requirements — Requirements 6.4.3 and 11.6.1 mandate script integrity monitoring on payment pages (effective March 2025)
• Respond faster to incidents — Get alerted immediately instead of discovering breaches weeks or months later

Who Benefits

• Security teams — Gain visibility into supply chain attack attempts
• PCI compliance officers — Meet DSS 4.0 requirements for script integrity monitoring
• E-commerce teams — Protect payment pages from Magecart-style attacks

When to Enable

Integrity monitoring is critical for any site loading third-party scripts, especially:

• Payment and checkout pages (required for PCI DSS 4.0 compliance)
• Login and authentication flows
• Any page loading scripts from CDNs
• Sites using analytics, advertising, or widget scripts

How to Configure

Integrity monitoring requires two components:

• Integrity-Policy header — Enables reporting of violations
• integrity attribute — Enables blocking of tampered resources

You need both for full protection and visibility.

Step 1: Set Up the Reporting Endpoint

First, define where browsers should send violation reports using the Reporting-Endpoints header:

Reporting-Endpoints: default="https://reporting-api.app/browser-reports/YOUR-ENDPOINT-UUID"

Replace YOUR-ENDPOINT-UUID with your application's unique endpoint from the reporting-api.app dashboard.

Step 2: Enable the Integrity-Policy Header

The Integrity-Policy header tells browsers to report when scripts lack valid integrity metadata:

Integrity-Policy: blocked-destinations=(script), endpoints=(default)

This configuration:

• blocked-destinations=(script) — Requires integrity metadata for scripts (can also include style for stylesheets)
• endpoints=(default) — Sends reports to the "default" endpoint defined in Reporting-Endpoints

Step 3: Use Report-Only Mode (Optional)

Before enforcing integrity requirements, test with Report-Only mode to see which scripts would be affected:

Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(default)

Report-Only mode sends violation reports without blocking any resources, letting you identify scripts that need integrity attributes before enforcement.

Step 4: Add Integrity Attributes to Scripts

For each external script, add the integrity and crossorigin attributes:

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

The crossorigin="anonymous" attribute is required for CORS-enabled resources. Without it, browsers won't verify the integrity hash.

Step 5: Generate SRI Hashes

Generate SHA-384 hashes for your scripts using command-line tools or online generators.

Using OpenSSL (local file)

openssl dgst -sha384 -binary script.js | openssl base64 -A

Using curl + OpenSSL (remote file)

curl -s https://cdn.example.com/library.js | openssl dgst -sha384 -binary | openssl base64 -A

Online Generator

Use srihash.org to generate integrity hashes from URLs. It also verifies that the CDN supports CORS.

Step 6: Monitor Reports and Refine

After enabling Report-Only mode, monitor incoming reports in your dashboard. Common findings include:

• Scripts without integrity attributes — These need hashes added
• Dynamically loaded scripts — Scripts added via JavaScript may not have integrity attributes
• Third-party widgets — Some services load additional scripts that you can't control

Once you've added integrity attributes to critical scripts, you can switch from Report-Only to enforcement by removing the -Report-Only suffix from your header.

Step 7: Set Up Integrations

Route integrity violation reports to your existing tools for alerting and analysis:

• AppSignal integration — Track violations alongside application errors
• Webhook integration — Send reports to Slack, PagerDuty, or custom endpoints
• Google Chat integration — Post alerts to team chat spaces

See the Integrations documentation for setup instructions.

Understanding Violation Reports

When an integrity violation occurs, the browser sends a JSON report to your endpoint. Understanding this payload helps you respond appropriately to incidents.

Report Fields

Example Report

{
  "type": "integrity-violation",
  "url": "https://example.com/checkout",
  "body": {
    "blockedURL": "https://cdn.example.com/payment-widget.js",
    "documentURL": "https://example.com/checkout",
    "destination": "script",
    "reportOnly": false
  }
}

How to Act on Findings

• reportOnly: true — The resource wasn't blocked (Report-Only mode). Review and add integrity attributes before switching to enforcement.
• reportOnly: false — The resource was blocked. Investigate immediately:
  • If the hash is correct, this could indicate a supply chain attack
  • If the CDN updated the file, you need to update your hash
• Multiple reports for the same script — Widespread violations suggest a CDN compromise rather than a configuration issue.

Server Configuration Examples

Nginx

server {
    # ... your existing configuration ...

    # Reporting endpoint
    add_header Reporting-Endpoints 'default="https://reporting-api.app/browser-reports/YOUR-UUID"' always;

    # Integrity-Policy with reporting
    add_header Integrity-Policy 'blocked-destinations=(script), endpoints=(default)' always;

    # Or use Report-Only mode first:
    # add_header Integrity-Policy-Report-Only 'blocked-destinations=(script), endpoints=(default)' always;
}

Ruby on Rails

# Add Reporting-Endpoints and Integrity-Policy headers
# Note: Use lowercase header names for Rack 3 compatibility
Rails.application.config.action_dispatch.default_headers.merge!(
  "reporting-endpoints" => 'default="https://reporting-api.app/browser-reports/YOUR-UUID"',
  "integrity-policy" => 'blocked-destinations=(script), endpoints=(default)'
)

# For Report-Only mode, use:
# "integrity-policy-report-only" => 'blocked-destinations=(script), endpoints=(default)'

Troubleshooting

Reports Not Appearing

• Check browser support — Only Chrome and Edge send reports to endpoints. Safari doesn't support Integrity-Policy reporting at all, and Firefox only logs to console.
• Check allowed origins — Ensure your website's origin is whitelisted in your application settings.
• Verify headers are sent — Use browser DevTools (Network tab) to confirm both Reporting-Endpoints and Integrity-Policy headers are present in responses.
• Check endpoint configuration — Ensure the endpoints=(default) value matches an endpoint name defined in Reporting-Endpoints.

CORS Errors

• Add crossorigin attribute — Scripts from CDNs require crossorigin="anonymous" for SRI verification to work.
• Check CDN CORS headers — The CDN must send Access-Control-Allow-Origin: * (or your specific origin) for cross-origin resources.
• Use srihash.org — This tool verifies CORS support when generating hashes.

Hash Mismatches After CDN Updates

• Pin to specific versions — Use versioned CDN URLs (e.g., /jquery@3.7.1/) instead of "latest" to prevent unexpected changes.
• Monitor for violations — A sudden spike in violations for a specific script may indicate the CDN pushed an update.
• Regenerate hashes — When you intentionally update a dependency, regenerate the integrity hash and deploy the new value.

Next Steps

• Network Errors — Monitor DNS, TCP, and TLS failures
• Integrations — Route reports to your observability tools
• Getting Started — Set up your first application