A security headers scan checks whether your app returns the browser policies that reduce common abuse paths, including clickjacking, MIME sniffing, weak referrer leakage, and unsafe framing. For most SaaS teams, the useful outcome is simple: verify the right headers on real production pages, then monitor them so a deploy, CDN rule, or proxy change does not silently remove protection.
Security headers scan checklist
Start with the headers browsers still enforce and the ones that commonly disappear during infrastructure changes. On most SaaS apps, you want these present on the homepage, login, signup, billing, and any authenticated app shell.
- Content-Security-Policy - Present on HTML responses, scoped to the scripts, styles, frames, and connections your app actually uses. A policy full of wildcards is usually a weak pass.
- Strict-Transport-Security - Returned on the final HTTPS response with a sensible
max-age. Only addincludeSubDomainswhen every subdomain is truly HTTPS-ready. - X-Content-Type-Options - Set to
nosniff. This is a low-complexity, high-value check. - Referrer-Policy - Use a modern value such as
strict-origin-when-cross-originor stricter if your flows allow it. - Permissions-Policy - Disable browser features you do not need, instead of accepting broad defaults.
- Frame protections - Prefer CSP
frame-ancestorsand keepX-Frame-Optionsif you want legacy browser fallback.
If your scan only checks the marketing homepage, it is incomplete. Real regressions often appear on redirects, error pages, or routes served by a different edge layer than the main app.
What a good result looks like?
A response header check is only useful if you know what counts as a pass. The goal is not to collect every possible header. The goal is to send the right set, with values that match how your app works.
Content-security-policy
For CSP, presence alone is not enough. A decent policy limits where scripts, styles, images, frames, and connections can load from. Common weak patterns include broad * sources, unnecessary unsafe-inline, and policies that protect the homepage but not the authenticated app.
For SaaS teams, the failure pattern is predictable. A new analytics script, support widget, or auth provider gets added late in a release, someone loosens the policy to make production work, and the policy stays weak for months.
Strict-transport-security
For HSTS, check the final HTTPS response, not just the first redirect. Teams often see the header on / but miss that /login or /app is served by another layer without it. If your app mixes multiple subdomains, validate each one separately before enabling broader scope.
Referrer, frame, and fallback controls
Referrer-Policy, X-Content-Type-Options, and frame protections should be consistent across HTML pages. They are easy to set, so missing values usually point to a deployment or proxy inconsistency, not a conscious security decision.
If you are doing a broader launch review, pair this work with secure your app before launch. Header validation helps, but it does not replace checks for exposed secrets, risky defaults, or broken production config.
How to run the check?
You do not need a complex tool to start. A browser and a command line are enough for the first pass.
curl -I https://yourapp.com/loginThen make the process repeatable:
- Check the redirect chain. Validate the final HTTPS response and any intermediate 301 or 302 hops that matter to users.
- Test critical pages. Include
/,/login,/signup,/billing, key authenticated routes, and one known 404 page. - Compare anonymous and authenticated responses. Some apps attach headers at the CDN for public pages but miss app routes rendered elsewhere.
- Inspect error behavior. A clean 200 response can look fine while
401,403, or500responses drop your browser security policies. - Repeat in production. Preview and staging can pass while production edge rules behave differently.
A solid audit also checks the places where incidents actually happen. If your login uses a separate subdomain, or your checkout touches another host, inspect those responses too. Many teams validate the main app and forget the auth callback, billing portal, or support center.
For adjacent issues, run a secrets review as well. Missing headers and exposed credentials often show up together in rushed launches, so it is worth pairing this with scan exposed secrets.
Common production misses
Most header problems are not caused by developers forgetting what to set. They come from architecture drift.
- CDN overrides - Headers are injected only on some HTML routes, not across all edge paths.
- Separate rendering layers - Marketing pages, app pages, and auth pages are served by different stacks with different defaults.
- Error templates - Reverse proxies or platform error pages return thin responses without the expected policy set.
- Preview-only config - A staging environment has the right rules, but production uses older edge config.
- Third-party flows - Hosted auth or billing pages may not be under your control, so your scan must distinguish what you own from what you merely link to.
This is where operational visibility matters. A one-off report tells you the state of headers at one moment. It does not tell you when they change after a deploy. That is why teams usually combine a header audit with external monitoring and broader production monitoring.
Turn the check into monitoring
The practical next step is simple: monitor a few critical pages from the outside and alert when important response headers disappear or change unexpectedly.
For most SaaS products, start with these assertions:
- CSP exists on HTML pages
- HSTS exists on final HTTPS responses
- X-Content-Type-Options equals
nosniff - Referrer-Policy matches your approved value
- Frame protections are present on pages that should not be embedded
Run those checks on the homepage, login, signup, and billing. If a missing header would materially change risk, treat it like a production regression, not a nice-to-have. The same synthetic approach used to monitor critical user flows can also verify response headers before customers notice a bad deploy.
The important operational point is this: basic uptime checks only tell you the page answered. They do not tell you the response is still safe, consistent, and configured the way you intended.
A good headers process has three layers: baseline policy, repeatable validation, and alerting when production changes.
A one-time header audit helps you find obvious gaps. The real win comes when you validate important pages continuously, especially the ones tied to sign-in, billing, and account access. That is where regressions create real customer and incident pressure.
Faq
Which headers matter most for a SaaS app?
Start with Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, and frame protections. Those cover the most common browser-side controls with practical value. Permissions-Policy is also useful, but it usually comes after the core set is consistent across your important pages.
Should every route return the same headers?
Not always. Static assets, API responses, downloads, and HTML pages can reasonably differ. What matters is consistency for the routes users actually render in a browser, especially login, signup, billing, and authenticated app pages. Error responses should also keep the important browser-facing protections.
Can uptime monitoring detect missing headers?
A simple ping check cannot. You need a monitor that validates response content or headers, not just status code and latency. Synthetic checks are a better fit because they can assert that specific header names and values are present on key production routes.
How often should i validate response headers?
At minimum, run the check during deployment and at regular intervals in production. High-change teams often validate after every release and keep an external check running continuously on critical pages. That catches regressions caused by CDN rules, proxies, and environment drift.
If you want this visible after launch, AISHIPSAFE adds website monitoring and response checks on key pages so header regressions trigger alerts fast.