When we do a site audit for a new client, one of the first things we check is HTTP security headers. Most sites — including well-maintained ones — are missing several of them entirely. It's not a crisis, but it is a gap worth closing: these headers tell browsers exactly how to handle your content, and without them your site relies solely on application-level code to stay secure, with no browser-enforced safety net backing it up.
SSL covers the transport layer. Security headers cover everything the browser does once the content arrives. Both matter. Here's what each header does and how to add them.
What Are HTTP Security Headers, Exactly?
Every time a browser requests a page, your server sends back a response that includes HTTP headers — metadata packets carrying instructions. Most handle mundane stuff: content type, caching, encoding. Security headers are different: they tell the browser how to handle your content in ways that close down well-known attack vectors.
Without them, your browser is operating on the honor system. With them, you give it a strict rulebook: trust scripts from these sources only, never embed this page in an iframe on another domain, always use HTTPS. The browser becomes an enforcer, not just a renderer.
The Six Headers Every Site Should Have
1. Strict-Transport-Security (HSTS)
HSTS tells browsers: this site is HTTPS only, full stop. Once seen, the browser will never attempt a plain-text connection to your domain. This kills SSL-stripping attacks where a man-in-the-middle downgrades your connection before you realize it.
For Apache, add this inside your .htaccess file: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
For Nginx, add to your server block: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
The preload directive lets you submit your domain to the browser-maintained HSTS preload list at hstspreload.org. Once listed, browsers enforce HTTPS before they've ever visited your site. Just make sure your SSL is airtight first — there's no easy opt-out once you're on the list.
2. X-Frame-Options
This header prevents your pages from being embedded in iframes on other domains. Without it, a malicious site can load your login page invisibly inside a transparent iframe and capture your users' clicks — that's clickjacking, and it's been reliably working on unprotected sites since the early 2000s.
The fix: Header always set X-Frame-Options "SAMEORIGIN" — or DENY if you have no legitimate use of iframes on your own site (stronger).
3. X-Content-Type-Options
This stops browsers from second-guessing your declared content types. Without it, a browser might decide a text file "looks like JavaScript" and execute it — a behavior called MIME-sniffing that's been exploited in real-world attacks. The fix is a single line: Header always set X-Content-Type-Options "nosniff"
4. Referrer-Policy
When a visitor clicks an outbound link, the browser tells the destination where they came from. That's mostly fine, but you don't want to leak internal URLs or query strings that contain user data. strict-origin-when-cross-origin is the modern best practice — it sends referrer info for same-origin requests but strips the path and query string when linking to other domains.
Add: Header always set Referrer-Policy "strict-origin-when-cross-origin"
5. Permissions-Policy
Formerly known as Feature-Policy, this controls which browser APIs your site and any embedded iframes can access. If you have no legitimate need for geolocation, microphone, or camera access, explicitly disable them. This prevents malicious injected scripts from silently hijacking those features.
A sensible default: Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
6. Content-Security-Policy (CSP)
CSP is the most powerful header on this list — and the most nuanced. It lets you define a whitelist of exactly which sources of scripts, styles, fonts, and images are trusted. This is the primary browser-level defense against Cross-Site Scripting (XSS) attacks, where attackers inject malicious scripts into your pages.
The critical thing: don't deploy CSP in enforcement mode on day one. Start with Content-Security-Policy-Report-Only — it logs violations without blocking anything, so you can see which legitimate sources you'd accidentally break before you go live with enforcement. A WordPress site using Google Fonts and Google Tag Manager will need a handful of extra whitelist entries.
How to Add These to a WordPress Site
You've got three practical options, listed from most to least reliable:
- Server config (best): Apache sites use
.htaccess; Nginx requires editing the server block directly. This approach survives plugin updates, WordPress core updates, and everything else. Set it and forget it. - Cloudflare Transform Rules: If you're already behind Cloudflare, you can inject most headers via their Transform Rules UI — no server access required. A solid middle-ground option.
- WordPress plugin: Plugins like Headers Security Advanced & HSTS WP handle the basics through a UI. Convenient if you lack direct server access, though server-level config is always more reliable long-term.
If your site runs on Microcomp's managed hosting, security headers are configured at the server level from day one — no plugin to install, no configuration drift, no 2 AM surprises after an auto-update.
How to Verify Your Headers
The most straightforward way to inspect what your server is sending is with curl from the command line. Run curl -I https://yourdomain.com and the response will list every HTTP header your server returns. You can see immediately which security headers are present and what values they carry — no third-party service required.
Browser DevTools work just as well for a quick check. Open the Network tab, reload the page, click the document request at the top of the list, and look at the Response Headers panel. Every header is listed there, and you can verify your changes took effect without sending your domain anywhere.
Worth knowing: several public scanning tools log the domains they receive and display them in leaderboards or recent-scan feeds. For client sites, we stick to local verification methods for this reason.
Implementing HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy covers most of the ground and takes around fifteen minutes at the server level. Layer in CSP once the basics are confirmed working.
The SEO Connection
Google has used HTTPS as a ranking signal since 2014. Security headers are less direct, but they matter indirectly: a compromised site can end up serving malicious third-party scripts that inflate page weight and degrade Core Web Vitals. Keeping your server properly configured reduces that attack surface. It's also worth noting that AI crawlers powering features like Google AI Overviews and Perplexity favor sources that signal technical credibility — a well-configured server is part of that picture.
Need a Hand With the Configuration?
Security headers aren't complicated, but CSP in particular requires careful setup — a misconfigured policy can break legitimate site features. When we onboard a new client to our maintenance and support plans, a header audit is part of the process. We configure everything at the server level so there's nothing extra to maintain on the WordPress side. If you'd like us to take a look at your current setup, get in touch.