# HTTPS Isn't Enough: 5 Security Header Mistakes

Having an SSL certificate is an important first step toward securing a website. But HTTPS alone doesn't guarantee that a web application is configured securely.

While working with Linux servers, Nginx, reverse proxies, and my website security audit project, SiteProbeLab, I've been focusing on practical HTTP security configuration issues.

Here are five mistakes worth checking.

1. HSTS Is Present but Effectively Disabled

Consider this HTTP response header:

Strict-Transport-Security: max-age=0

At first glance, HSTS is present. But max-age=0 actually tells the browser to remove the stored HSTS policy for that host after receiving the header over HTTPS.

A commonly used configuration is:

Strict-Transport-Security: max-age=31536000

A longer policy, with includeSubDomains, should only be enabled after verifying that every affected subdomain supports HTTPS properly.

Lesson: Check security header values, not just their presence.

2. Content Security Policy Is Too Permissive

Content Security Policy (CSP) helps reduce the impact of certain client-side attacks by controlling which resources the browser can load.

However, a policy that broadly permits external sources and unsafe inline scripts can weaken this protection.

For example, using script-src 'self' 'unsafe-inline' may allow inline script execution that a stricter policy would block.

A stronger approach is to design a policy around the application's actual dependencies, using nonces or hashes where appropriate.

CSP should be treated as defense in depth, not a replacement for secure application code.

3. Enforcing CSP Without Testing

A strict CSP can accidentally block legitimate JavaScript, fonts, analytics, or third-party integrations.

Before enforcing a new policy, test it with:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'

This example lets you evaluate the restrictions without enforcing them.

Review browser console violations, configure reporting if needed, and adjust the policy before switching to enforcement.

4. Missing Security Headers on Nginx Error Responses

This is an easy detail to overlook in Nginx configurations.

Consider:

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

Without the always parameter, Nginx adds this header only for certain HTTP response codes.

A more consistent configuration is:

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

Also check how add_header directives are inherited between http, server, and location blocks. A header defined at one level can disappear when additional headers are configured at a more specific level.

Recent Nginx versions provide additional inheritance controls, but you should verify the behavior of the version you're actually running.

5. Testing Only the Homepage

A website may return the expected security headers on /, but behave differently on:

• API endpoints
• Redirect responses
• Error pages
• Static resources
• Responses delivered through a CDN

A simple starting point:

curl -sSI https://example.com/

Then test actual GET responses:

curl -sS -D - -o /dev/null https://example.com/api/health

curl -sS -D - -o /dev/null https://example.com/nonexistent-page

When using Cloudflare or another reverse proxy, inspect what the client actually receives, not only the origin server's configuration.

Remember that different resource types require different security controls. The absence of a browser-oriented header on a JSON API isn't automatically a vulnerability.

My Current Project: SiteProbeLab

I'm developing SiteProbeLab, a website audit MVP focused on making common security configuration findings easier to identify and understand.

The project explores checks involving HTTPS, HSTS, CSP, and HTTP security headers.

Project website:
https://siteprobelab.com/

I also document my Linux infrastructure, cloud, DevOps, and security engineering projects at:

Technical portfolio:
https://ta551.info/

Final Thoughts

Security configuration isn't a one-time checkbox.

A reliable workflow should include:

1. Reviewing HTTP response headers.
2. Validating their actual values.
3. Checking different application routes and response codes.
4. Testing changes before enforcing restrictive policies.
5. Rechecking configurations after deployments.

Security headers are valuable, but they are only one layer in a broader application security strategy.

How do you validate security headers in your deployment workflow?

I'd be interested in hearing about tools and approaches other developers and system administrators use.

Technical references

• OWASP HTTP Headers Cheat Sheet
• MDN — Strict-Transport-Security
• MDN — Content Security Policy
• Official Nginx Headers Module Documentation