Security Testing for Modern SaaS Stacks (Next.js, Supabase, Stripe)

The modern stack changes where bugs live

Frameworks like Next.js and platforms like Supabase remove a lot of classic vulnerability classes for you, but they shift risk to configuration and authorization. The breaches we see on these stacks rarely come from the framework being insecure; they come from a row-level-security policy that was never enabled, or an API route that trusts a client-supplied user ID.

Next.js: server actions and API routes

• Authorize on the server, every time. Server actions and route handlers are public HTTP endpoints. Don't rely on the UI hiding a button, verify the session and the user's permission inside the handler.
• Watch what crosses the client boundary. Don't leak secrets or privileged data into client components or props.
• Validate inputs to server actions as untrusted, even though they look like function calls.

Supabase: row-level security is the whole game

Supabase exposes your Postgres database to the client through PostgREST. If row-level security (RLS) isn't enabled and correctly written on every table, any user can read or write data they shouldn't, straight from the browser. The most common, most damaging Supabase bug is a table with RLS disabled or a policy that checks the wrong column. Test every table as an authenticated low-privilege user and confirm you cannot reach other tenants' rows.

Stripe & webhooks

• Verify webhook signatures. An unverified /webhook endpoint lets an attacker forge "payment succeeded" events and unlock paid features for free.
• Make webhook handling idempotent so replays don't double-credit accounts.
• Never trust client-supplied amounts or price IDs, validate against your server-side catalog.

Secrets and the build

Serverless and edge deployments make it easy to leak secrets through the wrong environment-variable prefix (e.g. anything exposed to the client bundle), committed .env files, or verbose error pages. Keep server secrets server-only, and scan your deployed bundle for anything that shouldn't be there.

Testing it the easy way

You could test all of this by hand for every release, or point a continuous hunter at the running app and let it probe these exact failure modes for you. Kyro maps your routes, logs in as a low-privilege user, and actively tries to cross tenant boundaries, forge events, and reach data it shouldn't, then reports only what it can reproduce. start a free scan to run it against your stack.