Your Website Has an Invisible Security Layer (or It Should)
When someone visits your website, their browser and your server exchange a set of HTTP headers before any page content is rendered. Most of these headers are mundane — content type, cache instructions, encoding. But a special subset of headers exists specifically to tell the browser how to protect your visitors.
These are security headers, and most websites are missing at least half of them.
Security headers do not require code changes to your application. They are server configuration directives that instruct browsers to enable built-in protections against clickjacking, cross-site scripting (XSS), protocol downgrade attacks, data sniffing, and other common threats. Adding them is one of the highest-impact, lowest-effort security improvements you can make.
The Security Headers That Matter
There are nine security-related checks that a thorough website health scanner examines. Here is what each one does, why it matters, and what a properly configured version looks like.
1. SSL Certificate (HTTPS)
What it does: SSL/TLS encrypts the connection between your visitor's browser and your server. Without it, login credentials, form submissions, and browsing behavior are transmitted in plain text where anyone on the network can read them.
Why it matters: Browsers now display "Not Secure" warnings for sites without HTTPS. Google has used HTTPS as a ranking signal since 2014. Beyond SEO, SSL is the baseline requirement for every other security header — most modern protections require HTTPS to function.
What to check: Ensure your site loads via https:// and that the certificate is valid, not expired, and covers all subdomains you use.
2. HTTPS Redirect
What it does: Even if your site has a valid SSL certificate, visitors who type your domain without https:// or follow old HTTP links will land on the unencrypted version unless your server redirects them. An HTTPS redirect ensures all HTTP requests are automatically forwarded to the secure version.
Why it matters: Without a redirect, you are running two versions of your site — one secure and one not. Browsers, search engines, and link-sharing services may reference either one. A proper redirect consolidates all traffic to HTTPS.
How to implement:
# Nginx — redirect all HTTP to HTTPS
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
3. Strict-Transport-Security (HSTS)
What it does: HSTS tells the browser "for the next N seconds, always connect to this domain over HTTPS — even if the user types http:// or clicks an HTTP link." The browser upgrades the request to HTTPS before sending it, eliminating the brief HTTP request that a redirect still allows.
Why it matters: Without HSTS, the first request to your site on each session could be over HTTP. An attacker on a public Wi-Fi network could intercept that first request (a "protocol downgrade attack") before the redirect kicks in. HSTS closes this window completely.
Recommended header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
This tells browsers to enforce HTTPS for one year, including all subdomains. The preload directive submits your domain for inclusion in browser preload lists, which enforce HTTPS even on the very first visit.
4. Content-Security-Policy (CSP)
What it does: CSP specifies which sources of content (scripts, styles, images, fonts, frames, etc.) the browser should trust. If an attacker injects a malicious script into your page, CSP prevents it from executing because it was not loaded from an approved source.
Why it matters: Cross-site scripting (XSS) remains one of the most common web vulnerabilities. CSP is the most effective browser-side defense because it does not rely on your application code being bug-free — it adds a blanket policy that blocks unauthorized content regardless of how it got there.
Example header:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'
CSP can be complex to configure because every external resource your site uses needs to be explicitly allowed. Start with a report-only mode (Content-Security-Policy-Report-Only) to identify violations before enforcing the policy.
5. X-Frame-Options
What it does: X-Frame-Options controls whether your site can be embedded in an <iframe> on another domain. Setting it to DENY or SAMEORIGIN prevents clickjacking attacks, where an attacker overlays your site inside an invisible frame and tricks users into clicking things they cannot see.
Why it matters: Clickjacking can trick users into unknowingly changing account settings, making purchases, or granting permissions. Banking sites, admin panels, and any site with authenticated actions are primary targets.
Recommended header:
X-Frame-Options: DENY
Use SAMEORIGIN if your site legitimately needs to be framed by pages on the same domain (e.g., an admin panel within your own app).
6. X-Content-Type-Options
What it does: This header prevents the browser from "MIME sniffing" — guessing the content type of a response when the server-provided type seems wrong. Without it, a browser might interpret a text file as executable JavaScript.
Why it matters: MIME sniffing can turn a harmless file upload into a security vulnerability. If an attacker uploads a file that the server labels as text/plain but contains JavaScript, some browsers will execute it anyway.
Recommended header:
X-Content-Type-Options: nosniff
This is a single value, no configuration needed. There is no reason not to set it on every site.
7. Referrer-Policy
What it does: Referrer-Policy controls how much referrer information is included when users navigate away from your site. Without it, the full URL of the page they were on — potentially including query parameters with sensitive data — is sent to the next site.
Why it matters: URLs sometimes contain session tokens, search queries, or user identifiers in query parameters. Leaking these to third-party sites is a privacy risk. A restrictive Referrer-Policy keeps this data within your own domain.
Recommended header:
Referrer-Policy: strict-origin-when-cross-origin
This sends the full referrer for same-origin requests (useful for your own analytics) but only the origin (domain) for cross-origin requests.
8. Permissions-Policy
What it does: Permissions-Policy (formerly Feature-Policy) lets you control which browser features your site and its embedded content can use. You can disable camera access, microphone, geolocation, payment APIs, and more — either for your own site or for iframes embedded within it.
Why it matters: If your site does not use the camera, there is no reason to leave camera access enabled. Disabling unused features reduces your attack surface. More importantly, it prevents embedded third-party content (ads, widgets, iframes) from abusing these permissions.
Example header:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
The empty parentheses mean "disabled for all origins." If a feature is needed, you can allowlist specific origins.
9. Mixed Content
What it does: Mixed content occurs when a page served over HTTPS loads sub-resources (images, scripts, stylesheets, iframes) over plain HTTP. This is not a header you add — it is a problem you fix by ensuring all resources use HTTPS URLs.
Why it matters: Mixed content undermines HTTPS protection. An attacker can intercept the HTTP resources and replace them with malicious versions. Modern browsers block mixed active content (scripts, iframes) outright and display warnings for mixed passive content (images). Either way, it erodes user trust.
How to fix: Search your HTML and CSS for any http:// resource URLs and replace them with https:// or protocol-relative // URLs. Use the browser console to identify mixed content warnings, or run a scan to catch them automatically.
How to Check Your Security Headers
You can check your security headers manually by opening browser DevTools, navigating to the Network tab, clicking the main document request, and reading the response headers. But this only tells you what headers are present — it does not tell you whether they are configured correctly or what you are missing.
PageVital checks all nine security items listed above in a single scan: SSL validity, HTTPS redirect, HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and mixed content detection. Each check returns a pass, warning, or fail status along with a specific recommendation for what to fix.
The security category carries 25 percent of your overall health score. Each check is severity-weighted — SSL and HTTPS redirect are critical severity (weight ×3), CSP and HSTS are high severity (weight ×2), and policy headers like Referrer-Policy and Permissions-Policy are medium to low severity. This means fixing your SSL and HTTPS configuration produces a much larger score improvement than adding a Permissions-Policy header — which matches the real-world risk hierarchy.
Adding Security Headers to Your Server
The exact method depends on your hosting setup.
Apache (.htaccess)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
Vercel (vercel.json)
{
"headers": [
{
"source": "/(.*)",
"headers": [
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
{ "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains; preload" }
]
}
]
}
Cloudflare
Cloudflare automatically enforces HTTPS and provides HSTS settings in the SSL/TLS section of your dashboard. For other headers, use Transform Rules or a Cloudflare Worker.
A Security Header Implementation Plan
If your site is missing most headers, do not try to add them all at once. Here is a practical order:
-
SSL + HTTPS Redirect — The foundation. Nothing else works without this. Most hosting providers offer free SSL through Let's Encrypt.
-
HSTS — Once HTTPS is working reliably, enforce it with HSTS. Start with a short max-age (one hour) and increase to one year after confirming everything works.
-
X-Content-Type-Options — A one-liner with no configuration. Add
nosniffimmediately. -
X-Frame-Options — Set to
DENYunless your site needs to be framed. Instant clickjacking protection. -
Referrer-Policy — Set
strict-origin-when-cross-originas a safe default. -
CSP — The most complex header. Deploy in report-only mode first, review violations for a week, then tighten the policy.
-
Permissions-Policy — Disable features you do not use.
After implementing each header, run a scan with PageVital to verify the changes took effect. The security category in your health report shows exactly which checks pass and which still need work. Aim for all nine checks passing — it is achievable for any site and earns a category score in the A range (90 or above).
Security Headers Are Not Optional
HTTP security headers are one of the few things in web development where the implementation cost is low, the maintenance burden is minimal, and the protection they provide is significant. They cannot prevent every attack, but they raise the bar dramatically — and they signal to browsers, search engines, and your visitors that you take security seriously.
Check your security headers now with a free PageVital scan. You will see which of the nine checks your site passes, which it fails, and exactly what to configure to close the gaps.