Web Application Security Checklist for Founders

How to Use This Checklist

Work through each section with your engineering lead. Anything you cannot answer "yes" to is a task for your backlog. The items align with the OWASP Top 10 and the OWASP Application Security Verification Standard.

Authentication

• Passwords are hashed with a modern algorithm such as Argon2 or bcrypt, never stored in plain text.
• Multi-factor authentication is available, and required for admin accounts.
• Login, password reset and sign-up are rate limited.
• Sessions expire, and are invalidated on logout and password change.
• Where possible, use a proven identity provider instead of building authentication yourself.

Access Control

• Every API endpoint checks that the current user may access the specific record requested, not just that they are logged in.
• Tenant data is isolated so one customer can never read another's data.
• Admin features are separate and audited.
• Access is denied by default; permissions are granted explicitly.

Broken access control is the most common serious finding in our penetration tests.

Input and Output Handling

• All input is validated on the server against a schema.
• Database queries use parameterised statements or a safe query builder.
• Output is encoded for the context it appears in (HTML, URLs, JavaScript).
• File uploads are checked for type and size and stored outside the web root.

Data Protection

• All traffic uses HTTPS, with HSTS enabled.
• Sensitive data is encrypted at rest.
• Secrets live in a secrets manager, never in the code repository.
• You collect only the personal data you actually need, and you know where it is stored.

Security Headers

• A Content Security Policy restricts where scripts can load from.
• X-Content-Type-Options, Referrer-Policy and frame protections are set.
• Cookies use Secure, HttpOnly and SameSite attributes.

Dependencies and Pipeline

• Dependencies are scanned automatically for known vulnerabilities.
• Secret scanning runs on every commit.
• The main branch is protected, and changes require review.
• Production deployments are automated and can be rolled back quickly.

Our DevSecOps practice sets these controls up as part of delivery.

Logging and Monitoring

• Security-relevant events (logins, permission changes, failed access) are logged.
• Logs do not contain passwords, tokens or full card numbers.
• Alerts fire on unusual patterns such as spikes in failed logins.
• You have a written incident response plan. Our incident response runbook template is a good starting point.

Frequently Asked Questions

What is the most common web application vulnerability?

Broken access control, where users can reach data or actions they should not, consistently tops industry rankings including the OWASP Top 10.

Do small startups really need all of this?

Most items are cheap to put in place early and expensive to retrofit. Prioritise authentication, access control, HTTPS and secret handling first.

How often should I review this checklist?

Review it before each major release and at least every quarter.

Is a security checklist a substitute for a penetration test?

No. A checklist covers known good practice. A penetration test finds the issues specific to your application's logic.