The Pre-Launch Web Application Security Checklist (And How to Verify Each Item)
A web application security checklist should cover seven areas before you ship: transport security (HTTPS/TLS), security headers and Content Security Policy, exposed secrets, access control and sensitive paths, dependencies with known CVEs, DNS and email authentication, and continuous monitoring. For each item you do three things — check the current state, understand why it matters, and verify it with a real tool or standard. This guide walks through the full list, and shows where an automated external scan can confirm most of it in a single pass.
This is the practical, evergreen version: things a developer can actually run through the afternoon before a launch.
How do I use this checklist?
Go top to bottom. Most items take a minute to verify with a browser dev-tools tab, an online tool, or a command. The point of grouping them is that each group maps to a different attacker entry point, and most are observable from outside your app — which is exactly what automated vulnerability scanning tools are good at. Where a tool name appears below, it's the same kind of check an external scanner runs for you.
1. Transport security: is your TLS actually hard?
HTTPS is table stakes, but "the padlock is there" is not the same as "TLS is configured well."
| Check | Why it matters | How to verify |
|---|---|---|
| Valid certificate, no expiry surprises | An expired or mismatched cert breaks trust and blocks users | SSL Labs or testssl.sh |
| TLS 1.2+ only, weak ciphers disabled | Old protocols/ciphers enable downgrade and decryption attacks | testssl.sh cipher matrix |
| HSTS enabled with a sane max-age | Without HSTS, a user's first HTTP request can be intercepted | Check the Strict-Transport-Security response header |
| HTTP redirects to HTTPS | Mixed entry points leak traffic in cleartext | Curl the http:// URL and follow redirects |
HSTS is defined in RFC 6797 — a long max-age plus includeSubDomains is the standard hardened setup. SteelSuit runs the full testssl.sh cipher and protocol matrix and reports HSTS status as part of every scan.
2. Security headers and CSP: are you telling the browser how to behave?
Response headers are a cheap, high-leverage defense layer. The OWASP Secure Headers Project and MDN's security headers reference are the canonical lists. Key items:
- Content-Security-Policy — your strongest defense against XSS. Avoid
unsafe-inlineandunsafe-eval; avoid wildcard sources. - X-Content-Type-Options: nosniff — stops MIME-type confusion.
- Referrer-Policy and Permissions-Policy — limit data leakage and feature access.
Verify in the browser network tab, with Mozilla Observatory, or with a scanner. Framework-specific guidance matters too — see our Next.js security headers guide for a copy-paste config. SteelSuit includes a CSP evaluator that flags unsafe directives and missing protections.
3. Secrets exposure: did a key end up in your frontend?
This is one of the most common and most damaging mistakes, especially in fast-moving or AI-assisted codebases. Front-end JavaScript bundles are public — anything bundled into them is readable by anyone.
- Check your shipped JS for live credentials: AWS keys, Stripe secret keys, GitHub tokens, database URLs.
- Why it matters: a leaked secret key is a direct path to your cloud bill, your data, or your users' data.
- How to verify: tools like TruffleHog scan content against hundreds of credential detectors. Also confirm no
.envfile is served at a public path.
SteelSuit runs TruffleHog (800+ detectors, pattern-match only — it never tries the key) against your homepage and external JS bundles, and probes for an exposed .env. We go deep on this in how to find exposed API keys on a website, and the same class of mistake shows up constantly in security for vibe-coded apps.
4. Access and sensitive paths: what's reachable that shouldn't be?
Attackers fingerprint your app by requesting predictable paths. Your job is to make sure nothing sensitive answers.
.env,.git/, backup files, and config dumps must not be served.robots.txtandsitemap.xmlshould not advertise admin or staging paths.- Admin panels and debug endpoints should not be publicly reachable without auth.
- CORS must not reflect arbitrary origins with credentials (see how to test for a CORS misconfiguration).
Verify by probing the paths directly, or let a content-discovery tool walk a wordlist. SteelSuit probes for critical/sensitive paths, inspects robots.txt/sitemap.xml, and (on deep scans) runs deeper content discovery and CORS testing.
5. Dependencies and known CVEs: are you running something already broken?
Most real-world breaches exploit known vulnerabilities, not novel ones — which is exactly why OWASP A06: Vulnerable and Outdated Components is on the OWASP Top 10.
- Check: server software, frameworks, and CMS plugins for outdated, vulnerable versions.
- Why it matters: public exploits for known CVEs are trivially weaponized.
- How to verify: a template-based scanner like Nuclei tests for thousands of known issues from the outside.
SteelSuit fingerprints your stack and, on deep scans, runs the full Nuclei template set plus a CMS scan. It maps findings to compliance frameworks (PCI DSS 4.0, ISO 27001:2022, GDPR) so you can see what's at stake.
6. DNS and email authentication: can someone spoof you?
Domain and email security are easy to forget and easy to get wrong.
| Record | Purpose | Verify with |
|---|---|---|
| SPF | Declares who may send mail as your domain | checkdmarc / DNS lookup |
| DKIM | Cryptographically signs outbound mail | DNS lookup |
| DMARC | Tells receivers what to do with unauthenticated mail | checkdmarc |
A missing or permissive DMARC policy lets attackers send phishing email that appears to come from you — see Google and Yahoo's bulk-sender requirements for why this is now effectively mandatory. SteelSuit checks SPF, DKIM, and DMARC via checkdmarc and reports gaps — see SPF, DKIM, and DMARC explained for what each record does and how to fix the common ones. On deep scans it also enumerates subdomains and checks for subdomain takeover.
7. Monitoring: who's watching after launch?
Security is not a one-time gate. Configurations drift, certificates expire, and new subdomains appear. Schedule a recurring external scan so regressions surface before an attacker finds them. Set up alerting on score drops or new high-severity findings.
What's the fastest way to cover this whole checklist?
Manually, the list above is a couple of hours of careful work. The pragmatic shortcut: run an external automated scan that covers most of it at once. SteelSuit takes a domain and probes from the outside — no agent, no source-code access — running TLS analysis, header/CSP evaluation, secret detection, sensitive-path probing, DNS/email checks, and (on deep scans) full Nuclei and subdomain testing. You get aggregated, deduplicated findings, an A–F security score, a shareable PDF, and stack-specific fix advice.
A fast scan finishes in about 26 seconds and is free; a deep scan (full port scan, content discovery, the complete Nuclei set, headless-browser analysis) takes 5–6 minutes and requires DNS-TXT domain-ownership verification. Either way, you walk away with the checklist verified instead of assumed.
Best practices for application security aren't exotic — they're this list, done consistently, every release. Automate the parts you can, and spend your human time on the business-logic risks a scanner can't reason about.
Frequently asked
What should a web application security checklist cover?
At minimum: HTTPS and TLS configuration, security headers and Content Security Policy, exposed secrets and credentials, access control and sensitive path exposure, dependencies with known vulnerabilities, DNS and email authentication (SPF/DKIM/DMARC), and ongoing monitoring. Each item should be checked, understood, and verified with a concrete tool or standard.
How often should I run a web app security scan?
Run a full scan before every launch or major release, and schedule a recurring scan (daily or weekly) for production. Configuration drifts: a header gets removed in a refactor, a new subdomain is exposed, a certificate expires. Periodic scanning catches regressions you would otherwise ship unnoticed.
What is the difference between SAST and DAST?
SAST (static application security testing) analyzes your source code without running it, so it needs repository access. DAST (dynamic application security testing) probes the running application from the outside, the way an attacker would, and needs no source access. An external scanner like SteelSuit is closer to DAST: it tests the live domain as a black box.
Can automated vulnerability scanning tools replace a manual pentest?
No. Automated vulnerability scanning tools give you broad, fast, repeatable coverage of common misconfigurations and known issues, which is most of the checklist. A manual penetration test adds human reasoning about business logic and chained exploits. Use automation as the baseline and pentesting for depth on critical apps.
Do I need source-code access to check my web app's security?
No. Many of the most common and most damaging issues — missing TLS hardening, absent security headers, exposed .env files, leaked API keys in JavaScript, broken email authentication — are all visible from the outside. An external black-box scan checks these without any agent, plugin, or repository access.