What the OWASP Top 10:2025 means for a SaaS team

The OWASP Top 10 is useful, but it is easy to use it badly. A team copies the ten headings into a spreadsheet, marks a few scanners as complete, and calls the application reviewed.

That misses the point. The list is an awareness document, not a test plan. Its value is in showing where real applications keep failing and where a team should spend its attention.

The OWASP Top 10:2025 changed enough to be worth revisiting. It is based on contributed data covering more than 2.8 million applications, plus a community survey intended to capture risks that automated tools do not measure well.

Three changes matter most for a modern SaaS product.

Access control is still the first thing to test

Broken Access Control remains A01. OWASP reports that an average of 3.73% of tested applications had at least one weakness from the 40 CWEs grouped into this category.

That percentage can sound small until you look at what it includes:

A user changing /api/invoices/123 to /api/invoices/124 and seeing somebody else's invoice
A normal account calling an admin endpoint directly
A tenant member reading records that belong to another tenant
A backend fetching an attacker-controlled URL with access to internal services

OWASP now groups Server-Side Request Forgery under Broken Access Control. That makes sense in practice. The underlying question is often the same: what is this identity or service allowed to reach?

For a SaaS review, start with roles and objects, not endpoints. Make a small matrix:

Role	Object	Read	Create	Update	Delete
Anonymous	Public profile	Yes	No	No	No
Member	Own invoice	Yes	No	No	No
Admin	Tenant invoices	Yes	Yes	Yes	Yes

Then test every important path against that matrix. Try valid requests with the wrong user, wrong tenant, wrong role, and wrong object ID. A scanner cannot infer your business ownership rules reliably.

GitHub's Octoverse 2025 supports the same priority. Broken Access Control became the most common CodeQL alert, appearing in more than 151,000 repositories, up 172% year over year. GitHub linked part of that growth to permissions in CI/CD and generated scaffolding that omitted authorization checks.

The useful lesson is not that AI code is automatically unsafe. It is that authentication is easy to scaffold while authorization depends on product context. A tool can add requireUser(). It cannot know that a support agent may read a ticket but must not export the customer's billing history.

Configuration moved from fifth to second

Security Misconfiguration is now A02, up from fifth place in the 2021 list. OWASP found one or more related weaknesses in an average of 3% of tested applications.

Modern apps are configuration-heavy. Security behavior lives in:

Cloud IAM and storage policies
Supabase RLS or Firebase rules
CORS and trusted origins
Framework middleware
Environment variables and build settings
Webhooks and redirect allowlists
CDN and cache behavior
Default roles in databases and SaaS integrations

The code can be clean while the deployed application is exposed.

A practical review needs both source and a real staging deployment. Source tells you what the team intended. The running environment tells you what actually shipped.

Some checks are simple:

Open the production JavaScript bundle and search for key prefixes, tokens, internal hostnames, and source-map references.
Call APIs without a session, with an expired session, and from an unexpected origin.
Review every public storage bucket and database table.
Check whether verbose errors expose SQL, filesystem paths, or framework internals.
Compare staging and production security settings. They often drift.

Do not treat a green dependency scan as evidence that configuration is sound. They answer different questions.

The supply chain is bigger than package versions

A03 is now Software Supply Chain Failures. It expands the old "Vulnerable and Outdated Components" category beyond package CVEs.

OWASP now asks teams to think about the whole path from source to release:

Who can change a dependency or lockfile?
Can a pull request workflow access production secrets?
Are GitHub Actions pinned to a trusted version?
Who can publish the package or deploy the app?
Are build artifacts signed or otherwise verified?
Can one compromised maintainer reach production?

This category had limited representation in OWASP's testing data, but the related CVEs had the highest average exploit and impact scores in the report. OWASP also notes that supply-chain weaknesses are difficult to test at scale, which is exactly why a normal web scan does not settle the question.

For a small team, the first controls do not need to be complicated:

Require review before merging to the production branch
Keep the lockfile in version control
Use Dependabot or an equivalent update process
Give CI workflows the minimum token permissions they need
Keep production secrets out of pull request workflows
Remove unused deploy keys, integrations, and package tokens
Turn on protected environments for production deployment

The new tenth category is about failure behavior

Mishandling of Exceptional Conditions is new at A10. It covers systems that behave unsafely when something unusual happens: an API times out, a value is missing, a transaction partially fails, or an authorization dependency is unavailable.

This is where "fail open" bugs live.

Imagine an authorization service that returns an error. The safe response is to deny the action and log the failure. The dangerous response is to catch the exception, continue, and assume the user is allowed.

Test the unhappy paths:

What happens when a webhook arrives twice?
What happens when payment succeeds but the database write fails?
What happens when a role lookup times out?
What happens when a JSON field has the wrong type?
What happens when an upload is larger than expected?

Error handling is security logic. It deserves the same review as the normal path.

A better way to use the list

Do not promise that an app is "OWASP compliant." OWASP does not certify applications, and a Top 10 review is not complete coverage.

Use the list to shape a focused review:

Map identities, roles, tenants, and sensitive objects.
Review the deployed configuration, not just the repository.
Inspect the path from dependency changes to production.
Exercise abnormal and partial-failure conditions.
Keep injection, cryptography, authentication, integrity, and logging in scope too.

The 2025 list is a useful correction for teams that equate security with finding vulnerable packages. Packages matter. So do the authorization rule, cloud policy, CI token, and error branch that no generic scanner understands.