HTTP Security Headers for Payment Pages Explained

HTTP security headers are instructions your server sends with each page that tell the browser how to treat it: which scripts to trust, whether to use HTTPS only, who may frame the page, what to share with other sites and what to store. For a payment page the most important are Content-Security-Policy, Strict-Transport-Security, frame protection, Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control. PCI DSS 11.6.1 asks you to be alerted when headers change without authorization, because weakening a header is a common step in an attack.

What security headers are and why they matter

When a browser requests a page, the response includes the page and a set of HTTP headers. Some headers are about performance; the security headers switch on protections that live in the browser itself. They cost almost nothing to send and, set well, they close whole classes of attack. Set badly or removed, they leave the page less protected, often without any visible change.

For payment pages the headers matter twice: they reduce the chance that a skimmer can load or send data out, and, because they can be changed by anyone who controls a proxy, CDN or server setting, they are something an attacker may weaken. That is why PCI DSS requirement 11.6.1 covers the HTTP headers as well as the page content.

The headers that matter most

Header	What it does	Typical value or note
`Content-Security-Policy`	Limits where scripts, frames, images, forms and connections may come from or go to. The strongest defense against injected scripts. See Content Security Policy for payment pages.	Built for your page; start with report-only mode.
`Strict-Transport-Security` (HSTS)	Tells the browser to use only HTTPS for your site for a set time, so a downgrade to plain HTTP cannot be forced.	`max-age=31536000; includeSubDomains`; add `preload` only after reading the preload requirements. Defined in RFC 6797.
`X-Frame-Options` and CSP `frame-ancestors`	Control which sites may put your page in a frame, which stops clickjacking.	`frame-ancestors 'none'` (or `'self'`) is the modern form; `X-Frame-Options: DENY` (or `SAMEORIGIN`) is the older one, defined in RFC 7034, kept for older browsers.
`Referrer-Policy`	Controls how much of the page address is sent to other sites when a visitor clicks away or the page loads a resource.	`strict-origin-when-cross-origin` is a sensible default; stricter values such as `no-referrer` suit pages with sensitive addresses.
`Permissions-Policy`	Turns browser features, such as camera, microphone, geolocation and payment request, on or off for the page and for frames inside it.	Disable what the page does not use, for example `camera=(), microphone=(), geolocation=()`.
`X-Content-Type-Options`	Stops the browser from guessing a file's type, which blocks some attacks that disguise script as another kind of file.	`nosniff`
`Cache-Control`	Controls whether the page may be stored by browsers and intermediaries. Pages with personal or payment details should not be.	`no-store` on pages that show or collect sensitive data.

Two older headers are worth a note. X-XSS-Protection controlled a filter that modern browsers no longer include and is generally recommended to be turned off or omitted. Public-Key-Pins was removed from browsers and should not be used.

A starting point, not a recipe

The headers below show the shape of a reasonable set. The Content Security Policy in particular must be built for your own pages and tested before it is enforced, so it is shown here only as a placeholder.

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: (built for your page, see the CSP article)
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Cache-Control: no-store

The OWASP HTTP Headers Cheat Sheet and the OWASP Secure Headers Project keep current guidance and the values recommended for each header.

What header tampering means

Header tampering is any unauthorized change to the headers a page is delivered with. In practice it takes forms such as:

removing the Content Security Policy, or adding 'unsafe-inline' or an attacker's domain to it, so that the attacker's script is allowed to run;
removing frame protection so the page can be framed by another site;
removing HSTS or shortening its lifetime;
headers that differ between pages, regions or visitors, for example a page that is protected on the main route but not on the payment step.

The cause may be an attacker with access to the server, CDN or proxy configuration, a well-meant change by someone who did not know the effect, or a deployment that overwrote the headers. The effect is the same, and it is invisible in the page itself. Checking the headers as the browser receives them, on a schedule, and alerting on any difference from the approved set is how requirement 11.6.1 deals with this. See how to detect client-side tampering.

Key takeaways

Security headers switch on browser protections; they are cheap to send and effective when set well.
For payment pages, the key headers are CSP, HSTS, frame protection, Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control: no-store.
Weakening or removing a header is a common step in an attack, and it does not change how the page looks.
PCI DSS 11.6.1 asks for alerts when HTTP headers change without authorization.
Build the CSP for your own pages and test in report-only mode first.

Frequently asked questions

Which HTTP security headers are most important for a payment page?

Content-Security-Policy is the most powerful, followed by Strict-Transport-Security, frame protection (CSP frame-ancestors, with X-Frame-Options for older browsers), Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control: no-store.

Does PCI DSS list the headers I must set?

Requirement 11.6.1 speaks of alerting on unauthorized changes to the HTTP headers of payment pages as received by the browser; it is a detection requirement and does not give a fixed list of headers to set. Which headers matter for your pages is a decision to explain to your assessor.

Is X-Frame-Options still needed if I use frame-ancestors?

Modern browsers honor the CSP frame-ancestors directive, which is more flexible. X-Frame-Options is still sent by many sites for older browsers. If both are present, browsers that support frame-ancestors use it.

Can I set a Content Security Policy in a meta tag instead?

Partly. A meta tag can carry most CSP directives, but not frame-ancestors, report-uri or sandbox, and it applies only after the browser has parsed it. A real HTTP header is the better choice.

References

Last reviewed: October 17, 2026

HTTP security headers for payment pages, explained