# WordPress security headers in 2026: CSP, HSTS, Trusted Types, and reporting > To improve WordPress security headers, start by measuring what the server currently delivers. Then prioritize HTTPS/HSTS, Content-Security-Policy, X-Content-Type-Options, and Referrer-Policy, evaluating Permissions-Policy and isolation policies only where they add value. CSP should usually begin in Report-Only mode so legitimate dependencies can be discovered before blocking. On compatible sites, Trusted Types can add protection against certain DOM XSS sinks, but it requires JavaScript and compatibility review. The Reporting API can collect CSP and other policy reports, though reporting also needs limits and privacy consideration. Canonical: https://kairoseth.com/en/blog/wordpress-security-headers-csp-hsts-2026 Product: [Website Security Audit](https://kairoseth.com/products/security-inspector) Primary query: WordPress security headers Intent: informational-wordpress-security Published: 2026-09-30 Updated: 2026-09-30 Geographic scope: España Geographic context: The guide is designed for WordPress and WooCommerce teams in Spain managing sites with plugins, CDNs, analytics, consent, and payments, and needing stronger headers without breaking commercial functionality. HTTP security headers can strengthen WordPress and WooCommerce, but copying generic configurations can break payments, scripts, and legitimate resources. This guide explains how to evaluate, deploy, and measure CSP, HSTS, and other browser policies progressively. Security headers are a useful defensive layer because they let the browser enforce restrictions before loading or executing certain resources. WordPress, however, rarely has a universal configuration. A site may include Elementor, WooCommerce, Google Tag Manager, payment gateways, video, external fonts, consent platforms, chat, and plugin scripts. A policy copied from a tutorial can break critical functionality or become so relaxed that it adds little value. In 2026 there are also two relevant web-platform changes: the CSP require-trusted-types-for directive reached Baseline status in February, and the Reporting API reached Baseline in March, expanding options for reducing certain DOM XSS sinks and collecting policy telemetry in modern browsers. The correct approach is to measure, test, and harden progressively. ## 1. Before adding headers, build a real baseline The first question is not which headers appear on a checklist, but which headers the browser actually receives on critical pages. A CDN may override the web server, a plugin may create duplicates, and a reverse proxy may apply different rules across environments. Check the home page, login, cart, checkout, account area, forms, and any route with different behavior. Security Inspector can passively detect public posture signals and help prioritize them. That observation does not replace an internal configuration review, but it prevents teams from starting blind. Keeping a baseline also makes it possible to prove what changed after each adjustment. - Check multiple routes, not just the homepage. - Record duplicated or conflicting values. - Identify which layer adds each header. ## 2. HTTPS first; HSTS second HSTS tells the browser to use HTTPS for future connections to the domain during the configured period. It is useful protection, but it assumes HTTPS is already correctly deployed. Before increasing max-age or enabling includeSubDomains or preload, verify certificates, redirects, and subdomains. MDN notes that the policy is learned through an HTTPS response and that includeSubDomains extends behavior to subdomains. In organizations with legacy tools, panels, or services on subdomains, an overly broad policy can create availability problems. HSTS should be treated as an infrastructure decision rather than a score to maximize. ## 3. CSP controls origins, but needs inventory Content-Security-Policy lets a site define which sources may provide scripts, styles, images, fonts, frames, connections, and other resources. OWASP treats it as an important defensive layer that can help mitigate XSS and injection attacks. In WordPress, the challenge is understanding the real resource ecosystem before blocking. A site may load analytics, consent, maps, chat, video, payment, widget, and plugin scripts. If those origins are not inventoried, the first CSP often ends up full of wildcards or broad exceptions. The policy gets stronger when unnecessary dependencies are removed first and only the remaining required sources are allowed. ## 4. Use CSP Report-Only to learn before blocking Content-Security-Policy-Report-Only lets teams observe what a policy would have blocked without enforcing the block. This is especially useful in WooCommerce because an apparently minor violation may correspond to a payment method, authentication flow, or consent script. The observation phase should be long enough to cover real traffic and scenarios, but should not become a permanent state. Reports can be grouped by directive, origin, route, and frequency; the team then decides whether a resource is legitimate, removable, or deserving of a narrower exception. The outcome should be a smaller policy, not an endless allowlist. ## 5. frame-ancestors is preferable to relying only on X-Frame-Options The CSP frame-ancestors directive controls which sites may embed a page in frames. It is relevant to reducing clickjacking scenarios and provides more flexibility than the historical X-Frame-Options header. WordPress sites should review this carefully when pages are legitimately embedded in portals, internal tools, or integrations. Applying DENY mechanically is not appropriate if the organization uses authorized iframes. The policy should reflect the origins actually required and be tested wherever content is embedded inside another system. ## 6. X-Content-Type-Options remains simple and useful X-Content-Type-Options with nosniff tells the browser to respect the declared Content-Type in relevant contexts and prevents MIME sniffing. Compared with CSP, it is a simple control with low operational complexity when server content types are configured correctly. If errors appear after enabling it, the problem may expose responses with an incorrect Content-Type. Correcting the real type is generally better than removing the protection to hide the symptom. ## 7. Referrer-Policy controls how much context leaves the site Referrer-Policy limits how much URL information the browser sends as the Referer when navigating to other origins. On sites containing parameters, internal paths, or sensitive context, reducing that exposure can be useful. The policy should be coordinated with analytics and attribution so teams understand its measurement impact. There is no single correct value for every organization. Configuration should balance privacy, security, and legitimate analytics requirements while avoiding unnecessary disclosure to third parties. ## 8. Permissions-Policy: restrict capabilities, but review compatibility Permissions-Policy controls which browser capabilities are available to the page and its iframes, such as camera, microphone, or selected APIs. MDN still marks the feature as having limited availability for some capabilities, so policies should be designed with compatibility tables in view. A corporate website that never uses camera or microphone may reasonably restrict those features. A site with video calls, document capture, or embedded components may need them. The useful principle is to deny capabilities the product does not use rather than copy an extreme list without understanding it. ## 9. Trusted Types became more practical in 2026 MDN marks require-trusted-types-for as Baseline 2026 since February. This CSP directive can require values created through Trusted Types policies at selected DOM sinks, reducing the attack surface for certain DOM XSS variants. It should not be enabled without preparation because first-party or third-party JavaScript may depend on assigning strings to affected APIs. In WordPress, plugins, builders, and external scripts make compatibility particularly important. Teams can begin by inventorying sinks and libraries, test in staging, and deploy progressively. Trusted Types complements rather than replaces sanitization, escaping, updates, and a well-designed CSP. ## 10. Reporting API: useful telemetry when managed with limits The Reporting API reached Baseline 2026 status in March and provides a common mechanism for receiving reports generated by features such as CSP and other policies. This can turn browser violations into operational signals that teams aggregate and review. Telemetry also needs governance. Reporting endpoints should be protected, events should be aggregated to reduce noise, and retention should be limited to what is necessary. On high-traffic sites, storing every event without deduplication can create cost and hide important problems. ## 11. WooCommerce: always test checkout and payments WooCommerce often depends on external scripts and frames for payments, fraud controls, wallets, consent, or analytics. A new CSP may allow the homepage while breaking only the checkout, turning a security improvement into a commercial incident. Testing should therefore cover real payment methods and alternate states. The inventory should connect every external origin to an owner and purpose. If a payment provider is retired, its domains can be removed from the policy. This discipline prevents CSP from accumulating exceptions for years. ## 12. Headers do not replace keeping WordPress current On September 22, 2026 WordPress released 7.1.2 to address a critical vulnerability and recommended immediate updating. Days earlier, 7.1.1 had included multiple security fixes. These notices show that no combination of headers can compensate for vulnerable core software or an outdated plugin. Headers belong inside a broader strategy: updates, least privilege, verified backups, plugin governance, logs, monitoring, HTTPS, and third-party review. Security Inspector helps observe public posture; internal hardening completes what cannot be determined from the outside. ## Key takeaways - Measure real headers before changing configuration. - Enable HSTS only after verifying HTTPS and subdomains. - Build CSP from an inventory and start with Report-Only. - Test checkout, payments, login, forms, and external resources. - Evaluate Trusted Types progressively on compatible sites. - Aggregate browser reports to reduce noise. - Keep WordPress, themes, and plugins current: headers do not replace patches. ## Sources - [WordPress 7.1.2 Security Release](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/) — WordPress.org - [WordPress 7.1.1 Maintenance and Security Release](https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/) — WordPress.org - [OWASP Secure Headers Project](https://owasp.org/projects/secure-headers-project) — OWASP - [OWASP HTTP Headers Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) — OWASP - [MDN Permissions Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Permissions_Policy) — MDN - [MDN Trusted Types CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/require-trusted-types-for) — MDN - [MDN Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API) — MDN ## External resources - [OWASP Secure Headers Project](https://owasp.org/projects/secure-headers-project): Reference project for understanding and verifying defensive HTTP headers. - [MDN Trusted Types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/require-trusted-types-for): Reference for the CSP require-trusted-types-for directive, Baseline 2026. - [WordPress 7.1.2](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/): Current WordPress security notice published on September 22, 2026. ## Related product - [Website Security Audit](https://kairoseth.com/products/security-inspector): Authorized passive website security audit with risk prioritization and remediation guidance. - [Custom request](https://kairoseth.com/custom-requests)