How to Fix Missing Security Headers Flagged in a Vulnerability Scan

What a missing security headers finding means

HTTP security headers are instructions your server sends with every response, telling the browser how to handle the page: always use HTTPS, which scripts may run, whether the page may be framed by another site, and how much of the URL to share when a visitor clicks away. They cost nothing to add and protect against whole classes of attack, such as clickjacking, content-type confusion and some cross-site scripting.

A vulnerability scanner or penetration test reports a finding such as Missing HTTP security headers when one or more of these is absent, or when a header is present but has a value the browser will ignore, often reported as security header is not valid. On its own, a missing header is usually rated low or informational, because it does not create a hole by itself. It removes a layer of protection that would limit the damage if something else went wrong.

That rating matters for how you respond. You do not need to take the site offline, but you should fix it, because the fix is quick, and because insurers, clients and compliance checklists increasingly expect to see these headers.

Which security headers matter, and their valid values

These are the headers most scanners check for, with a safe starting value for a typical small business site.

Two older headers still appear in some scan reports. X-XSS-Protection controlled a filter that modern browsers have removed; current advice is to omit it or send 0, so if a scanner asks for 1; mode=block, note that the recommendation is outdated. Feature-Policy was replaced by Permissions-Policy, which uses a different syntax.

How to check security headers on your site

The quickest check is from the command line, which shows exactly what the server sends:

curl -sI https://www.example.com/ | grep -iE 'strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy'

Any header missing from the output is missing from the response. Run the same check on a few different URL types, because headers are often set for some responses and not others:

for u in / /contact/ /wp-login.php /images/logo.png /no-such-page; do
  echo "== $u"; curl -sI "https://www.example.com$u" | grep -icE 'strict-transport|x-frame|x-content-type'
done

A count that drops for the 404 or the image tells you the headers are being added by the application rather than the server, or only on successful responses.

Checking security headers online

If you would rather not use a terminal, an online checker fetches the page and grades each header. Our security audit lists missing and invalid headers with the value it found, and Mozilla's HTTP Observatory is a well-known free alternative. In the browser, open DevTools, go to the Network tab, reload, click the first document request and read the Response Headers section.

Why a security header is not valid

A header that is present but wrongly written is treated by the browser as if it were missing. These are the mistakes scanners flag most often:

Duplicates are the hardest to spot. They happen when the application, a plugin, the web server and the CDN each add the same header. Check with curl -sI and count the lines for each header name; there should be one.

A Content Security Policy needs more care than the others, because a strict one can block your own scripts, analytics or payment forms. Roll it out with Content-Security-Policy-Report-Only first, as the CSP report-only guide explains.

Adding the headers at server, CDN or CMS level

Add the headers in one place, as close to the edge as you can, so every response gets them. On nginx, in the server block for HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

The always flag adds the header to error responses too. Note that a location block with any add_header of its own stops inheriting these, so repeat them there or move them into an included file. More in the nginx security headers guide.

On Apache with mod_headers enabled, in the virtual host or .htaccess:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Using set rather than add replaces any copy the application already sent, which avoids duplicates.

Other platforms

• Cloudflare: HSTS is under SSL/TLS, Edge Certificates. Other headers can be set with a response header transform rule. See the Cloudflare guide.
• Plesk: add the nginx or Apache lines under the domain's Apache and nginx Settings; see the Plesk guide.
• WordPress: server-level headers are better than a plugin, but a headers plugin works on shared hosting. See the WordPress guide.
• Windows IIS: use customHeaders in web.config, covered in the IIS guide.

A worked example

A scan of www.example.com, an Example Bakery site on nginx behind Cloudflare, reported four findings: missing HSTS, missing X-Frame-Options, missing Content-Security-Policy and X-XSS-Protection not set.

1. curl showed HSTS was present on the home page but missing on /shop/. The shop's location block had its own add_header for caching, which stopped inheritance. Moving the security headers into an included file and including it in both blocks fixed it.
2. X-Frame-Options was added at server level with always.
3. For CSP, the team sent a report-only policy for two weeks, collected the reports, added the payment provider's domain to frame-src and script-src, then switched to enforcing.
4. X-XSS-Protection was left out on purpose, with a note in the response to the scanner explaining that the filter has been removed from modern browsers.

The rescan showed all required headers present with valid values on every URL type tested, including the 404 page.

The fix, step by step

Edge cases worth knowing

• Headers on redirects. Scanners sometimes test http:// and flag missing headers on the 301 to HTTPS. HSTS is ignored over HTTP anyway; what matters is the HTTPS response.
• Static files and CDNs. Images and scripts served from a CDN or storage bucket may not get your server's headers. The CDN must add them.
• Meta tag CSP. A CSP in a <meta> tag works for most directives but not frame-ancestors or reporting. Use the header where you can.
• Framing you need. If your own pages are embedded elsewhere, use CSP frame-ancestors with the allowed domains rather than X-Frame-Options.
• Subdomains and HSTS. includeSubDomains applies to every subdomain. Check old ones such as a mail or staging host serve HTTPS first.

Keeping the headers in place

Headers disappear after server migrations, control panel updates, new CDN rules and theme changes. Make checking them routine:

• Keep the header set in one file under version control, and include it rather than copying it.
• Run the curl loop above after every deploy or hosting change, and monthly otherwise.
• Keep CSP reporting switched on, so you hear about blocked resources before customers do.
• Rescan after each fix and keep the report, so you can show clients or auditors when the issue was closed. Mixed content warnings often follow HSTS changes; see the mixed content guide.