Securing Modern Web Apps: Integrating SRI & CSP with Nonces and Hashes

Modern web developers rely heavily on external Content Delivery Networks (CDNs) to load essential JavaScript libraries and CSS stylesheets. While this approach improves performance and reduces server load, it introduces serious security risks. If a malicious attacker compromises a third-party CDN, they can inject malicious code directly into your users’ browsers. Fortunately, combining Subresource Integrity (SRI) and a robust Content Security Policy (CSP) creates a multi-layered defense mechanism that guarantees file integrity and prevents unauthorized code execution.

What is Subresource Integrity (SRI)?

Subresource Integrity is a powerful browser security feature that validates external assets before executing them. Specifically, developers generate a cryptographic hash of the expected file and include it in the HTML tag via the integrity attribute. Subsequently, when the browser downloads the file, it computes its hash in real time. If the calculated hash matches the integrity string, the browser executes the file; otherwise, it blocks the asset completely.

Use-Case Scenario: Protecting Third-Party CDNs

Imagine loading jQuery or Bootstrap from a public CDN. Furthermore, suppose hackers hijack the CDN server and replace the original file with malware. Without SRI, your website executes the malicious script automatically. With SRI enabled, your user’s browser detects the cryptographic mismatch and immediately drops the tampered script.

SRI Sample Code

To implement SRI, simply add the integrity attribute (using sha256, sha384, or sha512) along with crossorigin="anonymous" to your HTML tags:

<!-- HTML Script Tag with Subresource Integrity -->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"
        integrity="sha384-geWF76RCwLtnZ8qwWowPQNguL3RmwHVBC9FhGdlKrxdiJJigb/j/68SIy3Te4Bkz"
        crossorigin="anonymous"></script>

Enhancing Security with Content Security Policy (CSP)

While SRI ensures external assets remain untampered, an attacker might still inject inline scripts directly into your HTML document via Cross-Site Scripting (XSS). Therefore, you must implement a Content Security Policy (CSP). CSP restricts which scripts can execute inside the application using two main options: Nonces and Hashes.

Option A: CSP Nonces (Number Used Once)

A CSP nonce is a cryptographically strong, randomly generated token created on the server for every HTTP request. The server embeds this unique token in the CSP HTTP response header as well as in the inline <script> tags. Consequently, the browser executes only scripts that display the matching nonce value.

HTTP Response Header:

Content-Security-Policy: script-src 'nonce-rAnd0m1234567890==' 'strict-dynamic';

Inline Script Tag:

<script nonce="rAnd0m1234567890==">
    console.log("This trusted script runs safely!");
</script>

Option B: CSP Hashes

Alternatively, if your application serves static HTML pages and cannot generate dynamic server-side nonces, you can compute SHA-256 hashes of specific inline scripts. Afterward, you explicitly list these valid hashes directly within your CSP header.

HTTP Response Header:

Content-Security-Policy: script-src 'sha256-qznLcsLDbgWiW3d0EAW7r+x2Z4iH/4/a2jYgM90yKsw=';

Architectural Diagram: SRI & CSP Validation Flow

Combining SRI and CSP: Defense-in-Depth Checklist

Ultimately, blending SRI and CSP delivers robust defense-in-depth security. To achieve complete protection, follow these best practices:

• Mandate SRI via CSP: Use the CSP directive require-sri-for script style; (where supported) to enforce SRI validation on all external subresources.
• Implement 'strict-dynamic': Pair nonces with 'strict-dynamic' in CSP Level 3. As a result, trusted scripts can dynamically load secondary dependencies automatically without breaking the application.
• Ensure High Entropy Nonces: Always generate nonces using a cryptographically secure random number generator (at least 128 bits of entropy) and never reuse them across requests.
• Include CORS Headers: Remember that SRI requires Cross-Origin Resource Sharing (CORS) headers (Access-Control-Allow-Origin: *) on CDN assets to function properly.

Summary

In summary, securing subresources is no longer optional in today’s threat landscape. By combining Subresource Integrity (SRI) with CSP nonces and hashes, you safeguard your web applications against CDN compromises and XSS attacks simultaneously. Implement these security controls today to build a safer, more resilient web application!