Web Server Security Headers Checklist: 8 Checks (2026)

TLS makes the connection private. Security headers decide what the browser does once the page arrives: whether it will run an inline script, whether it will let another site frame you, whether it will hand your session cookie to JavaScript. This page documents the 8 checks in the CtrlOps Security Headers audit, in the order the audit runs them.

Every threshold below is transcribed from the audit script itself. The one mechanism worth understanding before reading the rest: this audit reads the live response, not just the config. It curls loopback and sends your configured server_name as the Host header, so the headers it grades are the ones your actual vhost returns, rather than whatever the default server block happens to send.

Key takeaways

Eight checks, no root needed for any of them, and only one can fail outright.

• Five are MEDIUM: HSTS, frame protection, CSP, CORS and cookie flags. Three are LOW: nosniff, referrer policy and permissions policy.
• None need sudo. Every check reads config text and an HTTP response, which any account can do. This is the one audit in the catalog you can run without elevated access at all.
• Only HSTS and CORS have a FAIL branch. Everything else warns, because a missing header is a missing improvement rather than an active misconfiguration.
• A config-only pass is a weaker statement than a live pass. Where the probe cannot reach the server, findings are suffixed "no live response, config only" and the check grades what the config says instead. Read that suffix.
• The whole audit takes about 10 seconds when CtrlOps runs it over your existing SSH connection, against roughly 3 minutes of curl and grep per host by hand.

Check 1: Is HSTS configured with a long enough max-age?

Strict-Transport-Security tells the browser to use HTTPS for this host and refuse to fall back, for as long as max-age says. Without it, the first request of every session is plain HTTP, and anyone in a position to intercept it can serve a downgraded copy of your site before the redirect ever happens.

The audit reads the header off the live response and compares max-age against 15552000 seconds, which is six months. Below that, the protection window is short enough that a visitor who has not been back in a while is unprotected again.

How to check manually

curl -sI https://yourdomain.com | grep -i 'strict-transport-security'

How to fix it

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

The always keyword in Nginx matters: without it the header is omitted on error responses, which is exactly when a downgrade attempt is most likely to be in play.

Check 2: Does the server send X-Content-Type-Options nosniff?

X-Content-Type-Options: nosniff tells the browser to trust the declared Content-Type and stop guessing. Without it, a browser may inspect a file's contents and decide that the .txt a user uploaded is really JavaScript, then execute it in your origin.

The audit looks for the header on the live response, then falls back to looking for it in the effective config.

How to check manually

curl -sI https://yourdomain.com | grep -i 'x-content-type-options'
grep -rn 'X-Content-Type-Options' /etc/nginx/ /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -v '#'

How to fix it

add_header X-Content-Type-Options "nosniff" always;

Header always set X-Content-Type-Options "nosniff"

Check 3: Can your pages be framed by another site?

Clickjacking works by loading your page in an invisible frame on an attacker's site and positioning their controls over yours, so the victim's click lands on your "confirm" button while they believe they are clicking something else. Two headers prevent it: the older X-Frame-Options, and the frame-ancestors directive inside a Content Security Policy.

The audit accepts either. It checks the live response for X-Frame-Options or a CSP containing frame-ancestors, then falls back to the config text.

How to check manually

curl -sI https://yourdomain.com | grep -iE 'x-frame-options|content-security-policy'

How to fix it

# The modern form, and the one that wins where both are present
add_header Content-Security-Policy "frame-ancestors 'self';" always;

# The older header, still worth sending for legacy clients
add_header X-Frame-Options "SAMEORIGIN" always;

Header always set Content-Security-Policy "frame-ancestors 'self';"
Header always set X-Frame-Options "SAMEORIGIN"

Check 4: Is a Content Security Policy in place?

A Content Security Policy names the origins a page may load scripts, styles, images and frames from. It is the difference between an XSS bug that steals a session and an XSS bug that fails because the injected script has nowhere to load from and no permission to run inline.

The audit grades presence and quality together. A CSP containing unsafe-inline, unsafe-eval or a wildcard is reported as present but permissive, because in practice those three let most real payloads through.

How to check manually

curl -sI https://yourdomain.com | grep -i 'content-security-policy'

That first warning catches the most common outcome of adopting CSP: a policy written to stop breaking the site, tuned until nothing was blocked, which is another way of saying nothing is blocked.

How to fix it

Start in report-only mode so violations are logged rather than enforced:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; report-uri /csp-report" always;

Then tighten and switch to enforcing:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self';" always;

Inline styles are the usual last holdout. Keeping 'unsafe-inline' on style-src while script-src stays clean is a reasonable intermediate state, and the audit will still warn, correctly, that the policy is permissive.

Check 5: Does the server control referrer leakage?

When a visitor follows a link off your site, the browser tells the destination where they came from. By default that is the full URL, including the path and query string, which routinely carries password reset tokens, search terms, internal document ids and customer identifiers.

The audit looks for a Referrer-Policy header on the live response, then in the config. It does not grade the value, because any explicit policy is a decision and the absence of one is not.

How to check manually

curl -sI https://yourdomain.com | grep -i 'referrer-policy'

How to fix it

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Header always set Referrer-Policy "strict-origin-when-cross-origin"

strict-origin-when-cross-origin keeps the full URL for same-origin navigation, which analytics needs, and sends only the origin to other sites. It is the modern browser default, but defaults change and an explicit header is what makes the behaviour yours.

