What “HTTP Security Header Not Detected” Means

The scanner requested a URL and did not find one or more headers that its policy expects in the returned response. The finding is intentionally broad: two scanners can use the same label while checking different headers or response paths.

Common examples include:

• Strict-Transport-Security not detected on an HTTPS response.
• Content-Security-Policy not detected on a browser-rendered HTML document.
• X-Frame-Options not detected or no CSP frame-ancestors directive on a page that should not be framed.
• X-Content-Type-Options not detected where nosniff is expected.
• Referrer-Policy or Permissions-Policy not detected on browser-facing content.
• Cache-Control or safe Set-Cookie attributes missing from sensitive authenticated responses.

A missing header can be a valid defense-in-depth issue, a configuration gap limited to one route, or a low-value scanner finding on a response where that header provides little or no protection. Context determines priority.

Fast Diagnosis: What to Check Before You Change Anything

Use the scanner evidence to reproduce the exact request. A homepage check is not enough when the finding came from an API route, redirect, error page, management port, or authenticated response.

Quick verification commands

curl -sS -D - -o /dev/null https://example.com/path
curl -sS -I https://example.com/path
curl -sS -L -D - -o /dev/null http://example.com/path

Use the first command to inspect the real GET response, the second to compare a HEAD response, and the third to view the complete HTTP-to-HTTPS redirect chain. Replace the example URL with the exact scanner target.

How Serious Is a Missing HTTP Security Header?

Severity depends on the missing control, the response type, the application’s exposure, and whether another control already provides equivalent protection. A scanner’s generic rating should be treated as a starting point for triage rather than the final risk decision.

Security headers do not replace output encoding, secure coding, authentication, authorization, CSRF protection, object-level access control, API discovery, or runtime monitoring. They are browser and response hardening controls within a broader security model.

Which HTTP Security Headers Matter?

There is no universal bundle for every response. The strongest configuration is the one that matches the content, browser behavior, authentication model, and deployment architecture.

Practical baseline for an HTTPS HTML page

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

This is an example, not a drop-in policy. A real CSP normally needs explicit rules for scripts, styles, fonts, images, frames, and API connections. Test it in report-only mode before enforcement.

Advanced cross-origin isolation headers

Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy can strengthen isolation for applications that need it, including features that depend on cross-origin isolation. They can also break popups, embedded content, third-party resources, and integrations, so they should be introduced only for a defined requirement and tested as a coordinated policy.

Do APIs Need the Same Security Headers as HTML Pages?

No. Browser-facing APIs still need strong HTTP response controls, but not every browser document header adds value to every JSON response. This distinction helps teams remediate real risk without adding meaningless headers only to satisfy a generic scanner rule.

For APIs, the larger risks are often broken authorization, excessive data exposure, token leakage, unsafe CORS, undocumented endpoints, business logic abuse, and abnormal automated behavior. Headers support the security model, but runtime API visibility and response inspection address different layers of risk.

How to Fix “HTTP Security Header Not Detected”

Add the missing header at the layer that consistently controls the affected response. Centralized configuration is useful for common baselines, while application-level configuration is better when policies differ by route, tenant, authentication state, or response type.

NGINX or OpenResty example

add_header Strict-Transport-Security "max-age=31536000" 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 parameter helps include headers on non-2xx responses. Configure HSTS only in the HTTPS server context, and test inherited add_header behavior when nested locations define their own headers.

Apache HTTP Server example

Header always set Strict-Transport-Security "max-age=31536000"
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=()"

Enable the headers module, place HSTS only in the TLS virtual host, and confirm that application or proxy responses do not produce duplicate values.

IIS web.config example

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=31536000" />
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
      <add name="Permissions-Policy" value="camera=(), microphone=(), geolocation=()" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

For IIS, HSTS can also be managed with platform features or application middleware. Keep it limited to HTTPS and verify inherited site, server, and application settings.

Content Security Policy rollout

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Review violations, add only required sources, remove unsafe exceptions where feasible, test login and payment flows, then replace the report-only header with an enforced Content-Security-Policy.

