Lesson 3.10: Third-party scripts and Subresource Integrity
Every script tag that points to someone else's server is a promise that their file will never change in a harmful way. Subresource Integrity (SRI) turns that promise into a check: the page carries a hash of the exact file it expects, and the browser refuses anything else. In the lab you prove the CDN copy of the carousel library differs from the vendor's release, see the injected line, compute the SHA-384 integrity value of the genuine file, pin the script tag, and build the inventory of payment page scripts that PCI DSS v4.0 requires.
16 min
You will learn to
- Explain the risk of third-party scripts
- Compare a served file with a known-good release
- Compute an SRI hash
- Pin a script with integrity and crossorigin
- Inventory payment page scripts (PCI DSS 6.4.3)
Key terms
- Subresource Integrity (SRI)
- An integrity attribute with a hash; the browser refuses a script or stylesheet whose content doesn't match.
- crossorigin="anonymous"
- Fetches the file with CORS and without cookies, so the browser may check its integrity.
- Known-good copy
- A version verified at the time it was added (signed release, lockfile hash).
- PCI DSS v4.0 6.4.3 / 11.6.1
- Payment page scripts must be authorised, justified, integrity-assured, and changes detected.
- Self-hosting
- Serving a third-party library from your own origin after verifying it.
← Storing and checking passwords · All lessons · Password spraying and the lockout policy →