Check 6: Is Permissions Policy limiting browser APIs?

Permissions-Policy decides which browser capabilities a page and its embedded frames may even ask for: camera, microphone, geolocation, payment handlers and more. Without it, every third-party script on the page, the chat widget, the analytics tag, the ad slot, is free to prompt your visitor for their location or their camera.

The audit accepts Permissions-Policy or the older Feature-Policy spelling, from the live response or the config.

How to check manually

curl -sI https://yourdomain.com | grep -i 'permissions-policy'

How to fix it

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;

Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

An empty allowlist denies the feature everywhere, including to your own page. If the site genuinely uses one, name the origins that may: geolocation=(self).

Check 7: Are the CORS headers safely scoped?

Access-Control-Allow-Origin relaxes the browser's same-origin policy and names who may read your responses. A wildcard is correct for a genuinely public read-only API and wrong for anything behind a session. A wildcard combined with Access-Control-Allow-Credentials: true is the dangerous case: it is a request for any site on the internet to make authenticated requests on your users' behalf.

The audit reads both headers from the live response and grades the combination.

How to check manually

curl -sI -H "Origin: https://example.org" https://yourdomain.com | grep -i 'access-control'

One caveat that matters for API servers: the probe requests /, so a CORS policy that only applies under /api/ will show up as the "configured but none came back" warning rather than being graded properly. That warning is a prompt to check the route yourself, not a finding about the root path.

How to fix it

# Name the origins rather than reflecting whatever arrives
map $http_origin $cors_origin {
    default "";
    "https://app.example.com" $http_origin;
    "https://admin.example.com" $http_origin;
}

add_header Access-Control-Allow-Origin $cors_origin always;
add_header Access-Control-Allow-Credentials "true" always;

The pattern to avoid is reflecting the incoming Origin header back unconditionally. It looks like a specific origin in every test you run, and it is a wildcard in practice.

Check 8: Do cookies carry HttpOnly, Secure and SameSite?

Three flags decide how much damage a cookie can do once something goes wrong. HttpOnly keeps it out of reach of JavaScript, so an XSS bug cannot read the session. Secure stops it being sent over plain HTTP. SameSite stops it riding along on cross-site requests, which is most of what CSRF needs.

The audit reads every Set-Cookie header on the probed response and reports which of the three are missing across them.

How to check manually

curl -sI https://yourdomain.com | grep -i 'set-cookie'

That second skip is the important one to read correctly. Most applications only issue a session cookie after authentication, so a skip here means the audit never saw the cookie you actually care about, not that your cookies are clean.

How to fix it

Cookie flags normally belong to the application that sets the cookie, so fix them there first. Where a proxy sits in front of an application you cannot change:

# nginx 1.19.3 and later
proxy_cookie_flags ~ httponly secure samesite=lax;

Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure; SameSite=Lax"

What this audit does not cover

This audit reads HTTP response headers and the config that sets them. It does not check:

• TLS itself. Protocol versions, cipher suites, certificate expiry and the HTTPS redirect are the TLS Configuration audit.
• What the server exposes. Directory listing, dotfiles, backup files and status endpoints are the Content Exposure audit.
• Server configuration hardening. File permissions, web root ownership, request limits and rate limiting are the Configuration Hardening audit.
• Versions and patching. Server inventory, version disclosure, worker user and pending updates are the Identification and Patching audit.
• Headers set at a CDN. If Cloudflare, CloudFront or Fastly adds or strips headers at the edge, this audit sees the origin response, which is the one your CDN forwards from but not necessarily the one your visitors receive.
• Application-set headers on other routes. The probe requests the root path of one vhost. A header set only on /api/ is not seen.

The manual audit problem at scale

Checking eight headers by hand on one server is about three minutes, if you remember the header names and have a shell open. Across ten servers it is half an hour, the results live in terminal scrollback, and the question nobody can answer afterwards is which of the ten was the one missing CSP.

The subtler problem is the vhost. curl -sI https://127.0.0.1/ answers from the default server block, which on a name-based server is not the site you meant to test, so a manual check can report missing headers that are in fact present, or present headers that your real vhost never sends.

How CtrlOps runs all 8 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Security Headers audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Security Headers

Choose it from the Web Server category. All 8 checks are listed with their descriptions, severity levels and the estimated run time, about 10 seconds in total. None of them need root, which is unusual in this catalog and worth knowing if you audit with a restricted account.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table with the header value it actually saw, or the note that only the config could be read

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here because add_header in Nginx replaces the inherited set for that block rather than adding to it, and a fix applied in the wrong place silently drops the headers you already had.

Step 6: Re-run and compare

Run the same audit again after reloading and watch the score move. This audit is fast enough to run as the last step of a deployment, which is the point at which a changed proxy config quietly stops forwarding a header.

Conclusion

Security headers are the cheapest hardening on a web server and the most often skipped, because nothing breaks when they are missing. The site works, the padlock appears, and the only evidence is a report nobody runs.

One failure on this page is an active misconfiguration: a wildcard CORS policy with credentials. The rest are absences, and each one is a single line of config. The CtrlOps Security Audit runs all 8 in about 10 seconds per server, against the real vhost rather than the default one.

The neighbouring checklists cover the other web server layers: TLS configuration, content exposure, configuration hardening, identification and patching and logging and monitoring.

Frequently asked questions