Security12 min

OWASP Top 10 for SaaS applications in 2026

A SaaS-focused walk through the OWASP Top 10 for 2026 — broken access control, injection, insecure design, and more — with real examples, concrete mitigations, and a check for each.

The OWASP Top 10 is the closest thing the industry has to a shared checklist of what will hurt you. The 2026 revision (published as OWASP Top 10:2025) reorders a few categories, folds SSRF into Broken Access Control, and adds new entries for supply chain failures and mishandling of exceptional conditions. For SaaS teams, the headline is the same as it always was: most breaches still trace back to the first category on the list. What follows is the 2026 list translated into SaaS language — with real examples of how each category shows up in a multi-tenant web product, the mitigation that actually works, and a check any engineer can run today.

The 2026 list at a glance

Two new categories and one consolidation separate the 2026 edition from 2021. SSRF is no longer a standalone category — it now lives under Broken Access Control, which keeps its crown at number one. Software Supply Chain Failures enters at number three, and a new category at number ten covers mishandling of exceptional conditions. Here's the full list with the SaaS-specific risks that dominate each category.

RankCategorySaaS examplePrimary mitigation
A01Broken Access ControlTenant A reading Tenant B's invoice by guessing an IDRow-level scoping in every query, plus authz tests
A02Security MisconfigurationDebug endpoint shipping to production with stack tracesInfrastructure-as-code, baseline images, env-aware configs
A03Software Supply Chain FailuresA compromised npm transitive dep exfiltrating env varsLockfiles, SBOMs, pinned versions, Dependabot + review
A04Cryptographic FailuresPasswords hashed with MD5 or stored with a weak KDFArgon2id for passwords, TLS 1.3, managed KMS for secrets
A05InjectionSQL injection via an unescaped search parameterParameterised queries, typed ORMs, output encoding
A06Insecure DesignA password reset that reveals whether an email is registeredThreat model the feature, not just the implementation
A07Authentication FailuresNo rate limit on login, no MFA, weak password resetMFA by default, rate limits, secure reset flows, session hygiene
A08Software or Data Integrity FailuresTrusting an unsigned auto-update or insecure deserialisationSign artifacts, verify integrity, avoid deserialising untrusted data
A09Logging & Alerting FailuresLogs exist but nobody is paged when 5xx spikesCentralised logs, alerts on security events, retention policy
A10Mishandling of Exceptional ConditionsA payment failure silently passes because an exception was swallowedFail closed, propagate errors, test the unhappy path

If you only fix one thing this quarter, fix Broken Access Control. It's number one for a reason — OWASP's data shows the average application has multiple CWEs in this category, and it's the single most common cause of SaaS data leaks we see on incident reviews.

A01 — Broken Access Control

Broken access control is the category most responsible for SaaS data leaks. In a multi-tenant product the canonical bug is an Insecure Direct Object Reference — a URL like /api/invoices/8421 that happily returns the invoice to any authenticated user, regardless of which tenant owns it. The fix is not clever middleware; it is scoping every single query by the caller's tenant ID. Every read, every write, every join.

// Broken — trusts the URL parameter
app.get("/api/invoices/:id", requireAuth, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

// Fixed — scoped to the caller's tenant in the query itself
app.get("/api/invoices/:id", requireAuth, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, tenantId: req.user.tenantId },
  });
  if (!invoice) return res.status(404).end();
  res.json(invoice);
});

The check: pick any authenticated endpoint, create two test tenants, and try to access tenant A's resource from tenant B's session. If any endpoint leaks, you have a pattern problem, not a bug.

A02 — Security Misconfiguration

Security misconfiguration moved up to number two in the 2026 list. For SaaS this shows up as debug endpoints shipping to production, S3 buckets with permissive ACLs, verbose error pages leaking stack traces, default credentials on admin panels, and CORS that allows any origin. The mitigation is boring and effective: treat infrastructure as code, build from hardened baseline images, and make environments differ only in values — never in structure. The check: run a production smoke test that hits /debug, /admin, /.git, and confirms each returns 404.

A03 — Software Supply Chain Failures

A new category for 2026. Every npm install is a trust decision across hundreds of transitive dependencies. The event_stream and ua-parser incidents taught the industry that a single compromised package can exfiltrate secrets from every downstream project. The mitigations are unglamorous: pin dependency versions with lockfiles that are actually committed; generate an SBOM as part of CI; enable automated PRs for dependency updates and require a human review before merging; and scope build-time secrets so they're never exposed to install scripts. The check: run `npm audit --production` and confirm your CI fails on high-severity findings.

A04 — Cryptographic Failures

The classic SaaS mistakes here are hashing passwords with a fast function (MD5, SHA-1, or even unsalted SHA-256), encrypting at rest with a hand-rolled AES implementation, and serving TLS with outdated cipher suites. The fix in 2026: Argon2id for password hashing, managed KMS (AWS KMS, GCP KMS, or Vault) for application secrets, TLS 1.3 only, and HSTS with a preload. The check: run an SSL Labs scan against your production domain and confirm a grade of A or higher.

