Content Security Policy

Read the `Content-Security-Policy` header and its directives: `script-src`, `style-src`, `img-src`, `connect-src`, `frame-ancestors`, `default-src`. Each lists permitted sources. Browsers report violations to a `report-uri` or `report-to` endpoint, and the console prints each blocked load.

Roll it out with `Content-Security-Policy-Report-Only` first. Count the violation reports per day and per directive. A week with zero new reports on real pages means enforcement is safe to turn on.

A WooCommerce store ships `script-src 'self' https://js.stripe.com`. Overnight a compromised plugin writes `<script src="https://cdn-metrics-track.top/a.js">` into the footer. On the next visit the browser blocks it and posts a violation report naming the blocked URL.

The same policy also blocks the store's own Google Tag Manager snippet, because nobody listed it. Tag firing drops to zero until `https://www.googletagmanager.com` is added.

A CSP is enforced by the browser, on the visitor's machine, per page. A WAF sits in front of the server and filters requests before they reach your code. CSP limits what a loaded page can run, and it does nothing about a vulnerable form on the backend. The WAF does the reverse. Subresource integrity pins an exact file hash, which CSP alone does not.

Using `unsafe-inline` and `unsafe-eval` and calling it done. Writing `script-src *`. Enforcing on day one and breaking checkout. Putting the policy only on the homepage. Never reading the violation reports. Forgetting that inline event handlers and tag managers need nonces or hashes.

Start with report-only, collect two weeks of reports, then enforce a policy that lists exact hosts. Move inline scripts to files or give them nonces. Keep the policy in the repo so reviewers see each new host as a diff.