CSP and SRI: Run Only Your Own Code

This article has three layers:

1. Layer 1: The Intuition: Why a single external script can destroy a website
2. Layer 2: Real-World Use: British Airways Magecart, polyfill.io, Ledger Connect Kit
3. Layer 3: Principles and Engineering details

Layer 1: The Intuition

1.1 External Scripts = Handing Over Your House Keys

Many websites reference third-party code like this:

<script src="https://cdn.some-analytics.com/track.js"></script>

This line of code means: "Fetch a piece of code from that server and run it as me." If that server is compromised, or the domain changes owners, whatever code it returns will be executed on your page, including instructions like "send the user's entered credit card number to me."

1.2 Two Lines of Defense

Layer 2: Real-World Use

This category of attack is collectively known as Magecart (web skimming) or supply chain attacks: the attacker does not touch your server, but instead modifies the third-party code you trust.

Layer 3: Principles and Engineering

3.1 A Strict CSP

Content-Security-Policy:
  default-src 'none';
  script-src 'self';
  style-src 'self';
  img-src 'self' data:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'none';
  form-action 'self';
  report-to csp-endpoint

Before going live, you can use Content-Security-Policy-Report-Only to report without blocking, observe for a period, and only enable it officially once you have confirmed there are no false positives.

3.2 Writing SRI

<script src="https://cdn.example.net/lib-4.2.1.min.js"
        integrity="sha384-（SHA-384 hash of file contents, base64 encoded）"
        crossorigin="anonymous"></script>

After the browser downloads a file, it calculates the hash; if it doesn't match, execution is refused. It relies on the second pre-image resistance property of hash functions: an attacker cannot create a malicious file with different content but the same hash (see "The Birthday Paradox and Hash Collisions").

Limitations: SRI can only be used for fixed-version files. If you reference an "always latest version" URL, the content will change, the hash will change, and SRI will not work. This "always latest version" approach was precisely the root cause of the Ledger Connect Kit incident.

3.3 Zero Third-Party Scripts

For pages involving signatures, payments, or logins, the most secure approach is:

1. All dependencies must lock versions and be bundled into your own code during build time, rather than being loaded from any CDN at runtime;
2. Do not include any third-party scripts such as analytics, advertising, or customer chat;
3. Dependency upgrades should follow a manual review process; do not enable automatic merging;
4. Note that the hosting platform itself may inject things into the page (analytics, performance optimization, email obfuscation scripts); these need to be disabled, or you must use Cache-Control: no-transform and perform regular inspections (see "The Bybit Incident and Frontend Integrity").

3.4 What CSP Cannot Prevent

• If an attacker can directly modify files on your server (the source of 'self'), CSP will still allow them to run;
• If the build process is poisoned, the malicious code is already inside "your own code."

These two scenarios must be defended against through deployment pipeline security and online integrity inspections.

Summary