Missing security headers can leave a website more exposed to cross-site scripting, clickjacking, content injection, and data leakage.
This guide explains how to fix missing security headers across Apache, Nginx, IIS, and popular frameworks so you can harden responses without guesswork.
What security headers do and why they matter
Security headers are HTTP response headers that tell browsers how to handle your site’s content, connections, and embedded resources.
They do not replace secure code or patching, but they add an important layer of defense against common browser-based attacks.
When headers are missing, browsers fall back to permissive defaults.
That can make it easier for attackers to exploit weak input handling, inject scripts, frame your pages inside malicious sites, or downgrade user privacy.
Which security headers should you check first?
If you are trying to fix missing security headers, start with the most widely recommended ones.
These are the headers security tools commonly flag during audits with OWASP ZAP, Mozilla Observatory, SecurityHeaders.com, and similar scanners.
- Content-Security-Policy — limits where scripts, styles, images, and other resources can load from.
- X-Frame-Options — reduces clickjacking risk by controlling whether the page can be embedded in a frame.
- Strict-Transport-Security — forces browsers to use HTTPS for future requests.
- X-Content-Type-Options — prevents MIME sniffing by browsers.
- Referrer-Policy — controls how much referrer information is sent to other sites.
- Permissions-Policy — limits access to browser features such as camera, microphone, geolocation, and more.
In some environments, you may also see recommendations for Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy.
These are useful for stronger isolation, especially on applications handling sensitive data.
How to fix missing security headers in a structured way
The safest approach is to inventory your current response headers, decide which ones should be present on all pages, and then apply them at the web server or application layer.
Fixing them piecemeal often leads to inconsistent behavior between routes, subdomains, or asset types.
1. Audit the current response headers
Before changing anything, inspect live responses using browser developer tools, curl, or a security scanner.
Check the homepage, login page, API endpoints, static assets, and error pages because each may be served differently.
Look for missing headers, conflicting values, and duplicate headers added by multiple layers such as a CDN, reverse proxy, and application framework.
Conflicts are common when a platform adds a default header and the app overrides it later.
2. Decide where each header should be set
For most sites, security headers should be set as close to the edge as practical, typically in the web server, CDN, or load balancer.
This ensures they apply consistently even when the application returns an error or redirects a request.
If you need route-specific values, such as a stricter Content-Security-Policy on authenticated pages, you can still set those in the application.
The key is to avoid fragmented header logic that becomes hard to maintain.
3. Add a secure baseline
A sensible baseline for many websites includes HSTS, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
Then add a carefully tested Content-Security-Policy and frame protection.
Example baseline values often look like this in concept:
- Strict-Transport-Security: enable only after the site is fully available over HTTPS.
- X-Content-Type-Options: use
nosniff. - Referrer-Policy: use
strict-origin-when-cross-originfor a balanced default. - Permissions-Policy: disable features you do not use.
- X-Frame-Options: use
DENYorSAMEORIGINwhere framing is not required.
How to fix missing security headers on Apache
On Apache, headers are commonly added through mod_headers.
In many deployments, this is the simplest place to set a site-wide policy.
Typical configuration is placed in the virtual host file, .htaccess, or a server config file depending on hosting permissions.
For example, you can add headers with directives such as Header set and Header always set so they are returned even on error responses.
Be careful with .htaccess if performance matters.
Server-level configuration is generally easier to govern and less likely to be accidentally bypassed by nested directory rules.
How to fix missing security headers on Nginx
On Nginx, the add_header directive is commonly used in server blocks and location blocks.
A frequent mistake is assuming it applies everywhere by default, when in practice it may not be included on certain response codes unless configured carefully.
To avoid gaps, define headers at the server level and test responses for redirects, 4xx pages, and 5xx pages.
If you use a reverse proxy or CDN in front of Nginx, confirm that the upstream layer is not stripping or replacing the headers.
If you manage both static and dynamic routes, keep the baseline consistent and only narrow it where the application truly needs different rules.
How to fix missing security headers in IIS
In Microsoft IIS, security headers can be added through the HTTP Response Headers feature in the IIS Manager or in web.config.
This approach works well for Windows-hosted applications, especially when teams want configuration stored with the application.
Use centralized configuration where possible so all sites inherit the same defaults.
Then override headers only for specific applications that have known exceptions, such as legacy embedded content or older third-party integrations.
How to fix missing security headers in popular frameworks
Many application frameworks provide middleware or plugins for response headers.
This is useful when your infrastructure does not expose server configuration or when you need route-aware policies.
- Express.js: use Helmet to add and manage secure defaults.
- Next.js: configure headers in
next.config.jsor edge middleware when needed. - Django: use built-in security settings such as
SECURE_HSTS_SECONDS,SECURE_CONTENT_TYPE_NOSNIFF, and related options. - Laravel: use middleware or packages that inject response headers.
- Spring Boot: configure Spring Security header support in the security chain.
Framework-level controls are effective, but they should still align with your infrastructure.
If a CDN or proxy terminates responses before they reach the app, server-side settings alone may not be enough.
How to test whether the fix worked
After adding headers, verify them in multiple contexts.
Check the homepage, login form, API endpoints, redirect responses, error responses, and file downloads.
A header that appears on 200 OK responses but disappears on 301 or 404 pages is still a gap.
Use at least two validation methods: one manual and one automated.
Manual checks with browser tools and curl confirm what real clients receive, while scanners help catch missing coverage and weak policies across many routes.
For Content-Security-Policy, test carefully before enforcing a restrictive policy.
A policy that blocks legitimate scripts, fonts, analytics, or payment widgets can break functionality if deployed without staging.
Common mistakes when fixing missing security headers
Teams often run into the same problems when hardening headers.
Avoid these issues to keep your changes reliable.
- Adding headers only on the homepage instead of all responses.
- Setting HSTS before HTTPS is fully stable, which can lock users into a broken configuration.
- Using a weak or overly permissive Content-Security-Policy that allows
unsafe-inlinewithout justification. - Conflicting settings across CDN, proxy, and app layers, leading to unpredictable results.
- Forgetting non-HTML responses such as JSON, PDFs, and error pages.
- Not testing third-party embeds or scripts before tightening policies.
What a secure rollout should include
A good rollout plan includes staging, controlled testing, and documentation.
Start with the least disruptive headers, then move to stricter controls after you confirm business-critical pages still work.
Document which team owns each header, where it is applied, and what exceptions exist.
That makes future audits faster and reduces the chance of configuration drift after deployments, migrations, or CDN changes.
If you want long-term consistency, treat security headers as part of your release checklist alongside TLS configuration, dependency patching, and access control reviews.
When missing security headers are a symptom of a larger problem
Sometimes missing headers point to broader operational gaps.
A site with no HSTS, no CSP, and no referrer controls may also have weak TLS settings, outdated dependencies, or inconsistent deployment practices.
In those cases, fixing headers should be part of a wider hardening effort that includes secure cookie flags, authenticated session protection, least-privilege access, and regular vulnerability scanning.
Security headers are strongest when they support a broader defense-in-depth strategy.