Authentication Traps Under the Hood of AI-Generated Web Apps

When you ask an AI coding assistant to add sign-in to a web application, the visual result arrives in minutes: a polished login form, a redirect to /dashboard, and a sign-out button in the header.

Underneath that UI, however, AI assistants optimize for making the screen work on the first run. Unless prompted with strict security constraints, they frequently take shortcuts that leave user data exposed.

Here are four authentication and authorization traps we look for first when reviewing a codebase.

Trap 1: Checking cookie presence instead of verifying the session

Routing layers often check whether a session cookie exists to decide whether to redirect a visitor to /login. That check is fine as a fast UI redirect, provided the data layer still verifies the session token on the server.

The failure happens when route handlers or server components assume that reaching the page means the request is authenticated:

1// Broken check: only tests whether a cookie string is present2const token = cookieStore.get("session_token")?.value;3if (!token) {4  redirect("/login");5}6// Danger: never verified signature, expiration, or revocation

A routing redirect is a navigation convenience, not an access control boundary. Every data read and mutation must verify the session signature and expiration server-side.

Trap 2: Trusting userId or organizationId from the request body

When generating a form or API call, AI tools often pass userId or orgId as a hidden field or JSON property from the client component to the server handler.

1// Broken pattern: trusts the caller to state who they are2export async function getBillingHistory(requestedUserId: string) {3  return db.invoice.findMany({4    where: { userId: requestedUserId },5  });6}

An attacker does not need to break your cryptography if they can pass another customer's UUID into getBillingHistory. Derive the actor's identity exclusively from the verified server session, and verify membership before querying organization data.

Trap 3: Unsigned or non-idempotent auth and billing webhooks

Modern apps rely on webhooks from authentication providers (such as Clerk, Auth0, or Supabase) and payment processors (such as Stripe or Paddle) to provision accounts and upgrade plans.

Two defects are common in generated webhook handlers:

1. Skipping signature verification (or reading the parsed JSON body instead of the raw request bytes before calling constructEvent), allowing anyone who discovers the endpoint URL to forge a checkout.session.completed event.
2. Missing event-ID deduplication, causing duplicate account provisioning or double credits when the provider retries a slow 200 response.

1// Always verify the raw payload signature before parsing event data2const rawBody = await request.text();3const signature = request.headers.get("stripe-signature");4if (!signature) {5  return new Response("Missing signature", { status: 400 });6}7const event = stripe.webhooks.constructEvent(rawBody, signature, webhookSecret);

Trap 4: Leaking privileged keys into the client bundle

In Next.js and similar frameworks, any environment variable prefixed with NEXT_PUBLIC_ is inlined into the browser JavaScript bundle at build time.

When an AI assistant hits a missing environment variable error in a client component, a common automated "fix" is to rename SUPABASE_SERVICE_ROLE_KEY or an internal API key to NEXT_PUBLIC_... so the error disappears. That single rename hands full database bypass privileges to anyone who opens browser DevTools.

·// lib/db-admin.ts — isolate privileged clients to the server+import "server-only";·import { createClient } from "@supabase/supabase-js";··export const adminDb = createClient(·  process.env.NEXT_PUBLIC_SUPABASE_URL!,−  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!,+  process.env.SUPABASE_SERVICE_ROLE_KEY!,·);

How to verify your own repository

1. Search the codebase for every NEXT_PUBLIC_ variable and confirm none hold service-role keys, webhook secrets, or private API tokens.
2. List every Server Action and POST/PUT/DELETE route handler, and trace where the acting userId comes from.
3. Confirm every multi-tenant query filters by both the resource ID and the verified tenant or owner ID.

If you want a second pair of engineering eyes on a live or launching application, see how a Codeneath Review works or get in touch.