Security headers · Check
Third-party scripts without Subresource Integrity — locking down what you load
Multiple third-party origins on your homepage ship `<script>` tags without an `integrity=` attribute. Without Subresource Integrity, the browser cannot detect if the script content was modified between the upstream host and the user — a CDN compromise, a hijacked package, or a silent file swap all execute with full access to your page.
Why it matters
SRI is the cheapest defense against supply-chain compromise of public CDN scripts. Generate a SHA-384 hash, paste it into the `integrity=` attribute, and the browser will refuse to run a tampered file. It pairs naturally with a tight `script-src` CSP.
Real-world risk
If any of the third-party origins your homepage loads from is compromised — through credential theft, a hijacked package, or an attacker's silent swap — the modified script runs with full DOM and cookie access on your site. SRI gives the browser a hash to verify and refuse the load if the file was tampered with.
Fix steps (in order)
- Generate a SHA-384 hash for each third-party script you control the version of: openssl dgst -sha384 -binary script.js | openssl base64 -A
- Add integrity="sha384-..." and crossorigin="anonymous" to the <script> tag.
- For frequently-updated vendor scripts (Google Tag Manager, Stripe, Intercom), pin to a versioned URL where you can and add SRI; for unversioned tags, audit the loader carefully and consider proxying through your own origin.
- Pair SRI with a strict CSP script-src that explicitly allow-lists the origins you load from, so attackers cannot just point you at a different host.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (third_party_script_no_sri) clears once the externally-observable signal is in place.