Before you launch a website or a significant new feature, a security check is as important as a functional test. A publicly accessible site is immediately exposed to automated scanners, bots, and attackers — and the window between "just launched" and "first probed" is measured in minutes, not days. This 15-point checklist covers the most common pre-launch security gaps, with specific verification steps for each.
The 15-Point Pre-Launch Security Checklist
1. HTTPS is enabled on all pages
Not just the homepage or checkout page — every page. Verify by loading a non-HTTPS URL and confirming it redirects to HTTPS automatically. Check that the redirect returns a 301 (permanent), not 302.
2. HSTS header is configured
HTTP Strict Transport Security tells browsers to always use HTTPS. Check the response headers for Strict-Transport-Security: max-age=31536000; includeSubDomains. A max-age below 6 months (15768000 seconds) is too short.
3. Content Security Policy (CSP) is set
CSP restricts which scripts, styles, and resources can load on your pages. Even a basic CSP (default-src 'self') significantly reduces XSS risk. Verify in DevTools → Network → response headers. A missing CSP is a common finding in security audits.
4. X-Frame-Options or frame-ancestors CSP is set
Prevents your pages from being embedded in iframes on other domains (clickjacking protection). Set X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none'.
5. X-Content-Type-Options: nosniff is set
Prevents browsers from guessing the MIME type of responses. Set X-Content-Type-Options: nosniff. One line, near-zero cost, eliminates a class of content injection attacks.
6. Session cookies have HttpOnly and Secure flags
Check in DevTools → Application → Cookies. Your session cookie must have both flags. HttpOnly prevents JavaScript from reading it. Secure prevents transmission over HTTP. Also set SameSite=Lax or Strict to protect against CSRF.
7. No sensitive files are accessible
Manually test: append /.env, /.git/config, /backup.zip, /database.sql, /phpinfo.php to your domain. Each should return 404 or 403, never 200. A single exposed .env file can contain database credentials, API keys, and secrets.
8. Directory listing is disabled
Try accessing a directory URL like /images/ or /assets/. It should return 403 or redirect — not a file listing. Directory listing enabled on a production server exposes your file structure to attackers.
9. Debug mode / error verbosity is off
Verbose error pages that include stack traces, file paths, or SQL queries expose internal implementation details. Trigger a 500 error (if possible) and verify the response is a generic error page, not a framework debug screen.
10. Server version is not disclosed
Check the Server and X-Powered-By response headers. They should not reveal software versions (e.g., Apache/2.4.51 or PHP/8.1.2). Version disclosure helps attackers identify CVEs to exploit.
11. Subresource Integrity (SRI) is set on external scripts
If you load JavaScript from a CDN or third-party host, add integrity and crossorigin attributes. This ensures your page fails safely if the external script is compromised. Payment pages especially must have SRI on every external script.
12. Authentication has rate limiting
Your login endpoint should not allow unlimited password attempts. Test by making 10+ rapid POST requests to your login URL and verifying rate limiting kicks in (429 Too Many Requests or a temporary lockout).
13. SSL certificate autorenew is configured
An expired certificate takes your site offline and triggers browser security warnings. Verify your certbot cron, AWS Certificate Manager autorenew, or hosting provider's autorenew setting is active. Check the expiry date: openssl s_client -connect yourdomain.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates
14. Dependencies are up to date
Run npm audit (Node.js), pip-audit (Python), or your language equivalent. Fix HIGH and CRITICAL vulnerabilities before launch. Known-vulnerable dependencies are one of the most common root causes of breaches.
15. Run a full vulnerability scan
All of the above can be verified manually, but a vulnerability scanner catches things manual checks miss — misconfigured CORS, open redirects, injection indicators, missing headers on specific paths. Run this as your final gate before launch.
How Shieldome Checks This
Shieldome automates verification of items 1–11 and 15 in this checklist — covering the majority of pre-launch security requirements in a single 2–5 minute scan. Specifically:
- Items 1–2: HTTPS redirect check + HSTS header detection and max-age validation
- Items 3–5: All major security headers checked for presence and configuration
- Item 6: Cookie flag analysis on all Set-Cookie headers
- Item 7: Probes 20+ sensitive file paths automatically
- Item 8: Directory listing detection on common asset directories
- Items 9–10: Error verbosity and server version header checks
- Item 11: SRI attribute detection on external scripts
- Item 15: Full OWASP Top 10 (2021) coverage across 40+ controls
Run a Shieldome scan as your final pre-launch gate. It verifies the hardest-to-remember items and produces a PDF report documenting your security posture at launch — useful evidence if you ever need to demonstrate due diligence.
Frequently Asked Questions
Do I need to do this for every deployment or just major launches?
Run the full checklist for major launches (new site, new major feature). For routine deploys, focus on items that your changes could affect — if you updated dependencies, re-check item 14; if you added a new page with external scripts, re-check item 11. Running a Shieldome scan on every significant deploy takes 5 minutes and catches regressions.
What is the most commonly missed item?
In practice, items 3 (CSP) and 11 (SRI on external scripts) are most often missing on pre-launch sites. Security headers are easy to add but rarely set up correctly on the first attempt, and SRI is overlooked because adding it requires generating a hash of external script content.
Is this checklist sufficient for PCI DSS compliance?
This checklist covers significant overlap with PCI DSS 4.0 web application requirements (particularly Requirement 6), but PCI compliance requires additional controls beyond web security — network segmentation, access logging, key management, and a formal vulnerability scanning program with an Approved Scanning Vendor. Use this checklist as a baseline, not a compliance substitute.
What if I find issues the day before launch?
Security headers (items 3–5) and cookie flags (item 6) can be fixed in minutes with a config change. Server version disclosure (item 10) is typically a one-line server config change. These should not delay a launch. Sensitive file exposure (item 7) or debug mode (item 9) are higher urgency and may warrant a short delay to fix properly.
How do I generate an SRI hash for external scripts?
Use the SRI Hash Generator at srihash.org, or run: curl -s https://cdn.example.com/script.js | openssl dgst -sha384 -binary | openssl base64 -A. Prefix the result with sha384- and use it as the integrity attribute value.
Security before launch is always cheaper than security after a breach. Run a free Shieldome scan as your final pre-launch gate and launch with confidence.