Add HTTP Security Headers in WordPress: HSTS Plugin Best Practice

Direct answer: A WordPress site should usually send HSTS, Content-Security-Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Add them at the server, CDN, or application layer, validate every security header in staging, then roll out gradually so login, checkout, analytics, and embedded assets keep working.

A security header is a small instruction sent with http response headers. It tells browsers how to handle framing, MIME sniffing, referrer data, transport security, and script loading. WordPress does not automatically configure every recommended security header because each hosting stack, CDN, cache, theme, and third-party script mix is different. That is why configuring http needs a plan instead of a random snippet copied into production.

This guide explains the purpose of HTTP security headers in WordPress, the commonly used HTTP security headers, a recommended header set, Apache .htaccess and Nginx examples, adding headers in WordPress using a controlled extension path, validation steps, and rollout risk. The goal is basic protection using HTTP security headers without breaking forms, media, tracking, or admin workflows.

Purpose of HTTP Security Headers in WordPress

HTTP security headers can help reduce browser-side risk by setting rules before a visitor interacts with the page. They do not replace patching, backups, malware cleanup, or access control, but they add an additional layer of security and an extra layer of security for every request. Used carefully, security headers can help improve the website’s security and the security of your WordPress site.

Commonly Used HTTP Security Headers

Recommended WordPress Security Headers

A conservative header set starts with transport, framing, MIME, referrer, permissions, and a measured CSP. For the header set Content-Security-Policy first, use report-only logs to see which domains the theme, editor, analytics, fonts, payment widgets, and embeds require. That approach is the best practice because implementing HTTP security headers too aggressively can lead to security vulnerabilities being replaced by broken business workflows.

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Do not preload HSTS until you know the site can only be accessed over HTTPS across the full domain portfolio. Old links, like HTTP, should redirect to HTTPS instead of HTTP, and any http to https chain should be short. The rule affects future http communication in the browser, so a mistake can be sticky for returning visitors.

Adding HTTP Headers with Apache .htaccess

If the site runs on Apache and allows overrides, the htaccess file can add the HTTP header rules. Add the security headers to your WordPress environment in staging first, then promote through version control or a managed hosting control panel. This example shows header always usage only where it matters most.

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';"
</IfModule>

Apache rules should be tested with cache bypassed. If the CDN also sets the same security header, choose one owner. Duplicate policies can be hard to debug because the browser enforces the strictest combined behavior.

Configuring HTTP Headers with Nginx

On Nginx, add_header directives usually belong in the server block or a shared include maintained by the host. This is often cleaner than editing application files because the web server sends the response before PHP finishes rendering the page.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';" always;

After the reload, check normal pages, redirects, 404 templates, admin login, REST API responses, and cached HTML. Security headers are sent only when the active layer includes them, so a cache rule or error page can accidentally omit an important security header.

Headers in WordPress Using a Plugin

If you cannot edit Apache, Nginx, or CDN settings, using a WordPress plugin can be an option to add HTTP security at the application layer. Choose a security plugin that lets you review exact values, export configuration, and disable overlapping modules. WordPress security plugins sometimes include advanced security features beyond headers; use only the controls you need.

A good extension path helps teams add HTTP security headers while preserving rollback. Using a WordPress plugin may be acceptable on shared hosting, but a server-level owner is usually stronger for HSTS and cache consistency. If you want to add HTTP security changes without server access, document the setting, owner, date, and expected output.

Check HTTP Security Headers Before Rollout

1. Check HTTP security headers with curl, browser DevTools, and an external header scanner.
2. Confirm the same security header appears on the homepage, article pages, admin login, redirects, and error templates.
3. Test forms, search, comments, checkout, maps, videos, fonts, analytics, and tag-manager events.
4. Run CSP in report-only mode before enforcement, then remove unnecessary third-party sources.
5. Enable HSTS after certificate coverage, redirects, www/non-www, subdomains, and CDN behavior are verified.
6. Keep a rollback path so adding these headers can be reversed quickly if revenue-critical functionality fails.

Headers protect visitors only when they are present on the response they receive. Add security headers to your site, then check headers on your WordPress website from the public edge, not only from the origin server. That is also how to verify headers to your website after CDN cache rules or hosting changes.

Best Practice Rollout Risks

The primary risk is a strict CSP or premature HSTS rollout. A strict CSP can block inline scripts, payment frames, font providers, marketing tags, or media embeds. Premature HSTS can lock users into HTTPS before every hostname is ready. These problems are avoidable when you add the HTTP security headers in stages and keep report data for each change.

Another risk is ownership confusion. A CDN, host, Apache include, Nginx include, cache layer, and application extension can all implement security headers. Pick one owner for each security header, document it in the WordPress hosting account notes, and remove duplicates. This improves the security of your WordPress estate without creating invisible conflicts.

Implementation Notes for Teams

HTTP Strict Transport Security is the formal transport rule behind the common strict-transport-security value. Content Security Policy is the policy family behind CSP, and it deserves extra review because one blocked response header can break a script, form, frame, font, or API call. Adding HTTP headers and configuring HTTP headers should be treated as a change-management task, not a cosmetic tweak. Recommended security headers are easiest to maintain when HTTP security headers work best: one owner controls each rule, one person reviews the logs, and one rollback note explains how to remove a bad security header quickly.

For comprehensive security, use headers with patching, backups, least-privilege accounts, malware monitoring, and WAF rules. WordPress HTTP security headers are not a full firewall, but they help protect your WordPress site and improve the security posture visitors experience in the browser. If the WordPress site using a cache or CDN serves stale output, purge it before checking the website’s security headers. Teams that rely on a WordPress security plugin should still record the exact setting and confirm the same security header appears at the public edge.

For improving your site’s security, review security headers on your WordPress install after theme changes, checkout changes, marketing tag changes, and hosting migrations. Security headers on your WordPress website should align with HTTP headers to your website at the CDN and origin. That keeps the WordPress site’s security visible, testable, and easier to maintain.

For broader hardening, connect this guide to WordPress security hardening, common website security threats, and the WordPress security checklist for small businesses.

FAQ

Which security headers does a WordPress site need?

A WordPress site should usually send HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and a framing control such as frame-ancestors or X-Frame-Options.

Can I add HTTPS security headers with a plugin?

Yes, you can add HTTPS security headers with an extension when server access is unavailable, but server or CDN configuration is usually more consistent for cached pages and redirects.

Should I use X-Frame-Options or CSP frame-ancestors?

Use frame-ancestors in CSP as the modern control, and keep X-Frame-Options when you need older browser support. Avoid conflicting values.

Is HSTS safe for every website?

No. Enable HSTS only when HTTPS, redirects, certificates, subdomains, and CDN behavior are stable. Consider preload only after a separate readiness review.

Can security headers break a site?

Yes. A strict CSP can block scripts, styles, frames, or API calls. Roll out in report-only mode, validate business-critical pages, and keep rollback instructions.

To implement security headers cleanly, start with staging, choose one configuration owner, validate the output, then add them to your WordPress production stack. Security headers to your WordPress site are a practical layer of security, and headers to your WordPress website should be reviewed after every hosting, CDN, theme, or major extension change.