SaaSFort A SaaS application missing HTTP security headers is like a bank vault with the door propped open. The vault itself might be solid — encrypted at rest, patched weekly, pen-tested quarterly — but anyone walking by can see the invitation.
Security headers are the first thing automated scanners check. They’re the first thing enterprise procurement tools flag. And under NIS2, they map directly to Article 21(2)(e) network security requirements.
SaaSFort checks all six critical headers as part of its 60-check scan. Here’s what each one does, why it matters for compliance, and the exact configuration your team should deploy today. For the other half of your transport security — TLS protocol versions, cipher suites, and certificate chains — see our TLS/SSL configuration guide.
The 6 Headers That Matter
1. Strict-Transport-Security (HSTS)
What it does: Forces browsers to only connect via HTTPS. Prevents SSL stripping attacks and accidental HTTP connections.
Recommended value:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Why it matters for NIS2: Article 21(2)(h) requires cryptographic controls. HSTS ensures encrypted transport is enforced at the browser level — not just by your server configuration. Without it, a user on a coffee shop WiFi can be downgraded to HTTP by a man-in-the-middle attacker, even if your server supports HTTPS.
Common mistakes: Setting max-age=0 (effectively disabling it), omitting includeSubDomains (leaving staging/API subdomains exposed), skipping preload submission to hstspreload.org.
2. Content-Security-Policy (CSP)
What it does: Controls which resources (scripts, styles, images, fonts) the browser is allowed to load. The most powerful — and most complex — security header.
Recommended starting point:
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 'none'
Why it matters for NIS2: Article 21(2)(f) covers vulnerability handling. CSP is your primary defense against Cross-Site Scripting (XSS) — OWASP’s #1 web application risk. A properly configured CSP blocks injected scripts even if an XSS vulnerability exists in your code.
Common mistakes: Using unsafe-eval (defeats the purpose), setting default-src * (allows everything), not testing in report-only mode first. Start with Content-Security-Policy-Report-Only to identify violations before enforcing.
3. X-Frame-Options
What it does: Prevents your site from being embedded in iframes on other domains. Blocks clickjacking attacks.
Recommended value:
X-Frame-Options: DENY
Use SAMEORIGIN only if your application legitimately needs to iframe itself (rare for SaaS).
Why it matters for NIS2: Clickjacking can trick users into performing actions they didn’t intend — including granting OAuth permissions or changing security settings. Article 21(2)(i) requires access control measures, and preventing UI manipulation is part of that.
4. X-Content-Type-Options
What it does: Prevents MIME type sniffing. Forces browsers to respect the declared Content-Type header instead of guessing.
Recommended value:
X-Content-Type-Options: nosniff
Why it matters: Without this header, a browser might interpret a plain text file as JavaScript and execute it. This is a prerequisite for CSP effectiveness — if the browser can sniff types, your CSP restrictions become leaky. One line of configuration, zero performance impact.
5. Referrer-Policy
What it does: Controls how much URL information is shared when navigating away from your site. Prevents leaking sensitive paths, session tokens, or internal routes to third parties.
Recommended value:
Referrer-Policy: strict-origin-when-cross-origin
Why it matters: SaaS applications often have user-specific URLs (/dashboard/org-123/report/456). Without a Referrer-Policy, these paths leak to analytics scripts, external links, and third-party resources. For NIS2 Article 21(2)(i) access control requirements, data leakage prevention starts here.
6. Permissions-Policy
What it does: Controls which browser features (camera, microphone, geolocation, payment) your site can access.
Recommended value:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Why it matters: If your SaaS doesn’t need camera or microphone access, explicitly disabling them blocks any injected script from abusing these APIs. It’s defense-in-depth — even if an attacker achieves XSS, they can’t escalate to device-level access.
Quick Reference: All 6 Headers
| Header | Value | NIS2 Article | Blocks |
|---|---|---|---|
| Strict-Transport-Security | max-age=31536000; includeSubDomains; preload | 21(2)(h) | SSL stripping, downgrade attacks |
| Content-Security-Policy | default-src 'self'; script-src 'self'; frame-ancestors 'none' | 21(2)(f) | XSS, data injection |
| X-Frame-Options | DENY | 21(2)(i) | Clickjacking |
| X-Content-Type-Options | nosniff | 21(2)(f) | MIME confusion attacks |
| Referrer-Policy | strict-origin-when-cross-origin | 21(2)(i) | URL/path leakage |
| Permissions-Policy | camera=(), microphone=(), geolocation=() | 21(2)(i) | Device API abuse |
How to Check Your Headers in 60 Seconds
Three options, from easiest to most thorough:
-
SaaSFort scan — Run a free scan on your domain. Security headers are checked as part of the 60-check suite, with each finding mapped to NIS2 controls. The full report shows pass/fail status for each header.
-
Browser DevTools — Open any page, press F12, go to Network tab, click the main document request, check Response Headers. Manual but immediate.
-
curl —
curl -I https://yourdomain.comreturns all response headers in your terminal. Script it for CI/CD checks.
For automated monitoring, SaaSFort’s CI/CD integration checks headers on every deployment — so regressions are caught before they reach production.
Implementation: Where to Add Headers
The exact implementation depends on your stack:
| Stack | Where to configure |
|---|---|
| Nginx | add_header directives in server block |
| Cloudflare | Transform Rules or Workers |
| AWS CloudFront | Response Headers Policy |
| Vercel/Netlify | vercel.json / _headers file |
| Express.js | helmet middleware |
| Django | SECURE_* settings + django-csp |
Pro tip: Configure headers at the CDN/proxy level (Cloudflare, CloudFront), not in your application code. This ensures headers are applied to all responses — including error pages, static assets, and redirects that might bypass your application middleware.
What Auditors Actually Check
BSI auditors and enterprise procurement teams don’t manually inspect headers. They use automated scanning tools — including tools like SaaSFort, Mozilla Observatory, and SecurityHeaders.com. In fact, your security grade vs pentest report determines whether procurement even looks at your detailed findings.
What triggers audit flags:
- Missing HSTS — automatic fail on any modern security assessment
- No CSP — yellow flag, often requires remediation timeline
- Missing X-Frame-Options + frame-ancestors — clickjacking risk documented
- Inconsistent headers — different headers on different subdomains signals configuration drift
A NIS2 compliance PDF from SaaSFort maps each header finding to the specific Article 21(2) measure it addresses — exactly the format BSI auditors expect.
FAQ
Do security headers affect performance?
No measurable impact. Headers add 200-400 bytes to each HTTP response. The browser processes them in microseconds. CSP can actually improve performance by preventing unwanted resource loads.
Can I add all 6 headers at once?
Yes, but test CSP in report-only mode first (Content-Security-Policy-Report-Only). The other five headers have no side effects and can be deployed immediately. CSP is the only one that might break functionality if your app loads third-party scripts.
My SaaS uses third-party scripts (analytics, chat, payments). Does CSP block them?
Only if you don’t whitelist them. Add each trusted domain to the appropriate CSP directive: script-src 'self' https://js.stripe.com; connect-src 'self' https://api.stripe.com. Every third-party domain you add weakens your CSP — so audit your script dependencies and remove unused ones.
Are security headers required by NIS2?
NIS2 Article 21(2) requires “appropriate and proportionate technical measures.” Security headers are considered baseline measures by BSI auditors — their absence signals a lack of basic security hygiene. While no specific header is named in the directive text, the BSI Grundschutz++ practices for network security and cryptography cover exactly these controls.
How often should I audit my security headers?
After every infrastructure change (CDN migration, new proxy, server update) and at minimum monthly. Headers can silently disappear during deployments. Automated continuous monitoring catches regressions immediately.
Check your security headers now. Free scan — 60 checks including all 6 critical headers, mapped to NIS2 Article 21. Results in under 60 seconds. Export as NIS2 compliance PDF for your audit file. For the complete framework, download our free SaaS Security Playbook 2026.
De la lectura a la acción
Escanee su dominio gratis. Primeros resultados en menos de 10 segundos — sin registro.