A security incident in the first months after launch can cost you customer trust that took years to build. The good news is that most common attacks exploit a short list of well-known gaps that are straightforward to close before you go live.
Before launching a web application, make sure traffic is encrypted, authentication and access control are solid, every input is validated, secrets are kept out of code, dependencies are patched, and you have logging, backups and a plan for incidents. The 15 checks below cover the essentials and map closely to the OWASP Top 10.
What is the OWASP Top 10 and why does it matter?
The OWASP Top 10 is a widely used awareness document from the Open Worldwide Application Security Project that lists the most critical categories of web application security risk, such as broken access control, injection and security misconfiguration. It is not a complete standard, but it is the best starting point for any pre-launch review. For a deeper checklist, OWASP also publishes the Application Security Verification Standard (ASVS).
The 15-point pre-launch security checklist
| # | Check | What good looks like |
|---|---|---|
| 1 | HTTPS everywhere | TLS on every page and API, HTTP redirected to HTTPS, HSTS enabled |
| 2 | Password storage | Passwords hashed with Argon2id or bcrypt, never stored in plain text or with fast hashes |
| 3 | Multi-factor authentication | MFA available for users and enforced for admins |
| 4 | Access control | Every request checked server-side for permission, including record ownership |
| 5 | Input validation | Validated on the server against a schema; parameterised queries or an ORM to prevent SQL injection |
| 6 | Output encoding | User content escaped by the templating framework to prevent cross-site scripting |
| 7 | Secure sessions and cookies | Cookies set as HttpOnly, Secure and SameSite; sessions expire and rotate on login |
| 8 | CSRF protection | Anti-CSRF tokens or SameSite cookies on state-changing requests |
| 9 | Security headers | Content-Security-Policy, X-Content-Type-Options and frame protections configured |
| 10 | Secrets management | No keys in the repository; secrets in environment variables or a manager such as AWS Secrets Manager |
| 11 | Dependency updates | Known vulnerabilities checked with Dependabot, npm audit, Composer audit or Snyk |
| 12 | Rate limiting | Limits on login, password reset, OTP and public APIs to slow brute-force attacks |
| 13 | File uploads | Type and size checked, files stored outside the web root or in object storage, never executed |
| 14 | Logging and monitoring | Security events logged without sensitive data, with alerts on unusual activity |
| 15 | Backups and recovery | Automated, encrypted backups that have actually been restored in a test |
Which checks are most often missed?
Broken access control
Hiding a button in the interface is not security. If a user can change an ID in a URL or API request and see someone else's invoice, the application has broken access control. Every endpoint must check, on the server, that the current user is allowed to see or change that specific record.
Secrets in code
API keys and database passwords committed to a repository are easy to leak, especially if the repository is ever made public or shared with a contractor. Use a secret scanner such as GitHub secret scanning or Gitleaks, and rotate any key that has ever been committed.
Untested backups
A backup you have never restored is a hope, not a plan. Run a restore into a separate environment before launch and record how long it takes.
How should security fit into your development process?
- Automate checks in CI. Run dependency scanning, linting and tests on every pull request. Our guide to setting up a CI/CD pipeline shows where these fit.
- Review code with security in mind. Make access control and input handling part of every code review.
- Apply least privilege to cloud accounts, database users and admin panels.
- Separate environments. Keep staging and production data, credentials and access apart.
Do you need a penetration test before launch?
It depends on what you store and who your customers are. If you handle payments, health data, financial records or enterprise clients, an independent penetration test is strongly advisable, and some customers or regulations will require one. For a smaller product, a careful internal review against this checklist and the OWASP Top 10, plus automated scanning with a tool such as OWASP ZAP, is a sensible minimum. Either way, plan a re-test after major changes.
What happens after launch?
Security is ongoing. Keep dependencies patched, review access when people leave, watch your logs and have a simple incident response plan: who is contacted, how you contain the issue and how you inform affected users. Our article on application monitoring and incident response covers this in detail, and what a maintenance plan should include explains how to keep patches on schedule.
Key takeaways
- Most common attacks exploit well-known gaps: weak access control, injection, leaked secrets and outdated dependencies.
- Use the OWASP Top 10 as your baseline and automate dependency and secret scanning in CI.
- Test your backups and consider a penetration test if you handle sensitive data.
Want a second pair of eyes before launch? We can review your application against this checklist, fix the gaps and keep it patched afterwards. Ask about maintenance and security support, or see how we work.