OWASP Top Ten for SaaS in 2026

What you need to know

• Broken access control is the most common and consequential vulnerability in SaaS applications. Every data access in the application should verify that the requesting user has permission to access that specific resource.
• SQL injection is preventable with parameterized queries and prevented by default by most ORMs. It still appears in code that uses string concatenation for SQL construction. Audit every raw SQL call in the codebase.
• Security misconfiguration in cloud infrastructure is responsible for a significant portion of publicly reported data breaches. S3 bucket access policies, security group rules, and API key permissions should be reviewed at least quarterly.
• Cryptographic failures are preventable with modern library defaults: bcrypt or Argon2 for passwords, TLS 1.2+ for transport, and AES-256 for symmetric encryption. Using outdated cryptography is almost always a legacy decision that persists through negligence.
• The OWASP Top Ten should be a checklist in every security review, not a document that gets read once and filed. Each category should have a concrete answer for how the application addresses it.

The core argument

The OWASP Top Ten is valuable because it gives a non-security engineer a vocabulary for the category of security problem that produced most of the major breaches in recent history. A developer who understands what broken access control means, what injection means, and what security misconfiguration means can identify these patterns when writing code and ask the right questions during code review. Security expertise helps, but the OWASP categories are broad enough that any engineer can use them as a checklist.

Broken access control deserves special attention because it is architecturally pervasive and easy to introduce through a single missed check. The pattern appears in multi-tenant SaaS constantly: the API endpoint that fetches a resource by ID does not verify that the ID belongs to the requesting tenant, allowing one tenant to access another's data by guessing or enumerating IDs. This is the insecure direct object reference vulnerability, and it is preventable with one filter on every database query. In my experience reviewing SaaS codebases, the most common form is: the user ID is in the JWT, the resource ID is in the URL, and the query joins them. But when the developer is moving fast, the tenant check is occasionally left out. One missed check creates a data exposure vulnerability that is indistinguishable from the correct implementation until an attacker finds it.

The 2023 OWASP update added two categories that are particularly relevant for modern SaaS: insecure design and software and data integrity failures. Insecure design addresses the gaps that static analysis and code review miss: architectural decisions that make it structurally impossible to enforce security correctly. A multi-tenant architecture that shares database schema without tenant isolation in every query is an insecure design. No amount of code review will catch every missing tenant filter if the design does not enforce it. Addressing insecure design requires security thinking at the architecture stage, not just during implementation.

Common mistakes

1. Only enforcing authorization at the route level, not the data level. Checking that a user is authenticated before accessing a route is necessary but not sufficient. The application must also verify that the specific resource being accessed belongs to the requesting user or tenant. Route-level authorization prevents unauthenticated access; object-level authorization prevents authenticated users from accessing each other's data.

1. Using string concatenation for SQL queries in any part of the codebase. Even when 99 percent of queries use an ORM, a single raw query built with string concatenation is a potential SQL injection vulnerability. Audit the codebase for raw query calls and replace string concatenation with parameterized queries.

1. Leaving verbose error messages in production responses. Stack traces, database error messages, and framework internals exposed in API error responses reveal implementation details that help attackers understand the system. Production error responses should return generic error messages with a request ID for support purposes; the detailed error should be logged server-side.

1. Not rotating secrets after a suspected exposure. When a secret (API key, database password, signing key) may have been exposed through logs, repository commits, or error messages, the response is immediate rotation, not investigation first. Rotate first, investigate second. A secret that might be compromised should be treated as compromised.

1. Skipping the OWASP checklist for new features. New features introduce new attack surface. Each new feature should be evaluated against the OWASP Top Ten categories during design review, not after launch. Features that involve user-supplied URLs (SSRF risk), file uploads (path traversal, malware execution risk), or new data access patterns (broken access control risk) should receive specific security attention.

Where to start

1. Audit every API endpoint for object-level authorization. For each endpoint that returns or modifies a resource identified by an ID, verify that the query includes a filter on the user or tenant that owns the resource. Document the authorization check for each endpoint. Missing checks are the most common source of data exposure in SaaS.

1. Search the codebase for raw SQL construction. Grep for string concatenation in SQL queries. Every instance of query building with string interpolation should be replaced with parameterized queries. This is a one-time exercise that eliminates the SQL injection surface permanently.

1. Review cloud infrastructure permissions quarterly. For each S3 bucket, security group, IAM role, and API key: who can access it, from where, and is that the minimum permission required for the application to function? Permissions that expand over time without review create the security misconfiguration exposure that causes preventable incidents.

Related reading

• Insecure Direct Object References: The Bug Founders Underestimate
• OAuth 2.0 Without Tears: A Founder Engineer's Guide
• JWT Best Practices in 2026: What Has Changed
• ISO 27001 for Engineering Founders: A Practical Reading