Content Security Policy (CSP) for payment pages

What a Content Security Policy does

Content Security Policy (CSP) is a browser security feature, switched on by sending a Content-Security-Policy header with the page. The policy is a list of directives, each naming the kinds of resource it controls and the sources allowed. If the page tries to load or run something the policy does not allow, the browser blocks it and can report the attempt.

For a payment page the value is twofold. It can stop a skimmer from running, by refusing script from a source you did not approve, and it can stop a skimmer from sending data out, by limiting where the page can make requests, load images and submit forms. It is therefore both a prevention control and, with reporting, a source of signals. It does not replace fixing the underlying flaw; see XSS and injected skimmer code.

The directives that matter for payment pages

script-src: allow-lists, nonces, hashes and strict-dynamic

Allow-lists of hosts: easy but fragile

The simplest policy lists the hosts scripts may come from. It is weak in practice: any script on an allowed host runs, so one allowed host that serves user-supplied content, an open redirect or a large library collection can be abused to run an attacker's code. Long lists are also hard to keep accurate.

Nonces

A nonce is a random value generated for every response and placed both in the header and on each legitimate <script> tag. The browser runs only scripts that carry the nonce. It must be unpredictable and fresh on every response, at least 128 bits long before encoding according to the CSP specification. Nonces need pages that are generated per request; a page cached and served identically to everyone cannot use them.

Hashes

A hash lists the exact content of an allowed script, so the browser runs a script only if its hash matches. Hashes suit static inline scripts that change rarely.

'strict-dynamic'

With 'strict-dynamic', a script that is trusted through a nonce or hash may load further scripts, and those inherit trust without being listed. In browsers that support it, host allow-lists are then ignored. It works well with tag managers, but it also means anything the trusted script loads is trusted, so the governance of that script matters; see tag manager risk.

What defeats a policy

• 'unsafe-inline' allows any inline script, including an injected one, and removes most of the protection. When a nonce or hash is present, modern browsers ignore it, which is why it is sometimes included as a fallback for old browsers.
• 'unsafe-eval' allows code to be built from strings.
• Wildcards such as *, https: or a broad domain pattern allow far more than intended.
• data: as a script source allows script to be embedded in a link.

Rolling out safely: report-only mode and reporting

A new policy almost always blocks something legitimate. Send it first as Content-Security-Policy-Report-Only: the browser does not block anything but reports each violation. Review the reports, fix the policy or remove the unneeded script, and enforce when the reports are quiet.

Reports are sent to an address you name. The older report-uri directive is deprecated in favor of report-to with a named endpoint set in the Reporting-Endpoints header, but browser support differs, so many sites send both for now. Check MDN for current support.

An illustration, not a policy to copy

Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-{random-per-response}' 'strict-dynamic';
  connect-src 'self' https://payments.example-provider.com;
  frame-src https://payments.example-provider.com;
  img-src 'self';
  style-src 'self';
  form-action 'self';
  base-uri 'none';
  object-src 'none';
  frame-ancestors 'none'

A real policy has to be built from what your payment page actually needs; Google's CSP Evaluator and the guidance on strict CSP at web.dev are useful for checking it.

CSP and PCI DSS

A CSP can serve as part of the authorization method for requirement 6.4.3, because it enforces which sources may run, and it supports the exfiltration limits that make a skimmer less useful. It does not, by itself, show that an allowed file has not been altered, so it is usually paired with an integrity measure such as Subresource Integrity. And because the policy is itself an HTTP header, requirement 11.6.1 expects you to be alerted if it is changed without authorization. See PCI DSS 6.4.3 explained and HTTP security headers for payment pages.