OWASP Top 10 for startups: a practical security checklist

Security can feel like a luxury for an early-stage team. There's always a feature to ship, and breaches seem like something that happens to bigger companies.

But most real-world breaches don't involve exotic techniques. They exploit a familiar set of weaknesses: the ones catalogued in the OWASP Top 10. Covering them is achievable for any team, and much cheaper than cleaning up afterwards.

This checklist is mapped to the OWASP Top 10:2025, the current edition. For each category you'll find what it means in plain language, what usually goes wrong in startups, and the specific steps that prevent it.

#How to use this checklist

• Work top to bottom. The list is roughly ordered by how often each risk appears in real applications.
• Turn items into habits. Many checks belong in code review templates and CI pipelines, not a one-off audit.
• Be honest. A checklist where everything is ticked by default is worse than none.

#A01: Broken access control

Users can do or see things they shouldn't: another customer's invoice, an admin page, someone else's files. It's been the number one risk for years, and the 2025 edition also absorbs server-side request forgery (SSRF) into this category.

What goes wrong: permission checks exist only in the user interface; IDs in URLs can be changed to view other records; admin endpoints are "hidden" rather than protected.

Checklist:

• Check permissions on the server for every request, never only in the UI.
• Deny by default; grant access explicitly by role and ownership.
• Scope every database query to the current user or organisation.
• Use unguessable identifiers, but don't rely on them for security.
• Validate and restrict any URL your server fetches on a user's behalf (SSRF).
• Write automated tests that try to access another user's data.

#A02: Security misconfiguration

The application is secure in theory, but deployed insecurely: default passwords, open cloud storage, verbose error pages, unnecessary services.

Checklist:

• Set security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, and frame protection.
• Disable debug routes, stack traces and verbose errors in production.
• Keep storage buckets private by default; review public access regularly.
• Remove default accounts and change default credentials everywhere.
• Manage infrastructure as code, so configuration is reviewed like code.
• Keep development, staging and production secrets separate.

#A03: Software supply chain failures

New in 2025. Your application is mostly other people's code: frameworks, packages, build tools, CI actions and container images. A compromised or vulnerable dependency becomes your vulnerability.

Checklist:

• Run dependency scanning (for example npm audit, Dependabot or similar) in CI, and patch critical advisories quickly.
• Commit lockfiles and use them in every build.
• Keep dependencies few; remove unused packages.
• Pin third-party CI actions and base images to specific versions.
• Protect your main branch: required reviews, no direct pushes.
• Limit who can publish releases and deploy to production, and use multi-factor authentication for those accounts.
• Load third-party scripts only from sources you trust, and restrict them with your Content Security Policy.

#A04: Cryptographic failures

Sensitive data is exposed because it isn't encrypted, or is encrypted badly.

Checklist:

• Enforce HTTPS everywhere with HSTS.
• Hash passwords with a modern algorithm such as Argon2 or bcrypt, never plain hashes like SHA-256.
• Encrypt sensitive data at rest, especially backups.
• Never write your own cryptography; use well-reviewed libraries.
• Store secrets in a secrets manager or environment variables, never in the repository.
• Classify your data: know which fields are sensitive and where they flow.

#A05: Injection

Untrusted input is interpreted as code or commands: SQL injection, cross-site scripting (XSS), command injection, template injection.

Checklist:

• Use parameterised queries or an ORM; never build queries by concatenating strings.
• Rely on your framework's automatic output encoding, and avoid bypassing it.
• Sanitise any user-supplied HTML with a proven library before rendering it.
• Validate input on the server: type, length, format and allowed values.
• Encode user data in every context it appears, including emails, PDFs and logs.
• Never pass user input to shell commands.

#A06: Insecure design

Some flaws can't be fixed with better code because the design itself is unsafe: a password reset that can be guessed, a referral scheme that can be farmed, a contact form that can send unlimited emails.

Checklist:

• Threat-model new features: what could an attacker, or a bored teenager, do with this?
• Rate-limit sign-up, login, password reset and contact forms.
• Put business limits on costly actions: emails sent, files uploaded, credits issued.
• Design abuse cases alongside user stories.
• Review designs for features that move money, change permissions or expose data.

#A07: Authentication failures

Weak login, session or recovery mechanisms let attackers take over accounts.

Checklist:

• Offer multi-factor authentication, ideally passkeys, and require it for admins.
• Protect against credential stuffing with rate limits and breached-password checks.
• Use secure, HttpOnly, SameSite session cookies, and rotate session IDs at login.
• Expire sessions sensibly and let users sign out of all devices.
• Make password reset tokens single-use and short-lived.
• Don't reveal whether an email address has an account in login or reset errors.

#A08: Software or data integrity failures

Code or data is trusted without verifying it hasn't been tampered with: unsigned updates, unsafe deserialisation, unverified webhooks.

Checklist:

• Verify signatures on webhooks from payment and other providers.
• Avoid deserialising untrusted data into objects.
• Sign firmware and app updates, and verify signatures before installing.
• Use subresource integrity or self-host critical third-party scripts.

#A09: Logging and alerting failures

Attacks go unnoticed because nothing records them, or nobody is told.

Checklist:

• Log security events: logins, failed logins, permission changes, password resets, admin actions.
• Never log passwords, tokens or full payment details.
• Alert on unusual spikes: failed logins, 403s, password resets, sign-ups.
• Keep logs long enough to investigate an incident, and protect them from tampering.
• Write down who responds to an alert, and how.

#A10: Mishandling of exceptional conditions

New in 2025. Applications that fail in unsafe ways: an error that skips a permission check, a timeout that leaves a payment half-processed, an exception that leaks internal details.

Checklist:

• Fail closed: if a security check errors, deny the action.
• Return generic error messages to users; keep details in server logs.
• Use transactions so multi-step operations either complete or roll back.
• Set timeouts on every outbound request, and handle them explicitly.
• Test unhappy paths: invalid input, missing data, slow or failing dependencies.

#Quick wins for this week

If you only have a few hours, start here:

1. Turn on dependency scanning in CI and fix critical findings.
2. Add security headers and confirm HTTPS-only with HSTS.
3. Add rate limits to login, sign-up, password reset and contact forms.
4. Write one automated test that tries to read another user's data.
5. Enable MFA on every admin, cloud and code-hosting account.

#Make it routine

Security is a habit, not a project.

The teams that stay secure aren't the ones with the biggest budgets. They're the ones that build these checks into everyday work:

• add a short security section to your pull request template
• run scanners on every build, and fail the build on critical issues
• review access to production and third-party services every quarter
• schedule an independent review before major launches and enterprise deals

We apply this checklist to our own work, including this website. For an independent assessment of your application, from a focused OWASP review to a full penetration test, see our IT consulting and security services or get in touch.