Content Security Policy (CSP) limits the resources and code behavior a page may load or execute. Subresource Integrity (SRI) checks whether a selected script or stylesheet matches its declared hash. CSP sets policy boundaries; SRI checks the bytes of a particular file. Neither replaces input validation, output encoding, or a safe release process. CSP Level 3 specification SRI specification

Generate a fresh CSP nonce for each response

When inline scripts are necessary, a server can generate an unpredictable nonce for each response and place the same value in the response header and each permitted <script> element. The current CSP Level 3 document is a Working Draft; it says a nonce must be unique for each policy transmission and recommends at least 128 bits. The brace-delimited value below is a server-side placeholder that must be replaced with a secure random value for every response. A fixed string defeats the purpose. Nonce requirements

Content-Security-Policy: default-src 'self'; script-src 'nonce-{{REQUEST_NONCE}}'; object-src 'none'; base-uri 'none'
<script nonce="{{REQUEST_NONCE}}">/* permitted inline code */</script>

{{REQUEST_NONCE}} must be the same response-specific value in both places. Do not hard-code it in a template or reuse it for other visitors through page caching. Review external script origins and whether they also need nonces or SRI. A nonce does not authorize eval(). String-compiling operations such as eval() are controlled by the 'unsafe-eval' policy in script-src; do not try to bypass that boundary by adding a nonce. script-src guidance

Pin the expected bytes of an external file with SRI

For a version-pinned CDN file, record the hash produced by your build or trusted supplier. The browser will refuse to apply the resource if the downloaded content does not match. Cross-origin resources must be requested using CORS, so include crossorigin="anonymous". Review and deploy a changed file and its hash together. SRI usage requirements

<script src="https://cdn.example.com/lib-1.2.3.js"
        integrity="sha384-{{GENERATED_BASE64_DIGEST}}"
        crossorigin="anonymous"></script>

This is a placeholder example, not a deployable hash. Verify the exact file digest and the CDN’s CORS response first. SRI confirms that a file has the expected bytes; it does not certify that the code was safe or current to begin with.

Test before enforcing

Inventory the scripts and inline code the page actually uses. A Content-Security-Policy-Report-Only header lets you observe a proposed policy without blocking existing behavior. Confirm that your reporting path works and that reports do not expose sensitive data; then narrow the policy and enforce it in a test environment. Report-Only is an observation stage, not active protection. The W3C specification says this header cannot be delivered through an HTML <meta> element; send it as an HTTP response header. Report-Only behavior

Before release, check that the nonce changes per response, matches between header and HTML, and allows only intended scripts; also confirm that each SRI hash matches the deployed file. CSP and SRI address different failures. A CSP violation can break a required feature, and an SRI mismatch can block a resource, so define a rollback and hash-update procedure.

Sources