Browser security
Security headers for SaaS: what to add first
A practical guide to CSP, HSTS, clickjacking protection, MIME sniffing, referrer policy, and permissions policy for SaaS teams.
Security headers are small response headers with an outsized job. They tell a browser which scripts may run, whether a page may be framed, and whether an insecure connection is acceptable. A SaaS can have solid application code and still leave these browser defenses unset.
The hard part is not adding every possible header. It is choosing a safe order, measuring what breaks, and avoiding a copied policy that does not match your product.
Start with the headers that close clear gaps
For most SaaS products, four headers deserve attention first. They cover transport, framing, content interpretation, and script execution.
- Strict-Transport-Security tells supporting browsers to return over HTTPS after the first secure visit.
- Content-Security-Policy limits where scripts, styles, images, frames, and connections may come from.
- X-Content-Type-Options: nosniff stops a browser from guessing a different content type.
- frame-ancestors in CSP, or X-Frame-Options for older clients, limits clickjacking through hostile frames.
Roll out CSP without breaking production
A strict CSP copied from another app can block payments, analytics, support widgets, or your own inline code. Begin with Content-Security-Policy-Report-Only, collect violations, and map each required third party to the narrowest directive that allows it.
Avoid treating unsafe-inline and a wildcard as the finished policy. They may make the report quiet while leaving much of the original risk in place. Nonces or hashes are a better long-term answer for inline scripts.
- Inventory scripts, API connections, images, fonts, frames, and form destinations.
- Ship a report-only policy and watch real routes, including login, checkout, and password reset.
- Replace broad sources with exact hosts, nonces, or hashes.
- Move to an enforced policy and keep violation reporting during later releases.
Do not enable HSTS by reflex
HSTS is valuable only when every affected hostname is ready for HTTPS. Start with a shorter max-age on the primary host. Add includeSubDomains after checking forgotten subdomains, status pages, and customer-facing custom domains. Preload is a separate commitment and is difficult to undo quickly.
Also keep the server-side HTTP to HTTPS redirect. HSTS improves repeat visits, but a new visitor can still arrive over HTTP before the browser has learned the policy.
A sensible release check
Test headers on the final public response, not only in application code. A CDN, reverse proxy, or hosting platform can add, remove, or duplicate them. Scan the production hostname after deployment, open important flows manually, and keep the change easy to roll back.
Check your production site
See which of these issues are visible now.
ScanMySaaS checks the public surface and keeps the affected URL with every finding. Verify results before changing production.
Run a free scan