Skip to main content

Third-party scripts documented

ab-002427 · security-headers-ii.supply-chain.script-inventory
Severity: infoactive

Why it matters

Every external script loaded by your application is a potential supply chain attack vector. Without documentation of which scripts are loaded and why, a security review cannot determine whether a given external dependency is intentional or injected — and developers cannot confidently audit or remove scripts that are no longer needed. CWE-1357 (Reliance on Insufficiently Trustworthy Component) applies when third-party scripts are loaded without recorded justification. OWASP A08 (Software and Data Integrity Failures) calls out undocumented third-party dependencies as a supply chain risk. Documented inventories also accelerate incident response when a CDN is compromised.

Severity rationale

Info severity because undocumented scripts don't create a direct vulnerability but eliminate the audit trail needed to detect unauthorized additions or remove stale dependencies during security reviews.

Remediation

Add a third-party script inventory to your README or a dedicated docs/third-party-scripts.md. At minimum, record each script's domain, purpose, and when it was added.

## Third-Party Scripts

| Script | Domain | Purpose | Added |
|--------|---------|---------|-------|
| Google Tag Manager | googletagmanager.com | Analytics | 2024-01 |
| Stripe.js | js.stripe.com | Payment processing | 2024-02 |
| Sentry Browser SDK | browser.sentry-cdn.com | Error tracking | 2024-03 |

Alternatively, add an inline comment above each <script> tag explaining its purpose and owner. The goal is that any developer or security reviewer can quickly answer: is this script supposed to be here, and who approved it?

Detection

  • ID: security-headers-ii.supply-chain.script-inventory

  • Severity: info

  • What to look for: Check for documentation of external script dependencies. Look in: README sections about third-party scripts, code comments near script tags explaining purpose, a manifest file (e.g., third-party-scripts.md, vendor.json), or package.json annotations. The goal is that someone reviewing the codebase can understand why each external script is loaded. Check for at least 1 documentation location that lists external dependencies with their purpose.

  • Pass criteria: At least 1 documentation location lists external script dependencies with purpose/justification. Count all documentation locations found and report: "Found documentation in X location(s)."

  • Fail criteria: No documentation of external script dependencies found anywhere in the codebase.

  • Skip (N/A) when: No third-party scripts loaded — all resources are first-party or bundled.

  • Detail on fail: "No documentation of third-party scripts found — external dependencies loaded without recorded justification" or "3 external scripts loaded but no README section, comments, or manifest documenting their purpose"

  • Remediation: Document every external script your project loads. This helps with security reviews, compliance, and debugging:

    ## Third-Party Scripts
| Script | Domain | Purpose | Added |
|--------|--------|---------|-------|
| Google Analytics | googletagmanager.com | Usage analytics | 2024-01 |
| Stripe.js | js.stripe.com | Payment processing | 2024-02 |
| Sentry | browser.sentry-cdn.com | Error tracking | 2024-03 |

    Alternatively, add inline comments near each script tag explaining why it is loaded.

External references

Taxons

supply-chain

History