A05 — Injection

Injection dropped from number three to number five in 2026 — frameworks have improved, typed ORMs have become the default, and the industry finally learned to parameterise. It still dropped fourteen thousand new CVEs into the wild last year, so the drop is relative. The canonical SaaS injection today is a raw SQL query built with template strings, or a MongoDB query that trusts untyped user input in a $where clause.

// Broken — string concatenation into SQL
const rows = await db.query(
  `SELECT * FROM users WHERE email = '${req.body.email}'`
);

// Fixed — parameterised query
const rows = await db.query(
  "SELECT * FROM users WHERE email = $1",
  [req.body.email]
);

// Broken — untyped body into a Mongo filter
const user = await User.findOne(req.body);

// Fixed — extract only the fields you expect
const user = await User.findOne({ email: String(req.body.email) });

Beyond SQL and NoSQL: command injection (shell execs with user input), LDAP injection, and prompt injection in LLM-backed features are all live risks in 2026. The check: grep the codebase for string-template queries and direct `req.body` spreads into database filters.

A06 — Insecure Design

Insecure design is not a bug in the implementation — it's a flaw in the requirements. A password reset flow that confirms whether an email address exists is insecurely designed, even if every line of code is perfect. A billing feature that charges a card before the user confirms the order is insecurely designed. The mitigation is threat modelling: before a feature is built, someone sits down and asks what an attacker would do with it. The check: does your PR template have a 'security considerations' section? Is it ever actually filled out?

A07 — Authentication Failures

Authentication failures in SaaS usually look like one of: no rate limit on login (credential stuffing), optional MFA (most users skip it), enumerable reset flows, weak password requirements, or sessions that never expire. The 2026 default is MFA on by default for admin accounts, passkeys available for user accounts, rate limits at the IP and account level, and reset tokens that are single-use, short-lived, and delivered to a verified channel. Session cookies should be HttpOnly, Secure, SameSite=Lax, and rotated on privilege change.

The most commonly missed check in this category is rate limiting on the password reset endpoint. Many teams rate limit login but forget that reset emails can be used to spam users, enumerate accounts, or trigger email bombing attacks.

A08 — Software or Data Integrity Failures

Trusting an unsigned software update, deserialising untrusted data into live objects, or loading third-party JavaScript from a CDN without Subresource Integrity — all fall under this category. For SaaS teams the two common patterns are: pulling a CI image without verifying its digest, and deserialising user-provided JSON or YAML into class instances that trigger code execution. The fix: verify signatures on everything you pull (container images, build artifacts), use JSON Schema for untyped input, and never deserialise untrusted data into anything that can execute code.

A09 — Logging & Alerting Failures

New naming for 2026: it's no longer enough to log — you have to alert. A breach detected ten weeks late is a breach that became a ransom. Ship structured logs to a centralised sink (Datadog, Grafana Loki, Elastic), alert on security-relevant events (failed logins, 401/403 spikes, privilege escalations, admin actions), and write retention and access policies for the logs themselves. The check: when was the last time your on-call was paged for something other than a 5xx spike?

A10 — Mishandling of Exceptional Conditions

The newest category, introduced in 2026. It covers swallowed exceptions, code paths that fail open (returning success when they should return failure), and logical errors in unusual edge cases. A classic SaaS example: a payment webhook handler that catches a database error, logs it, and returns a 200 — the payment provider stops retrying, the order is marked unpaid, the customer is never charged. Mitigation: default to failing closed, always propagate errors up to the boundary, and write tests for the unhappy paths (the happy path takes care of itself).

Running the list as a quarterly audit

The Top 10 is not something you read once and forget. Teams that take it seriously run it as a quarterly checklist: pick one category, do a focused audit across the codebase, document what you found, fix the real issues, and move on. Over a year you've covered the full list, and the next time a major version ships you have a baseline to diff against. The categories don't change much year over year — the ordering does, and the new entries usually reflect the kind of attack that's becoming common enough to matter.

Key takeaways

  • Broken Access Control is still number one and still causes the most SaaS data leaks — scope every query by tenant ID.
  • Supply chain is the new entrant worth the most engineering time — lockfiles, SBOMs, and pinned versions are table stakes.
  • Insecure design is the category most teams ignore because it lives in requirements, not code. Threat model before you build.
  • Authentication failures rarely get fixed all at once. Rate limiting the password reset endpoint is the most commonly missed control.
  • Logging without alerting is a compliance exercise, not a security control.
  • Run the list as a quarterly audit, not a one-time read.
#owasp#security#saas#broken-access-control#injection#authentication
Working on something similar?

Let's build it together.

We ship production SaaS, marketplaces, and web apps. If you want an engineering partner — not a consultancy — let's talk.