OWASP Top 10:2025 for Next.js + Supabase Apps

OWASP Top 10:2025 for Next.js + Supabase apps comes down to ten architectural decisions, made once in the template and enforced through code organization, not ten lists of rules to remember. The 2025 edition based on 175,000+ analyzed CVEs reshuffled the rankings: Broken Access Control stayed #1, Security Misconfiguration jumped to #2, and Software Supply Chain Failures rose to #3 [1]. Server-Side Request Forgery folded into A01, and a new A10 "Mishandling of Exceptional Conditions" category covers the bugs where errors fail open and grant access by accident.

This pillar maps every OWASP Top 10:2025 category to the specific Next.js + Supabase failure pattern, the disclosed 2026 CVE or breach example that proves it matters, and the architectural defense that prevents the whole category instead of patching individual bugs. The supporting clusters cover specific surfaces in depth: the 3-layer injection defense for A05, the backend-only data access pattern for A01 and A04, the Server Actions + Zod guide for A06, and the 12-step hardening checklist for the broader deployment surface.

TL;DR:

• A01 Broken Access Control (still #1): RLS deny-all by default + authorization checks inside every Server Action. SSRF (formerly A10:2021) is now folded into A01. CVE-2026-44578 [4] proved how a single crafted WebSocket request can read cloud metadata.
• A02 Security Misconfiguration (up from #5 to #2): strict CSP via next.config.ts and proxy.ts, serverActions.allowedOrigins for proxy deploys, separation of NEXT_PUBLIC_ and server-only env vars.
• A03 Software Supply Chain Failures (up from #6 to #3): Shai-Hulud and Shai-Hulud 2.0 npm worms compromised 180+ packages in 2025 [6]. The defense: .npmrc with min-release-age=7 and save-exact=true.
• A05 Injection (down from #3 to #5 but still 38 CWEs): PostgREST auto-parameterization, Zod on every input, nonce-based CSP on dynamic routes. The full architectural treatment lives in the 3-layer defense pillar.
• A10 Mishandling of Exceptional Conditions (NEW for 2025): ActionResult<T> discriminated unions on every Server Action, error boundaries that fail closed, structured catches instead of thrown exceptions.

Table of contents

• What changed in OWASP Top 10:2025?
• A01: Broken Access Control
• A02: Security Misconfiguration
• A03: Software Supply Chain Failures
• A04: Cryptographic Failures
• A05: Injection
• A06: Insecure Design
• A07: Authentication Failures
• A08: Software and Data Integrity Failures
• A09: Security Logging and Alerting Failures
• A10: Mishandling of Exceptional Conditions
• The defense matrix at a glance

What changed in OWASP Top 10:2025?

Three changes matter for Next.js + Supabase apps specifically [1]:

SSRF folded into A01. What was A10:2021 (Server-Side Request Forgery) is now part of Broken Access Control in 2025. The reframing matches reality: SSRF is access control that broke at the URL-fetching boundary instead of the database boundary. CVE-2026-44578 (Next.js WebSocket upgrade SSRF, patched in 15.5.16 and 16.2.5) is the canonical 2026 example: a single crafted HTTP request lets an unauthenticated attacker make the Next.js process issue an internal HTTP GET to any host the server can reach, including AWS metadata endpoints that store IAM credentials [4][5].

Supply Chain rose from #6 to #3. The 2025 ranking promoted what was "Vulnerable and Outdated Components" to a broader "Software Supply Chain Failures" category and moved it three places up. Shai-Hulud (September 2025), Shai-Hulud 2.0 (November 2025), and the TanStack compromise (May 2026) compromised 180+ npm packages with self-propagating worm payloads [6]. Every Next.js project that ran npm install against a ^ version range during one of those windows risked pulling poisoned code.

A10 is new: Mishandling of Exceptional Conditions. 24 CWEs about errors that fail open: failing to handle an exception means the next line runs as if everything succeeded. In a Server Action, "the next line runs" can mean "the user is treated as authorized when the auth check threw." This category is what catches the bugs that don't appear in any other list.

The rest of the categories shifted around but the underlying patterns are the same as 2021. The architectural decisions that prevent them are also the same.

A01: Broken Access Control

The failure pattern in Next.js + Supabase. RLS misconfiguration is the canonical version: a table ships with RLS disabled, or with a policy that's too permissive, and the publicly available anon key can query data it shouldn't. CVE-2025-48757 (the Lovable / SupaPwn breach) exposed 170+ apps via missing RLS, including one app that leaked 13,000 users through a publicly queryable password reset token table [7]. SSRF via Server Actions or middleware is the second variant: input that controls a fetch() URL becomes a primitive to read internal resources [4]. The third is missing authorization inside Server Actions, where the framework authenticates the request but the action doesn't check whether the caller can do the requested operation.

The architectural defense. Three layers, applied together:

• Backend-only data access. Every database query runs server-side through createAdminClient() in a Server Action. The browser bundle never has credentials capable of querying business tables. RLS becomes a deny-all safety net instead of the primary defense. The full pattern is in the cluster 3.1 pillar.
• Authorization inside every Server Action. Next.js documentation states the rule explicitly: "Always verify authentication and authorization inside each Server Action, even if the form is only rendered on an authenticated page" [8]. The pattern is validate-authorize-query in fixed order: safeParse the input, getUser() from the session, only then call the admin client.
• RLS deny-all defaults. Enable RLS on every table with zero policies. The anon and authenticated roles get nothing; the service_role bypasses RLS so the admin client still works. A missing policy fails closed instead of open. The RLS patterns guide covers the cases where granular policies do belong.

The CVE-2026-44578 WebSocket SSRF is a framework patch (upgrade to 15.5.16 or 16.2.5), but the broader SSRF defense is the same input-validation discipline: any user-controlled URL or hostname gets validated against an allowlist before any fetch() runs.

A02: Security Misconfiguration

The failure pattern in Next.js + Supabase. No CSP header, or a CSP that's effectively unsafe-inline everywhere. Missing security headers (no HSTS, no X-Frame-Options, no Referrer-Policy). The service_role key prefixed NEXT_PUBLIC_ by accident, shipping full database write access in the browser bundle. Trigger functions with default PUBLIC execute privileges. Permissive CORS that lets any origin call your APIs. The May 2026 Vercel security release patched 13 advisories at once, several of which were configuration-class issues [4].

The architectural defense. Configure once at the platform layer; never trust per-route discipline.

• Security headers in next.config.ts. X-Frame-Options DENY, HSTS with preload, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy locking down camera/microphone/payment. Configure CSP with explicit script-src, frame-ancestors 'none', object-src 'none', upgrade-insecure-requests. The free Next.js security headers generator emits a complete header set.
• Nonce-based CSP for dynamic auth-gated routes. proxy.ts generates a per-request nonce and stamps it into the CSP header for /dashboard, /settings, /billing, and /admin. Modern browsers ignore 'unsafe-inline' when 'strict-dynamic' is present, so inline scripts can only execute if they carry the matching nonce. Marketing pages stay on the broader next.config.ts CSP because they're statically pre-rendered.
• serverActions.allowedOrigins for proxy deployments. Behind Cloudflare Tunnel or a custom reverse proxy, the Host header may not match the public origin, breaking the built-in CSRF check. Setting the allowlist from NEXT_PUBLIC_APP_URL keeps the protection active.
• Env separation discipline. NEXT_PUBLIC_ prefix only on values that are genuinely safe in the browser bundle: Supabase URL, anon key, Stripe publishable key, app URL. Everything else (service role keys, Stripe secret, webhook secrets, Resend API key, AI provider keys) stays server-only. The API keys leak post covers what happens when this discipline fails.

A03: Software Supply Chain Failures

The failure pattern in Next.js + Supabase. This is the category that moved most aggressively in 2025. The Shai-Hulud npm worm compromised an initial set of packages in September 2025 starting with @ctrl/tinycolor, then self-propagated across the ecosystem. Shai-Hulud 2.0 in November 2025 expanded scope to over 25,000 malicious GitHub repositories across approximately 350 unique users, and moved execution to the pre-install phase to widen impact across CI/CD pipelines [6]. The TanStack compromise in May 2026 (84 malicious versions across 42 @tanstack/* packages in a 6-minute window) followed the same playbook. Every Next.js project that ran npm install against a ^ version range during one of those windows risked pulling and executing arbitrary code.

The architectural defense. Two .npmrc settings that make npm refuse to install fresh malicious code:

min-release-age=7
save-exact=true

min-release-age=7 blocks installation of any package version published within the last 7 days. Malicious releases land and get yanked within that window in nearly every documented case, so your install never sees them. Requires npm 11.10 or later.

save-exact=true writes exact versions to package.json instead of carat ranges. Silent patch bumps to compromised versions stop happening; your lockfile becomes an honest record. Combined with npm ci (frozen-lockfile) in CI, the dependency tree you tested is the dependency tree that ships.

Additional defenses:

• GitHub Dependabot or Renovate with auto-merge for patch only. Minor and major updates get human review. Patches usually don't.
• TruffleHog or git-secrets in CI as a pre-commit hook AND a CI gate to catch credentials before they enter git history.
• Runtime billing alerts on every paid third-party (Stripe, Supabase, Resend, OpenAI, Anthropic). A billing anomaly is often the first signal that a compromised key shipped.

The supply chain defense is one of the few areas where doing nothing actively hurts. Every other category, default behavior at least fails closed; here, default behavior is "trust whatever npm gives you at install time."

A04: Cryptographic Failures

The failure pattern in Next.js + Supabase. The headline failure: hardcoded secrets, JWT signing keys in source, Supabase service_role keys committed to git. The subtler failures: trusting getSession() for authorization instead of validating the JWT signature, password hashing rolled by hand instead of through Supabase Auth, sensitive data stored in unencrypted columns. The NEXT_PUBLIC_SUPABASE_SERVICE_ROLE antipattern shows up in AI-generated code regularly enough that it's a category, not an edge case.

The architectural defense.

• Let Supabase do password hashing. Supabase Auth uses bcrypt with sensible cost parameters. Don't roll your own. Don't use crypto.subtle to hand-implement anything.
• Validate JWTs locally with getClaims(), not getSession(). getSession() reads from cookies without re-validating the signature. getClaims() verifies the JWT signature against Supabase's cached asymmetric public key set on every call. The same security guarantee as getUser() (which hits the network) without the round-trip cost.
• Asymmetric JWT signing keys. Default for new Supabase projects since 2025. Existing projects enable them in the Supabase dashboard. The local validation pattern depends on the public key set being available.
• Env separation, enforced. Two grep checks before every deploy: grep -r "NEXT_PUBLIC_.*SERVICE_ROLE" returns zero results, and grep -r "service_role\|STRIPE_SECRET\|RESEND_API" returns nothing in files that don't have 'use server' or import 'server-only'.
• import 'server-only' on the admin client. Build-time enforcement that the service_role module can never be imported into a Client Component bundle. Cheap and catches the mistake at the earliest possible point.

The architectural commitment that closes most of this category: the backend-only data access pattern means the service_role key is structurally unable to ship in the browser, regardless of any individual developer's discipline.

A05: Injection

The failure pattern in Next.js + Supabase. OWASP A05:2025 covers 38 CWEs spanning SQL injection, command injection, XSS, OS command injection, and LDAP injection, with 100% of tested applications exhibiting some form of injection vulnerability during testing [2]. For Next.js + Supabase specifically: SQL injection through custom RPC functions that use EXECUTE with string concatenation, XSS through unsanitized Markdown rendering or React's raw-HTML insertion prop, CSRF through Server Action POSTs that ride along on session cookies, and a fourth modern category: prompt injection through service_role-scoped AI agents (the Supabase MCP exposure class).

The architectural defense. This category has its own pillar; the cluster 2.5 3-layer injection defense post walks the full architectural treatment with code for each defense layer. The summary:

• CSRF: Next.js Server Actions check Origin vs Host on every POST. CVE-2026-27978 patched the null-origin bypass in 16.1.7. Set experimental.serverActions.allowedOrigins for non-Vercel proxy deploys.
• XSS: strict CSP, nonce-based on dynamic routes. React's automatic escaping covers normal interpolation. Avoid raw-HTML rendering of user-controlled content; sanitize with DOMPurify on the server when unavoidable.
• SQL injection: the Supabase JavaScript client talks to PostgREST, which parameterizes every query automatically. RPC functions use EXECUTE format(...) USING with placeholders, never string concatenation. Direct postgres-js connections use tagged template literals, never sql.unsafe.
• Prompt injection: never give an AI agent the service_role key. Use a scoped role with explicit grants on a narrow schema. Validate AI-generated SQL or tool calls against an allowlist before executing.

If only one cluster pillar gets read for the injection category, it's the 3-layer defense post. This summary is the index.

A06: Insecure Design

The failure pattern in Next.js + Supabase. This is the meta-category: design-level mistakes that no amount of bug-fixing patches over. The classic Next.js + Supabase versions: a Server Action that reads userId from form input and uses it as a query predicate (the user can act on someone else's data); a webhook handler with no idempotency that double-fulfills on retry; a password reset flow that issues tokens without rate limits; a Stripe checkout flow where the success URL is the source of truth instead of the webhook. None of these are coding bugs. They're architectural decisions that ship broken.

The architectural defense.

• Validate, identify, then act. Every Server Action runs safeParse on input, getUser() for identity (using session cookies, never trusting payload IDs), and only then performs the privileged operation. The Server Actions + Zod guide walks the pattern.
• Idempotent webhook handlers. Use the provider's event ID (evt_... for Stripe) as a primary key on a deduplication table. The retry simply hits the unique constraint and returns 200 without doing the business work twice. The Stripe payments guide covers the full pattern including transactional consistency for higher-stakes flows.
• Rate limits on every sensitive action. Login, signup, password reset, contact forms, paid-API-call actions. Per-IP and per-user. The rate-limiting guide covers in-memory and Redis patterns.
• Server-side truth, never client-redirect-as-fulfillment. The user landing on /purchase/success does not mean they paid. Only the webhook confirms a real payment. The redirect is a courtesy, not authorization.

Insecure design is the category where the pre-launch security checklist earns its place: each of the 7 non-negotiables is an architectural commitment to a specific design defense.

A07: Authentication Failures

The failure pattern in Next.js + Supabase. Trusting getSession() for authorization. Storing auth tokens in localStorage instead of httpOnly cookies. No MFA on admin accounts. Password reset tokens that don't expire. Magic links that don't rate-limit by IP. Account enumeration via login form responses ("user not found" vs "wrong password"). Session fixation through unscoped cookies.

The architectural defense.

• getClaims() for local JWT validation. Validates the signature against the cached asymmetric public key set on every call. Cryptographic guarantee that the JWT is genuine, no network round trip. The proxy.ts post walks the full session-handling pattern.
• @supabase/ssr for cookie management. Cookies are set with httpOnly, secure, and SameSite=Lax defaults. Never roll cookie handling by hand.
• Supabase Auth for password reset and magic link. It rate-limits by default, doesn't leak user existence in responses, and issues tokens with built-in expiry. Don't reinvent.
• MFA via TOTP on admin accounts. Supabase Auth supports passkeys and TOTP. Enable on the superAdminEmails set at minimum.
• Authorization checks inside every protected Server Action. Middleware authenticates the request and routes; the action checks whether the authenticated user can do this specific operation. Two layers, both required.

The full Supabase Auth in App Router guide covers OAuth, magic links, and the session-validation patterns.

A08: Software and Data Integrity Failures

The failure pattern in Next.js + Supabase. Webhook handlers that skip signature verification. File uploads without size or type validation. Auto-update mechanisms that don't verify the source. Trusted CI pipelines that pull dependencies without lockfile verification (the supply-chain category overlaps here too).

The architectural defense.

• Always verify webhook signatures. Stripe, Resend, GitHub, Clerk, every webhook provider signs its payloads. stripe.webhooks.constructEvent with the raw body, before any business logic runs. The Stripe payments guide covers the full pattern including the read-body-as-text gotcha.
• Signed URLs for Supabase Storage. Files in private buckets get accessed through time-limited signed URLs generated server-side. Never let the browser construct storage URLs. The secure file uploads guide covers RLS on buckets, size/type validation on uploads, and signed URL generation.
• npm ci in CI, not npm install. Frozen lockfile means the install matches the lockfile exactly. Combined with the supply-chain defenses (A03), the integrity of the dependency graph stays intact.
• No dynamic code execution on user input. Treat any code-execution pathway as a deserialization risk. Avoid Function-constructor invocations, dynamic require(), and runtime template-string evaluation on user-controlled values. Zod-validated input flowing into typed branches; never strings flowing into runtime evaluation.

A09: Security Logging and Alerting Failures

The failure pattern in Next.js + Supabase. Production errors get masked by Next.js (it strips Server Component error messages by default and replaces them with opaque digests), and without instrumentation the real errors only exist in server logs nobody reads [3]. No failed-login logging. No alerts on Stripe webhook signature failures. No tracking of admin actions. The 2025 rename emphasized the "alerting" half: logging events into a system nobody monitors is roughly equivalent to no logging at all.

The architectural defense.

• Sentry's onRequestError hook. Captures the raw Server Component error before Next.js redacts it, correlates with the digest the client sees, and surfaces it in a searchable dashboard. The error handling guide walks the full integration.
• error.tsx and global-error.tsx for client-side and root-layout failures. Plus Sentry.captureException(error) inside the global-error component for catastrophic failures.
• Structured Server Action returns via ActionResult<T> discriminated unions. Unexpected errors land in a catch block, get logged server-side with full detail, return a generic message to the client. The bug is preserved without leaking to users.
• Audit logging on admin actions. Every admin-only Server Action writes an audit row with actor, target, action, timestamp, and IP. Trivial to query when something goes sideways.
• Billing-anomaly alerts. Stripe, Supabase, OpenAI, every paid service offers spend alerts. Wire them up; a 10x spike in a quiet hour is often the first signal that a key is compromised.

The 2025 wording change (logging-and-alerting, not logging-and-monitoring) matters. Logs without alerts are forensic-only. Alerts make logs operational.

A10: Mishandling of Exceptional Conditions

The failure pattern in Next.js + Supabase. New category for 2025, 24 CWEs. The pattern: an exception fires, the catch block swallows it or does nothing meaningful, and the next line of code runs as if the operation succeeded. In a Server Action, "the next line runs" can mean "the user is treated as authorized when the auth check threw," or "the database operation continues with a partial state." Failing open instead of failing closed is the OWASP definition.

The specific Next.js + Supabase shapes:

• A Server Action that does try { user = await getUser() } catch { user = null } and then proceeds as an unauthenticated request to a publicly accessible code path.
• An error.tsx that catches a rendering failure but the surrounding layout assumed the render succeeded.
• A webhook handler that catches signature verification failures and continues processing anyway because "the retry will sort it out."
• An async cleanup that throws but is fire-and-forget, leaving inconsistent state.

The architectural defense.

• Fail closed on every catch block in security-sensitive code. If getUser() throws, the action returns { ok: false, error: 'Authentication error' }, never falls through to "no user equals public access." If safeParse fails, the action returns the structured error. There is no path where the operation continues with degraded inputs.
• ActionResult<T> discriminated unions instead of thrown exceptions across Server Action boundaries. The caller gets { ok: true, data } or { ok: false, error }. Type narrowing prevents the "did we succeed or fail" ambiguity.
• Never catch redirect(). Next.js's redirect() throws a NEXT_REDIRECT signal to unwind the call stack. Catching it converts a navigation into a silent error.
• Sentry on every unexpected catch. Even when the action returns a generic error, the original exception goes to Sentry with full stack trace so the bug is visible to the operator, not just the user.
• Test the error paths. The testing guide covers Vitest tests on Server Actions specifically because the error paths are the ones a manual smoke test never exercises.

A10 is the category that turns latent bugs into security incidents. Every other defense in this post assumes that when a check fails, the code stops. A10 is what happens when that assumption is wrong.

The defense matrix at a glance

OWASP 2025	Next.js + Supabase failure pattern	2026 anchor	Architectural defense	Deeper guide
A01 Broken Access	RLS missing, SSRF via Server Actions, no authz in actions	Lovable breach, CVE-2026-44578	Backend-only data access + RLS deny-all + validate-authorize-query	3.1 pillar, 1.2 RLS
A02 Misconfiguration	No CSP, NEXT_PUBLIC on service_role, permissive CORS	May 2026 Vercel release (13 CVEs)	Headers in next.config.ts + nonce CSP via proxy.ts + import 'server-only'	2.1 hardening
A03 Supply Chain	Shai-Hulud, TanStack, dependency confusion	Shai-Hulud 2.0 (180+ packages)	.npmrc with min-release-age=7 + save-exact + npm ci + Dependabot	(changelog v1.8.1 covers the .npmrc shipping)
A04 Cryptographic	Service_role in client bundle, getSession() trusted, custom password hashing	Google $82K API key incident	Backend-only access + getClaims() + Supabase Auth for hashing + asymmetric JWT keys	3.2 API keys
A05 Injection	SQL via RPC EXECUTE, XSS via raw-HTML, CSRF via Server Action POST	CVE-2026-23870, CVE-2026-27978, CVE-2026-44581	PostgREST auto-parameterization + nonce CSP + Origin-vs-Host	2.5 pillar
A06 Insecure Design	userID from payload, webhook with no idempotency, redirect-as-fulfillment	Lovable misuse patterns	Validate-authorize-query + event-ID idempotency + server-side truth	2.2 Zod, 4.1 Stripe
A07 Auth Failures	getSession() trusted, no MFA, magic links unrate-limited	Various Supabase tokens leaked	getClaims() + @supabase/ssr cookies + Supabase Auth defaults + TOTP for admin	1.1 Supabase Auth
A08 Integrity	Skipped webhook signatures, no upload validation, npm install unfrozen	Forged webhook scenarios	constructEvent + signed URLs for storage + npm ci in CI	Stripe, uploads
A09 Logging	error.tsx swallows, no Sentry, no admin audit	Production debugging blind	Sentry onRequestError + ActionResult catches + admin audit table + billing alerts	5.1 error handling
A10 Mishandling (NEW)	Catch blocks fail open, redirect() caught, fire-and-forget cleanup	Latent until exploited	Fail-closed catches + ActionResult unions + test error paths	5.2 testing

The pattern that emerges across the matrix: the same architectural decisions cover multiple OWASP categories. Backend-only data access addresses A01, A04, and A06 simultaneously. The validate-authorize-query Server Action pattern addresses A01, A05, A06, and A10. Nonce-based CSP plus security headers addresses A02 and A05 together. This isn't a coincidence; it's why the categories repeat across the OWASP analysis across years. A well-chosen architectural commitment buys defense across several vulnerability classes at once.

What this means for your Next.js + Supabase architecture

The OWASP Top 10:2025 is a useful lens, not a checklist of things to bolt on after launch. The categories repeat from year to year because the underlying mistakes repeat. The defenses that hold up across editions are architectural, not patch-based: choose backend-only data access and you get A01, A04, and A06 for free; ship .npmrc with version quarantine and A03 stops being a category you have to think about; structure Server Actions as validate-authorize-query and A05, A06, A10 collapse into one habit.

The 2025 changes don't invalidate the 2021 patterns. SSRF moving into A01, Supply Chain moving to #3, and the new A10 just reflect what 2024-2025 breaches actually looked like. Every one of those breach classes has a known architectural fix; most templates don't ship the fix by default. This is what we built SecureStartKit around: a Next.js + Supabase + Stripe baseline where every OWASP category has a defense already wired in, documented in the 12-step hardening checklist, validated by the pre-launch security checklist tool, and explained in the cluster pillars referenced throughout this matrix. The site you're reading is the demo of the architecture; the pricing page is the conversion if the architecture matches what you need.