No auth on your AI-generated API endpoints: anyone can call your backend

Vibe coding (any tool) Involved 1-3 hours security critical Last verified Jul 17, 2026

The fix Assume every route is public until proven otherwise: hit each endpoint with curl, no cookies, no headers, and with another user's IDs. Anything that returns data is a live exposure. Then enforce auth server-side in shared middleware, deny-by-default, and add object-level checks so an authenticated user can't fetch /api/users/124 when they are user 123.

Symptoms

API routes that return or mutate sensitive data answer plain unauthenticated curl requests
Admin pages and internal dashboards are reachable by anyone with the URL
Changing an ID in a request (/api/users/123 to /api/users/124) returns someone else's data
A scanner or pentest flags public endpoints; Escape.tech found 2,000+ vulnerabilities of exactly this class, accessible directly through public endpoints, across 5,600+ vibe-coded apps

Why it happens

AI scaffolds working endpoints, not protected ones

Auth only appears in generated code if you explicitly ask for it. The default output is a route that works for everyone, including people you have never met.

UI-only enforcement

The frontend hides buttons and links while the endpoint itself stays public. Client-side-only enforcement was one of the flaws in the Base44 platform incident, where two auth endpoints (register and verify-otp) required nothing but a publicly visible app_id, letting anyone mint a verified account on any private app. Wiz reported it and Wix fixed it within 24 hours.

Missing object-level authorization

Even when authentication exists, the ownership check is often missing, so any logged-in user can walk resource IDs and read other users' data. This is the BOLA/IDOR class of bug.

Logic inversions

One Lovable app shipped an inverted auth check that blocked authenticated users and admitted unauthenticated ones, exposing data on 18,000+ people. Generated auth logic needs verification, not trust.

How to fix it

Inventory every route (assume exposure until you have checked each one)Enumerate every route your app exposes, via your framework's route listing or by grepping the api/ directory, and classify each as public or authenticated. If you cannot justify 'public', it is authenticated.
Enforce auth server-side, deny-by-defaultPut the check in shared middleware so no handler can forget it, and never rely on the frontend hiding a link. Every protected handler verifies the session or JWT before doing anything else.
Add object-level authorizationAfter authenticating, verify the requesting user actually owns the resource ID in the request. Authentication alone does not stop a logged-in user from fetching someone else's records; this is the BOLA/IDOR check.
Test like an attackerHit each endpoint with curl: no cookies, no headers, then again with another user's IDs. Anything that returns data is a finding, and this takes minutes per route.
Lock down internal toolsPut admin dashboards and internal tools behind real SSO or network restrictions. Unlinked URLs are discoverable via fingerprinting and crawlers, so obscurity is not a control.

How to prevent it

Ask for auth explicitly in every prompt that creates an endpoint, then verify it landed server-side.
Keep a route inventory and re-audit it after every AI-generated change.
Bake the curl-with-no-cookies test into your pre-launch checklist.
Use shared auth middleware so new routes inherit protection by default instead of opting in.

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

SupabaseFree tier incl. RLS

If your AI-built app uses Supabase, Row Level Security is the actual fix for exposed data, and it is free. The dashboard's Security Advisor lists every table you left open.

Try Supabase →

Clerkfree tier

Drop-in authentication that handles sessions, tokens, and protected routes properly, so you stop shipping the hand-rolled auth an AI guessed at. Generous free tier for a real app.

Try Clerk →

Frequently asked questions

Why doesn't AI-generated code include authentication?

AI coding tools scaffold endpoints that work, not endpoints that are protected: authentication typically only appears when you explicitly ask for it. Even then, it is often enforced only in the UI by hiding buttons and links while the endpoint itself answers any request. Treat every AI-generated route as public until you have verified server-side auth on it.

What is an IDOR or BOLA vulnerability?

IDOR (insecure direct object reference), also called BOLA (broken object level authorization), is when an API authenticates a user but never checks whether they own the resource they requested. Changing /api/users/123 to /api/users/124 and getting someone else's data back is the classic test. The fix is an ownership check after authentication on every resource access.

Is hiding the admin link enough to protect an admin page?

No. Hiding a link is client-side decoration; the endpoint behind it still answers anyone who finds the URL, and unlinked URLs are discoverable through fingerprinting and crawlers. Wiz found unauthenticated internal knowledge bases, chatbots, and admin dashboards deployed publicly this way. Put internal tools behind real SSO or network restrictions.

How do I test whether my API endpoints are exposed?

Test like an attacker: call each endpoint with curl using no cookies or auth headers, then again as one authenticated user requesting another user's resource IDs. Any request that returns data is a live finding. Escape.tech found 2,000+ vulnerabilities accessible directly through public endpoints across 5,600+ vibe-coded apps using essentially this approach.

Sources

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.