Add Important HTTP Security Headers to WordPress
Security headers are instructions sent by your website alongside its normal HTTP response. Instead of changing the visible content of the page, they tell the visitor's browser how certain security-sensitive situations should be handled.
For example, a header can tell the browser not to allow another website to display your page inside an iframe. Another can prevent the browser from guessing a different MIME type for a file. Referrer Policy can control how much information is sent when someone follows a link to another website, while HSTS can tell browsers to continue using HTTPS for future connections.
These protections are normally configured through Apache, NGINX, a CDN, hosting control panel, or custom WordPress code. WP PowerSuite Security Headers brings the most useful controls into WordPress, making it easier to maintain a consistent configuration without editing server files for every site.
The module deliberately does not enable every possible security header automatically. Some headers can significantly affect how a website works, so WP PowerSuite separates sensible defaults from advanced policies that should be configured according to the site's actual requirements.
Protect Against Clickjacking With X-Frame-Options
Clickjacking involves displaying a website inside a frame controlled by another site and potentially misleading a visitor into interacting with content they did not realize they were using.
Security Headers enables:
<X-Frame-Options: SAMEORIGIN>This tells compatible browsers that your pages may only be framed by pages from the same origin, helping prevent unrelated external websites from embedding your WordPress pages.
For many standard WordPress sites, this is a useful default. However, websites that intentionally need to be embedded by another domain should review this setting before enabling it. A third-party application, portal, LMS, preview system, or another service that legitimately embeds your site in an iframe may stop working when SAMEORIGIN is enforced.
Security headers are most effective when they reflect how the website is actually used rather than being enabled blindly.
Prevent Browser MIME Sniffing
Web servers normally send a content type describing what a resource is, such as an image, stylesheet, JavaScript file, or HTML document.
Some browsers have historically attempted to infer or "sniff" a different content type when they believe the declared type may be incorrect. In certain situations, interpreting content differently from how the server intended can introduce security problems.
WP PowerSuite enables:
<X-Content-Type-Options: nosniff>This instructs supporting browsers to respect declared MIME types rather than attempting certain forms of content-type guessing. It is a straightforward security header with relatively low configuration overhead, making it suitable as one of the module's default protections.
As with all security settings, your server should still provide correct MIME types for the files it serves. The header complements correct server configuration rather than replacing it.
Control Referrer Data With Referrer-Policy
When someone follows a link from your website to another page or domain, their browser may send information about the page they came from in the HTTP Referer header.
Referrer-Policy gives you control over how much of that information is shared.
Security Headers enables Referrer-Policy by default using:
<strict-origin-when-cross-origin>This provides a practical modern balance. Same-origin navigation can retain useful referrer information, while cross-origin requests generally expose only the origin rather than the complete page URL, and information is restricted further when moving to less secure destinations.
WP PowerSuite also provides several alternative policies, ranging from the privacy-focused no-referrer to more permissive options such as unsafe-url.
This allows developers and site owners to choose a policy appropriate for their analytics, privacy, integration, and security requirements rather than forcing one configuration onto every WordPress site.
Enforce HTTPS With HSTS
HTTP Strict Transport Security, commonly known as HSTS, tells a browser that a website should be accessed through HTTPS for a specified period.
Once a browser receives the HSTS header over a valid HTTPS connection, it can automatically prefer HTTPS for future requests to that domain. This can help protect against certain downgrade scenarios where a visitor might otherwise attempt an insecure HTTP connection first.
Because HSTS has persistent browser-side consequences, WP PowerSuite keeps it disabled by default.
When enabled, you can configure the max-age value up to two years and optionally include subdomains. The header is emitted only when WordPress detects an SSL connection, and the settings interface warns when the website itself is not currently using HTTPS.
Before enabling Include Subdomains, make sure every relevant subdomain supports HTTPS correctly. Otherwise, browsers that receive the policy may refuse to connect to an HTTP-only subdomain until the HSTS period expires.
WP PowerSuite deliberately does not add the HSTS preload directive. HSTS preloading involves additional long-term considerations and should be managed separately when a site intentionally participates in browser preload programs.
