The SaaS Website Security Checklist Auditors Actually Use

SaaS products live or die by trust. A single misconfigured header or an expired certificate on your login subdomain can undo months of sales work — and these are exactly the issues that show up in security questionnaires, SOC 2 audits, and pentest reports. The good news: most of the gaps are configuration problems, not code problems, which means you can close them in hours rather than sprints.

This checklist focuses on what actually matters for a SaaS product in production: the controls that protect sessions, prevent account takeover, and stop your marketing site from becoming a phishing vector. Work through it in order — the items at the top have the highest blast radius.

1. Transport security: TLS and certificate hygiene

Your TLS configuration is the foundation. If it's weak, nothing else matters because traffic can be intercepted or downgraded.

• TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0, 1.1, and all SSLv3. Most CDNs let you toggle this in one click.
• Strong cipher suites only. Remove RC4, 3DES, and any CBC-mode ciphers without AEAD.
• HSTS with a long max-age. Set Strict-Transport-Security: max-age=31536000; includeSubDomains; preload and submit to the HSTS preload list once you're confident every subdomain serves HTTPS.
• Certificate monitoring. Wildcard certs are convenient but expand blast radius if the private key leaks. Monitor expiry on every hostname — including api., auth., status., and marketing subdomains.
• OCSP stapling enabled. Faster handshakes and better privacy for users.

2. Security headers that actually do something

Most SaaS apps ship with two or three headers and assume the rest are optional. They're not — modern browsers rely on these to enforce isolation.

The required set

• Content-Security-Policy — your strongest defence against XSS. More on this below.
• X-Content-Type-Options: nosniff — stops MIME sniffing attacks.
• Referrer-Policy: strict-origin-when-cross-origin — keeps tokens out of Referer headers.
• Permissions-Policy — explicitly deny features you don't use (camera, microphone, geolocation, FLoC).
• Cross-Origin-Opener-Policy: same-origin — protects against cross-window attacks like Spectre.
• Cross-Origin-Resource-Policy: same-site — controls who can embed your resources.

Headers to remove

• X-Powered-By, Server version banners, X-AspNet-Version — fingerprinting gifts.
• X-XSS-Protection — deprecated and can introduce vulnerabilities. Remove it.

3. A Content Security Policy you can actually maintain

CSP is where most SaaS teams give up. The trick is to start in report-only mode, then tighten.

1. Deploy Content-Security-Policy-Report-Only with your strictest intended policy and a report-uri or report-to endpoint.
2. Run your app for a week, collect violations, and decide which are legitimate (your CDN, Stripe, Intercom) versus which are unexpected (inline scripts, third-party widgets nobody approved).
3. Move to enforcement with script-src 'self' 'nonce-{random}' instead of 'unsafe-inline'. Nonces are non-negotiable for any SaaS handling auth.
4. Set frame-ancestors 'none' unless you genuinely need to be embedded — this replaces X-Frame-Options.
5. Add upgrade-insecure-requests to catch any leftover HTTP references.

4. Cookie configuration

Session cookies are the crown jewels. Get every flag right.

• Secure — required, always.
• HttpOnly — required for session cookies. No exceptions.
• SameSite=Lax for session cookies, SameSite=Strict for anything sensitive that doesn't need to survive cross-site navigation.
• Prefix sensitive cookies with __Host- to enforce the strictest rules at the browser level.
• Short lifetimes for access tokens, longer for refresh tokens — and always rotate refresh tokens on use.

5. CORS without the footguns

CORS misconfigurations are one of the most common findings WebSentry surfaces on SaaS APIs. The patterns to avoid:

• Never reflect arbitrary origins. If you echo back the request's Origin with Access-Control-Allow-Credentials: true, you've effectively disabled the same-origin policy.
• Wildcards plus credentials is invalid — browsers will reject it, but some libraries silently misconfigure this.
• Maintain an allowlist of origins (your app, your marketing site, your status page) and validate exact matches.
• Don't allow null as an origin — sandboxed iframes and local files send it.

6. DNS and email authentication

Your DNS records protect your brand even when no one is on your site.

• CAA records restrict which CAs can issue certificates for your domain.
• SPF, DKIM, and DMARC — set DMARC to p=reject once you've verified all legitimate senders. SaaS phishing almost always starts with a spoofable sender domain.
• DNSSEC where your registrar supports it.
• Subdomain takeover audits — every dangling CNAME pointing to a deprovisioned Heroku app, S3 bucket, or Vercel project is a takeover waiting to happen.

7. Authentication and session controls

• Enforce MFA for all admin and billing accounts. Offer it to end users.
• Rate limit login, password reset, and signup endpoints — per IP and per account.
• Use a credential breach check (HIBP's Pwned Passwords API) on registration and password change.
• Invalidate sessions on password change, email change, and MFA enrollment.
• Log every auth event with IP, user-agent, and outcome. You will need this for incident response.

8. Third-party scripts and supply chain

Every analytics tag and chat widget you embed runs with the same privileges as your app.

• Pin third-party scripts with Subresource Integrity (SRI) where the vendor supports it.
• Self-host critical libraries instead of loading from public CDNs you don't control.
• Review the marketing site as carefully as the app — a compromised tag manager is a compromised login page.
• Maintain an inventory of every third-party domain in your CSP. If you can't justify it, remove it.

9. Continuous verification

Configuration drift is the killer. A header you set six months ago disappears when someone migrates from one load balancer to another, and nobody notices until a customer's security team flags it during procurement.

• Run automated security scans on every deploy to staging and production.
• Track grades over time so regressions are visible.
• Scan every public hostname, not just www. Your api., docs., and app. subdomains all need the same scrutiny.

This is where tools like WebSentry earn their place in the workflow: it gives each hostname an A–F grade across TLS, headers, CSP, cookies, DNS, and CORS, and shows you exactly what changed since the last scan. For SaaS teams answering vendor security questionnaires, having a current report ready saves days of back-and-forth.

10. Document it for buyers

Enterprise buyers don't take your word for it. Publish a security page that lists your controls, link to your subprocessor list, and be ready to share a recent scan report. The faster you can produce evidence, the faster deals close.

Run a free scan of your production hostnames at websentry.dev to see where your SaaS stacks up against this checklist — and which configuration changes will move your grade the fastest.