Most security incidents are caused by preventable configuration gaps, not sophisticated zero-day exploits. This 20-point checklist covers every layer of web application security that needs to be verified before you push to production, with brief explanations and remediation steps for each item.
Anay Pandya
1,824 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
Most web application breaches are not caused by sophisticated nation-state attacks or undiscovered zero-days. They happen because someone shipped to production without enabling HTTPS, left an API key in a public GitHub repo, or forgot to add rate limiting to a login endpoint.
This website security checklist covers 20 concrete checks across every layer of your stack. Work through it before any major launch and keep it as part of your release process. Each item includes a brief explanation of why it matters and what to do if you fail the check.
Is your site actually secure?
Run a free check — 60 seconds
Keep reading
Why it matters: If any page of your site loads over plain HTTP, credentials, session tokens, and form data are transmitted in clear text and can be intercepted on the network.
Check: Visit http://yourdomain.com and confirm it redirects to HTTPS. Check every subdomain.
Fix: Configure a permanent (301) redirect from HTTP to HTTPS at the server or CDN level. Get a free certificate from Let''s Encrypt if you do not have one.
Why it matters: An expired certificate causes browser warnings that drive users away and can trigger security alerts in monitoring tools. Expiry-driven downtime is entirely preventable.
Check:
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -datesFix: Set up automated certificate renewal (Let''s Encrypt with Certbot or ACME client, Cloudflare auto-renew). Set a calendar reminder 60 days before manual certificate expiry.
Why it matters: TLS 1.0 and 1.1 are deprecated and contain known vulnerabilities (BEAST, POODLE). Accepting them exposes users to downgrade attacks.
Check:
nmap --script ssl-enum-ciphers -p 443 yourdomain.comFix: In Nginx: ssl_protocols TLSv1.2 TLSv1.3;. In Apache: SSLProtocol -all +TLSv1.2 +TLSv1.3.
Why it matters: Without HSTS, attackers on the same network can intercept the initial HTTP request before your redirect, performing an SSL stripping attack.
Check: curl -I https://yourdomain.com | grep -i strict-transport
Fix: Strict-Transport-Security: max-age=31536000; includeSubDomains
Why it matters: CSP is the primary defence against XSS. Without it, injected scripts can load resources from any domain, steal cookies, or exfiltrate data.
Check: curl -I https://yourdomain.com | grep -i content-security-policy
Fix: Start with Content-Security-Policy-Report-Only: default-src ''self''; report-uri /csp-reports, collect violations, then switch to enforcement.
Why it matters: Without framing protection, attackers can embed your site in an iframe, overlay it with a transparent decoy page, and capture user clicks or keystrokes (clickjacking).
Check: curl -I https://yourdomain.com | grep -i x-frame
Fix: X-Frame-Options: SAMEORIGIN or Content-Security-Policy: frame-ancestors ''self''
Why it matters: Without this, browsers may guess (sniff) a file''s content type and execute a text file as JavaScript in a MIME confusion attack.
Fix: X-Content-Type-Options: nosniff (zero risk, add immediately)
Why it matters: Without this, your users'' full URLs (including query parameters that may contain tokens, IDs, or search terms) are sent to every third-party domain they navigate to.
Fix: Referrer-Policy: strict-origin-when-cross-origin
Why it matters:
- Without Secure: cookies can be sent over plain HTTP and intercepted
- Without HttpOnly: JavaScript can read the cookie (XSS can steal session tokens)
- Without SameSite: cookies are sent on cross-origin requests, enabling CSRF attacks
Check: Browser DevTools > Application > Cookies. Verify each cookie has all three flags.
Fix (Express example):
res.cookie(''session'', token, {
httpOnly: true,
secure: true, // Only sent over HTTPS
sameSite: ''strict'', // Or ''lax'' for OAuth flows
maxAge: 3600000, // 1 hour
});Why it matters: If your session ID appears in the URL (e.g. ?sessionid=abc123), it will be logged in server logs, browser history, and sent in the Referer header to third parties.
Check: Navigate your app and confirm session tokens never appear in the URL bar.
Fix: Store sessions in HttpOnly cookies only. If you are using JWT, transmit them in the Authorization header, not in the URL.
Why it matters: Without SPF, anyone can send emails appearing to come from your domain, enabling phishing attacks that impersonate your brand.
Check: dig TXT yourdomain.com | grep spf
Fix: Add a TXT record like v=spf1 include:_spf.google.com ~all (replace with your actual mail provider).
Why it matters: DMARC tells receiving mail servers what to do with emails that fail SPF or DKIM checks. A p=none policy monitors but takes no action. Only p=quarantine or p=reject actually protects your users.
Check: dig TXT _dmarc.yourdomain.com
Fix:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"Start with p=none to monitor, then move to p=quarantine, then p=reject.
Why it matters: Hardcoded API keys, database passwords, and private keys in your codebase are frequently discovered by automated scanners. Once committed to git, they persist even after deletion in later commits.
Check:
# Install truffleHog
pip install trufflehog
# Scan your local repo
trufflehog git file://. --only-verifiedOr use ZeriFlow''s Advanced Scan with a GitHub repo URL — it scans for secrets across the full commit history.
Fix: Move all secrets to environment variables. Rotate any secrets that were ever committed. Use git filter-repo to purge from history.
Why it matters: Vulnerable npm packages (or Python, Ruby, PHP packages) are a common entry point for attackers. The Log4Shell and event-stream incidents showed how devastating a single compromised dependency can be.
Check:
npm audit --audit-level=highFix: Run npm audit fix for minor updates. Review breaking changes before major version upgrades. Use Dependabot or Renovate for automated dependency updates.
Why it matters: Without rate limiting, automated brute-force tools can try millions of password combinations against your login endpoint. Most applications offer no resistance to this by default.
Check: Try sending 20+ rapid POST requests to your login endpoint. Confirm you get rate-limited (429 response) after a threshold.
Fix (Express with express-rate-limit):
import rateLimit from ''express-rate-limit'';
const loginLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 10, // Max 10 attempts per window
message: ''Too many login attempts. Please try again in 15 minutes.'',
standardHeaders: true,
legacyHeaders: false,
});
app.post(''/auth/login'', loginLimiter, loginHandler);Why it matters: Storing passwords in plain text or with MD5/SHA1 means a database breach instantly exposes all user credentials. Modern algorithms like bcrypt, Argon2, or scrypt are intentionally slow and include salting.
Check: Review your user model and auth code.
Fix:
import bcrypt from ''bcryptjs'';
// Hash on registration
const hash = await bcrypt.hash(password, 12); // 12 rounds
// Verify on login
const isValid = await bcrypt.compare(inputPassword, storedHash);Why it matters: Stack traces, database query errors, and detailed exception messages can reveal your tech stack, table names, internal paths, and logic to an attacker. This information is used for reconnaissance.
Check: Trigger a 404, a 500, and an invalid request. Confirm error responses show generic messages, not stack traces.
Fix: Implement a global error handler that logs details internally but returns generic messages to clients:
app.use((err, req, res, next) => {
console.error(err); // Internal logging
res.status(500).json({ error: ''An internal error occurred.'' }); // Safe client response
});Why it matters: Headers like Server: nginx/1.18.0 or X-Powered-By: Express tell attackers exactly which version of your software to look up CVEs for.
Check: curl -I https://yourdomain.com | grep -i "server\\|x-powered-by"
Fix:
- Nginx: server_tokens off;
- Apache: ServerTokens Prod and ServerSignature Off
- Express: app.disable(''x-powered-by'') or use helmet
Why it matters: If your web server serves a directory index when no index.html is present, attackers can browse your file structure and potentially access configuration files, backups, or source code.
Check: Navigate to a directory URL on your server (e.g. https://yourdomain.com/uploads/) and confirm you get a 403 or 404, not a file listing.
Fix:
- Nginx: autoindex off; (off by default, but verify)
- Apache: Remove Indexes from Options in your config
Why it matters: When an incident occurs, you need logs. Without IP addresses, timestamps, request paths, and user agent strings, you cannot determine what happened, when, or from where.
Check: Tail your access log and confirm it captures: timestamp, client IP, HTTP method, URL, response code, response size, and user agent.
Fix (Nginx log format example):
log_format main ''$remote_addr - $remote_user [$time_local] "$request" ''
''$status $body_bytes_sent "$http_referer" ''
''"$http_user_agent" "$http_x_forwarded_for"'';
access_log /var/log/nginx/access.log main;Ensure logs are shipped to a centralised service (Datadog, Logtail, CloudWatch) so they persist even if your server is compromised.
Manually checking all 20 items before every release is time-consuming. The good news is that about half of them can be automated:
Infrastructure checks (1–12, 18, 19) can be automated with a security scanner. ZeriFlow covers TLS, headers, cookies, DNS, email security, and server configuration in a single scan that takes under 60 seconds.
Dependency checks (14) can be automated with npm audit in CI/CD, or with Snyk/Dependabot for continuous monitoring.
Secrets scanning (13) can be automated with ZeriFlow''s Advanced Scan or truffleHog as a pre-commit hook or CI step.
Application-level checks (15–17, 20) require code review — no scanner can fully verify your business logic.
A practical approach: run an automated scan for the infrastructure items, and reserve manual review time for the application-level items that require code inspection.
The goal is not to run this checklist once at launch and forget it. Security is a continuous process — run a subset of these checks on every significant deployment, and the full list before any major release.
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
April 30, 2026
Best SAST Tools for Small Development Teams in 2026 (Free Included)
Monitor your security score
Schedule recurring scans and catch regressions after deployments.