Web App Security Checklist: What to Fix Before You Launch to Real Users

Shipping to real users is exciting. A security incident one week later is not. The good news is that the most common vulnerabilities in early-stage web apps are not exotic — they are predictable, preventable, and fixable before you launch. This checklist covers the high-impact items that matter most for a startup web application.

Force HTTPS everywhere. Your app should redirect all HTTP traffic to HTTPS with a permanent redirect. Set an HSTS (HTTP Strict Transport Security) header with a max-age of at least six months. This tells browsers to never connect to your domain over plain HTTP, even if a user types it manually. If you are running nginx, this is two lines in your server configuration.

Secure your authentication layer. If you built your own auth, verify that passwords are hashed using bcrypt or Argon2 — never MD5, SHA1, or plain text. Session tokens must be stored in httpOnly cookies, not in localStorage (localStorage is accessible by any JavaScript on the page, including injected scripts from third-party libraries). Set the Secure flag on cookies so they are only sent over HTTPS. Implement rate limiting on your login endpoint — five failed attempts per minute per IP is a reasonable starting threshold.

Validate all input on the server. Client-side validation is a user experience feature, not a security feature. Every field your API accepts must be validated on the server regardless of what the frontend sends. SQL injection and cross-site scripting (XSS) both come from accepting user-supplied strings and passing them directly into queries or HTML without sanitisation. Use parameterised queries (prepared statements) for every database interaction — never string-concatenate user input into a SQL query. Your ORM probably does this for you by default, but verify it.

Set security-related HTTP headers. The three most important are Content-Security-Policy (controls which scripts can run on your pages, reducing XSS risk), X-Content-Type-Options: nosniff (prevents browsers from guessing content types), and X-Frame-Options: DENY or SAMEORIGIN (prevents clickjacking). Libraries like Helmet for Express.js set sensible defaults for all of these with two lines of code.

Lock down your API. Every API endpoint that touches user data must require authentication. Check not just that a token is present, but that the authenticated user has permission to access the specific resource being requested. Returning user A's data to authenticated user B (because you only checked that a valid token was present, not whose token it was) is an Insecure Direct Object Reference vulnerability — one of the most common API security bugs.

Audit your dependencies. Run npm audit (for Node.js) or pip-audit (Python) before launch and fix any critical or high-severity vulnerabilities. Third-party packages that have not been updated in two or more years and have open CVEs are a risk. You do not need to update every package, but address anything flagged as high or critical.

Secure your environment variables and secrets. No API keys, database passwords, or service credentials in your codebase or git history. If a secret was ever committed, even to a private repo, rotate it immediately. Use a secrets manager (AWS Secrets Manager, SSM Parameter Store, or a service like Infisical or Doppler) rather than .env files on the server disk.

Enable logging and set up basic monitoring. You need to know when your app crashes, when database queries time out, and when a burst of failed login attempts hits your auth endpoint. A simple setup — structured logs to CloudWatch or Datadog, with an alert on error rate spikes — takes a few hours and has saved many founders from finding out about outages from Twitter.

Take a backup before launch and test that you can restore from it. This sounds obvious but most teams skip it. Run a restore drill on a staging environment. Verify the restored data is correct. Document how long the restore takes. A backup you have never tested is not a backup.

None of these require specialised security expertise. They are configuration decisions and code patterns that any production deployment should include. If you are not sure which of these gaps your current app has, a production readiness audit — reviewing your codebase, infrastructure configuration, and auth setup — is a good investment before you start acquiring paying users.