An online shop can run technically flawlessly and still carry an open flank that sits in the HTTP traffic: in the response headers the server sends with every page. HTTP security headers such as Content-Security-Policy and Strict-Transport-Security instruct the browser to shut down entire classes of attack up front -- from an injected third-party script to the unencrypted first request. Yet they are rarely set: only around 22 percent of all hosts serve a Content-Security-Policy at all (HTTP Archive Web Almanac 2025). What makes them trickier is that these headers are not a one-time setup. Every theme, plugin or payment update can break an existing policy or inject a new external script that silently undermines the rule. The payment card standard has responded and, since 31 March 2025, requires an inventory of all scripts on the payment page along with monitoring for unauthorized changes (PCI Security Standards Council). This article shows which headers a shop should set, how the path leads from the risk-free report-only mode to strict enforcement, and why ongoing header care including regression checks belongs in every security update service.
Key takeaways
- Security headers live in the server or application configuration, not in plugin code: a shop update never carries them along, yet it can render them ineffective without a sign. Only 22 percent (HTTP Archive Web Almanac 2025) of hosts serve a CSP at all.
- Base protection consists of six headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options with nosniff, Referrer-Policy set to strict-origin-when-cross-origin, Permissions-Policy for unused browser features, and X-Frame-Options or frame-ancestors.
- A CSP limits where scripts may load from and where data may be sent, but loses that protection with unsafe-inline, which over 92 percent (HTTP Archive Web Almanac 2025) of CSP-bearing sites use. Inline scripts are approved individually via a nonce or a content hash.
- HSTS forces HTTPS and closes the window of the unencrypted first request. includeSubDomains makes any subdomain without working HTTPS unreachable, and a preload entry can only be withdrawn with long lead time, so start with a short max-age and raise it after testing.
- The safe entry point is Content-Security-Policy-Report-Only: collect violations, assess every reported source, tighten the policy, verify it in staging, then enforce. Only around 1.8 percent (HTTP Archive Web Almanac 2024) of sites use this measurement mode.
- Themes, extensions, payment and consent scripts shift the sources a page loads, so every update is followed by a regression check. Since 31 March 2025, PCI DSS 4.0 requires a payment page script inventory (6.4.3) and a check at least every seven days (11.6.1).
Why Security Headers Are Not a One-Time Setup
A security header is a short instruction in the HTTP response head -- a line of text the browser reads before it renders the page. It costs almost no compute time, does not slow the shop down and can be set with a few lines in the server configuration. Precisely because the effort is so small, the low adoption is surprising: even where a Content-Security-Policy exists, it is often watered down. Over 92 percent (HTTP Archive Web Almanac 2025) of sites with a CSP allow unsafe-inline and thereby largely cancel a central protection against cross-site scripting. A header is simply not a product feature you enable once, but configuration -- and configuration shifts with every change to the system.
The insidious part lies in the interplay with day-to-day operation. A new theme embeds a font from a foreign address, an updated extension suddenly loads an additional analytics script, a payment provider moves its widget to a new domain -- and a previously correct Content-Security-Policy blocks legitimate functions, or a too loosely worded rule lets the new third-party script pass unchecked. Without a check after every update, hardening that was once in place quietly falls apart. That is exactly why we treat headers like any other security-relevant setting: as part of an ongoing process considered at every maintenance window without lost sales.
Headers Are Configuration, Not a Feature
The Most Important Headers at a Glance
Which headers make sense does not have to be reinvented. The OWASP Secure Headers Project maintains a vendor-neutral reference on which HTTP response headers increase security and how they should be configured (OWASP Secure Headers Project). In addition, the Mozilla MDN Web Docs describe every header including its directives and browser behavior in detail (Mozilla MDN Web Docs). From both, a baseline can be derived that holds for most shops -- five to six headers that together form a resilient base level of protection.
| Header | Protects against | Recommended starting point |
|---|---|---|
| Content-Security-Policy | cross-site scripting, injected third-party scripts | restrictive, first in report-only mode |
| Strict-Transport-Security | protocol downgrade, unencrypted first request | max-age=63072000; includeSubDomains |
| X-Content-Type-Options | MIME sniffing into misinterpreted files | nosniff |
| Referrer-Policy | leakage of URL data to third parties | strict-origin-when-cross-origin |
| Permissions-Policy | unwanted access to camera, microphone, location | set unneeded features to empty |
| X-Frame-Options | clickjacking via embedding in foreign pages | SAMEORIGIN or CSP frame-ancestors |
Adoption of these headers is very uneven. Most common is X-Content-Type-Options with nosniff at nearly 50 percent (HTTP Archive Web Almanac 2025), followed by X-Frame-Options at about 37 percent (HTTP Archive Web Almanac 2024) and HTTP Strict Transport Security at around 36 percent (HTTP Archive Web Almanac 2025). Notably rarer are the Referrer-Policy at around 17 percent (HTTP Archive Web Almanac 2024) and the comparatively young Permissions-Policy at only 3.7 percent (HTTP Archive Web Almanac 2025). For a shop this means: the simple, low-risk headers such as nosniff are set quickly, while the most effective ones -- CSP and HSTS -- demand the most care.
Content-Security-Policy: Effective but Delicate
The Content-Security-Policy is the most effective of the headers and at the same time the most demanding. It defines from which sources the browser may load scripts, styles, images and other resources, and where the page may send data. A script injected through a vulnerability that wants to send payment data to a foreign domain fails at a restrictive connect-src rule -- even if the attacker managed to place code in the page. The Mozilla MDN Web Docs describe CSP as an added layer of protection that detects and mitigates certain attacks such as cross-site scripting and data injection (Mozilla MDN Web Docs).
The most common mistake is the unsafe-inline directive. It permits arbitrary inline scripts and thereby reopens exactly the gap CSP is meant to close -- and yet over 92 percent of sites with a CSP resort to it (HTTP Archive Web Almanac 2025). The clean path runs via nonce- or hash-based approvals: each legitimate script receives a one-time random value or a content hash, and only scripts marked this way run. The OWASP Secure Headers Project recommends keeping a CSP as restrictive as possible and setting exceptions deliberately and documented (OWASP Secure Headers Project).
# Content-Security-Policy with nonce instead of unsafe-inline
add_header Content-Security-Policy "\
default-src 'self'; \
script-src 'self' 'nonce-$request_id' https://pay.example.com; \
style-src 'self'; \
img-src 'self' data:; \
connect-src 'self' https://pay.example.com; \
frame-ancestors 'self'; \
object-src 'none'; \
base-uri 'self'; \
report-uri /csp-report" always;
# To measure without blocking: same policy as Report-Only
# add_header Content-Security-Policy-Report-Only "..." always;unsafe-inline Undermines the CSP
unsafe-inline in script-src offers little protection against cross-site scripting anymore, because it permits arbitrary embedded scripts. Where inline scripts are unavoidable, they belong approved via a nonce or a content hash -- not wholesale. This distinction decides whether a CSP works or merely exists.HSTS: Enforce HTTPS Without Locking Yourself Out
HTTP Strict Transport Security instructs the browser to call a domain exclusively over HTTPS -- even when a user enters the address without https:// or follows an old http:// link. HSTS thereby closes the window of the unencrypted first request, in which an attacker on the same network could redirect the connection. The Mozilla MDN Web Docs describe the three central components: max-age sets the validity period in seconds, includeSubDomains extends the rule to all subdomains, and preload submits the domain for the list hard-coded into the browser (Mozilla MDN Web Docs).
includeSubDomains and preload in particular demand care. Whoever extends the rule to all subdomains must ensure that truly every subdomain -- including internal tools and legacy systems -- is cleanly reachable over HTTPS, otherwise they become unreachable. And a preload entry can only be undone with considerable lead time. That is why HSTS sensibly begins with a short max-age that is raised step by step after a successful test. Transport encryption itself -- certificates, protocol versions and renewal -- is covered in more depth in the article on managing SSL certificates.
Use includeSubDomains and preload Deliberately
includeSubDomains and preload is hard to reverse: browsers remember the instruction for the entire max-age duration, and a preload entry additionally sits firmly in the browser. Introducing the header with a short validity period and extending it only after a successful test avoids locking yourself or individual subdomains out.# Enforce HTTPS (extend step by step after testing)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
# Prevent MIME sniffing
add_header X-Content-Type-Options "nosniff" always;
# Share URL data sparingly
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Make clickjacking harder
add_header X-Frame-Options "SAMEORIGIN" always;
# Switch off unneeded browser features
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;The Report-only-to-Enforce Process
Switching a Content-Security-Policy to strict without knowing what the shop actually loads reliably ends in blocked scripts and a broken checkout. That is what the report-only mode is for. Through the header Content-Security-Policy-Report-Only, the browser reports every violation of the policy but blocks nothing -- the shop keeps running unchanged while you observe which sources would break the policy (Mozilla MDN Web Docs). This mode is barely used: only around 1.8 percent of sites run a CSP in report-only mode at all (HTTP Archive Web Almanac 2024), even though it is the safest entry point.
- Capture the current state: first serve the policy only as
Content-Security-Policy-Report-Onlyand collect the reported violations over a defined period. - Assess the sources: check each reported source -- does it belong to the shop, is it legitimate and necessary, or is it a candidate for removal?
- Tighten the policy: explicitly approve legitimate sources, allow inline scripts via
nonceor hash instead ofunsafe-inline, and exclude everything else. - Verify in a staging environment: test the tightened policy away from live operation first, as described in the article on staging environments for safe updates.
- Switch to enforce: activate the policy as an enforcing
Content-Security-Policyheader -- with the report channel still active to catch regressions early.
Report-only Measures, Enforce Protects
Why Every Update Can Break a Policy
Once a policy is strict, the real ongoing task begins. A shop is not a static structure: themes are updated, extensions are added, payment providers change their integration, consent and analytics tools load new resources. Each of these changes can do two things -- break an existing rule so that legitimate functions are blocked, or introduce a new external source that a too broadly worded policy lets through unchecked. The payment card standard addresses exactly this: requirement 6.4.3 demands a complete inventory of all scripts on the payment page, each authorized, integrity-checked and with documented justification (PCI Security Standards Council). Such an inventory only holds if it is carried along with every change.
Theme and Template Updates
A new theme often embeds fonts, icons or scripts from additional addresses. An existing CSP blocks them -- or has to be extended by exactly those sources before the page works fully again.
Plugins and Extensions
An updated extension sometimes loads new external libraries. Without a comparison against the policy, either the function or the protection breaks -- and no one notices immediately.
Payment and 3-D Secure
Payment providers and 3-D Secure flows load scripts and partly redirect to further domains. If this integration changes, the policy has to follow, otherwise the payment breaks or a foreign script slips through.
Consent and Analytics Scripts
Consent banners and analytics tools embed resources dynamically and change their sources without warning. They are a common reason why a CSP that was valid yesterday reports violations today.
At the checkout, this problem intensifies because payment data is in play. How injected or tampered scripts at the checkout concretely lead to data leakage, and how Subresource Integrity and a restrictive CSP prevent it, is covered in the article on web skimming at the checkout. For regulated operators there is the added factor that security measures increasingly have to be demonstrated -- an aspect the NIS2 obligations for online shops also touch on.
Header Care and Regression Checks
The consequence of all this is a recurring check: after every larger update, it is verified whether the set headers are still present, still fitting and still effective. The payment card standard sets a minimum cadence for this in requirement 11.6.1 -- detection of unauthorized changes to scripts and security-relevant HTTP headers of the payment page, checked at least every seven days (PCI Security Standards Council). Seven days is the minimum, not the goal: with an average of 119 new vulnerabilities per day in the period July 2024 to June 2025 (BSI report 2025), a tighter cadence up to continuous checking is the more sensible path. This observation can be automated through ongoing monitoring of the response headers.
- After every theme, plugin or payment update, check whether all set headers are still delivered and no new external source has crept in unnoticed.
- Compare the Content-Security-Policy against the resources actually loaded and approve new legitimate sources deliberately and documented.
- Deliberately roll back
unsafe-inlineand other weakenings and replace them withnonce- or hash-based approvals. - Regularly check the HSTS validity period and
includeSubDomainsagainst the actual subdomain inventory. - Keep the payment page script inventory versioned and re-approve it on every change (PCI DSS 4.0, requirement 6.4.3).
- Treat header changes like code: versioned, traceable and tested via a staging environment before they go live.
A security header is rarely rendered ineffective by an attack, but by your own next update. Whoever treats headers like code and re-measures after every change keeps the protection instead of quietly losing it.
A cleanly set header set, a documented report-only-to-enforce process and a fixed regression check after every update together produce protection that does not fall apart with the next deployment. This ongoing header care is a firm part of our ongoing security updates and interlocks with the other building blocks of maintenance -- from server hardening for shops through patch and CVE management to regression testing after updates. As part of an SLA maintenance contract and our entire managed maintenance services, a once-set policy becomes a state that is kept up across every update. How this looks in ongoing Shopware operation we are glad to discuss in detail.
nosniff, Referrer-Policy, Permissions-Policy and X-Frame-Options or frame-ancestors in the CSP. The OWASP Secure Headers Project and the Mozilla MDN Web Docs describe these headers and their recommended configuration in detail (OWASP Secure Headers Project). CSP and HSTS are the most effective and demand the most care.Content-Security-Policy-Report-Only. The browser reports every violation but blocks nothing -- the shop keeps running unchanged (Mozilla MDN Web Docs). This lets you measure which sources a page really loads before the policy is switched to strict enforcement. The mode is still rarely used, only around 1.8 percent of sites employ it (HTTP Archive Web Almanac 2024).