Testing and Rollout Best Practices

1. Reproduce the exact finding. Record the URL, port, protocol, method, status code, and current headers.
2. Classify the response. Decide whether it is HTML, JSON, a redirect, an error page, a file, or a static resource.
3. Select the control owner. Choose the application, proxy, gateway, CDN, WAF, or load balancer that should own the header.
4. Deploy in staging. Test public, authenticated, admin, upload, download, embedded, and error workflows.
5. Use report-only deployment where available. CSP and some cross-origin policies need observation before enforcement.
6. Inspect the real path. Verify the final response after every intermediary, not only the origin server.
7. Retest with multiple methods. Compare GET, HEAD, redirect chains, 4xx, and 5xx responses.
8. Monitor after release. Watch browser console reports, application errors, blocked resources, API failures, and repeated scanner alerts.

Common Scanner False Positives and Incomplete Fixes

Related Standards and API Security Guides

For current header behavior and testing guidance, review the OWASP Secure Headers Project, the OWASP HTTP Headers Cheat Sheet, and MDN’s HTTP header reference.

Related Ammune guidance includes REST API endpoint security best practices, OWASP Top 10 vulnerabilities with examples, API gateway security limitations, API runtime security protection, real-time API threat detection, and why edge security alone is not enough for APIs.

HTTP Security Header Remediation Checklist

1. Capture the exact evidence: URL, hostname, port, protocol, method, status code, response type, and missing header.
2. Determine applicability: confirm whether the control protects that response type.
3. Check for an equivalent control: for example, CSP frame-ancestors may provide framing protection even when X-Frame-Options is absent.
4. Assign one owner: application, NGINX/OpenResty, Apache, IIS, gateway, CDN, WAF, or load balancer.
5. Stage HSTS: enable it only over HTTPS and delay includeSubDomains or preload until the domain is fully ready.
6. Stage CSP: use report-only mode, collect violations, then enforce a tested policy.
7. Set accurate content types: pair X-Content-Type-Options: nosniff with correct Content-Type values.
8. Protect sensitive responses: use appropriate cache controls and secure cookie attributes.
9. Validate redirects and errors: inspect 3xx, 4xx, and 5xx responses as well as normal pages.
10. Check the delivery chain: compare origin and public responses for stripping, duplication, or overwrite.
11. Retest and document exceptions: close valid gaps and record response-specific non-applicability with evidence.
12. Monitor continuously: detect policy drift as applications, gateways, CDNs, and APIs change.

Common mistakes to avoid

• Adding every header to every response without considering whether it applies.
• Using HSTS includeSubDomains or preload before all subdomains are HTTPS-ready.
• Deploying a restrictive CSP directly into enforcement without real workflow testing.
• Adding deprecated X-XSS-Protection guidance copied from old remediation articles.
• Fixing only the homepage while redirects, APIs, management paths, and error pages remain inconsistent.
• Allowing multiple infrastructure layers to create duplicate or conflicting policies.
• Treating headers as a replacement for authorization, secure coding, and runtime API security.

Where Ammune fits

Ammune complements response hardening by discovering live APIs, inspecting requests and responses, identifying sensitive data exposure, detecting abnormal behavior and business logic abuse, and producing SIEM-ready security events. This helps teams see risks that browser security headers cannot address.

Conclusion

An “HTTP security header not detected” alert should lead to a precise response, not a universal header bundle. Reproduce the exact request, identify the missing control, determine whether it applies to that response, configure it at the correct layer, and verify the final result through the production delivery chain.

For browser-rendered pages, HSTS, CSP, frame protection, nosniff, Referrer-Policy, Permissions-Policy, secure cookies, and safe caching can materially improve defense in depth. For APIs, prioritize TLS, accurate content types, CORS where needed, cache and token protection, authentication, authorization, sensitive-data controls, and runtime visibility.

The best outcome is not simply making the scanner green. It is a documented, tested, and maintainable policy that protects each response without breaking the application.

FAQs About HTTP Security Header Not Detected