LR-05

Your Admin Panel Has No Lock. Just a Sign That Says 'Admin Only.'

Your app has an admin panel. It's hidden from the navigation — regular users don't see a link to it. The admin dashboard shows user management, billing overrides, content moderation, system settings.

But "hidden from the navigation" is not "protected from access." If someone types /admin in the URL bar, what happens? If the answer is "they see the admin panel" — even for a second before a redirect — your admin is protected by UI, not by your server.

In AI-generated apps, this is one of the most common privilege escalation patterns. The AI builds a polished admin interface and adds a client-side role check that hides the link. But the API endpoints that serve admin data, the routes that render admin pages, and the actions that modify user accounts have no server-side authentication or authorization.

A security researcher testing a vibe-coded app demonstrated this directly: he issued a DELETE request using the founder's user ID, received a 204 response, and left himself as the sole user with the ADMIN role — completely removing the founder's record from the database. The admin panel had no server-side protection.

Who This Is For

Founders whose app has any admin, dashboard, or internal management interface
Developers who added role-based access control through AI tools and aren't sure if it's enforced on the server
Teams who store user roles in a database table that users might be able to modify
Anyone who has debug routes, seed endpoints, or internal tools that were meant for development only

If your admin panel is "protected" by hiding the navigation link or by a client-side if (user.role === 'admin') check, it is not protected.

What Founders Experience

The admin panel "works." Admin users see admin features. Regular users don't see the link. It looks correct in every demo and test.
Nobody tests the adversarial path. The AI generated the admin for authorized users. Nobody tries accessing it as a regular user. Nobody tries calling admin API endpoints directly.
A curious user finds it. Someone guesses /admin, /dashboard/admin, or /api/admin/users. Or they look at the JavaScript bundle and see admin route definitions. Or they inspect network requests and find admin API endpoints.
The damage is immediate and severe. Unlike a data exposure that may go unnoticed, admin access lets someone actively modify your system — delete users, change roles, export data, override billing, or shut down features.
The founder discovers it last. In one documented case, a researcher deleted the founder's account and promoted himself to admin. The founder had no idea until the researcher disclosed it.

What's Actually Happening

AI tools generate admin interfaces that look complete but lack server-side enforcement. The protection exists only in the UI layer — which anyone can bypass.

Four patterns create this vulnerability:

1. Client-Side Role Check, No Server Enforcement

The most common pattern. The AI generates code like:

// In a React component
if (user.role !== 'admin') {
  return <Redirect to="/" />;
}
return <AdminDashboard />;

The admin UI is hidden from non-admin users. But the API endpoints that serve admin data — /api/admin/users, /api/admin/settings, /api/admin/billing — have no role check at all. Anyone who calls these endpoints directly gets full admin data.

2. Role Stored in a User-Writable Table

The AI stores the user's role in the profiles table — the same table the user can update through the Supabase API. Without a WITH CHECK constraint that prevents modifying the role column, any authenticated user can set role = 'admin' on their own row.

This is different from a missing RLS problem. RLS may be enabled, and the user may be correctly restricted to their own row. But if they can update any column on their own row — including role — the entire RBAC system is bypassed.

3. Unprotected Debug and Seed Routes

During development, AI tools generate utility routes: /api/seed, /api/debug, /api/test, /api/reset. These routes create test data, reset states, or expose internal information. They're meant to be temporary. They make it to production.

One audit found that 33% of AI-generated apps had debug mode enabled in production. These routes often have no authentication at all — they were designed for local development where auth wasn't needed.

4. Hardcoded Admin Credentials

AI tools sometimes generate admin authentication with hardcoded credentials — admin@admin.com / password123, or a password stored as a plain string in the source code. In Lovable-generated apps, researchers found client-side hardcoded passwords visible in the JavaScript source, with localStorage-based auth bypass.

What This Puts at Risk

Full system control. Admin access typically means: user management (create, delete, modify), billing overrides (refunds, plan changes), content moderation (publish, unpublish, delete), system configuration (feature flags, API keys, integrations). An unauthorized admin has the same power as the founder.

Data exfiltration. Admin panels often display aggregate data, user lists, transaction histories, and analytics. An attacker with admin access can export your entire user base, payment history, and business metrics.

Destructive actions. Admin panels let you delete users, reset data, and modify system state. The researcher who deleted the founder's account demonstrated what an attacker — or a disgruntled user — could do with unprotected admin access.

Audit trail gap. Most AI-generated admin panels have no audit logging. When someone accesses admin functions without authorization, there's no record of what they did. You can't investigate what you can't see.

How Trust Score Detects It

Trust Score checks four patterns that catch admin access failures:

ADM-01: Admin endpoints have server-side auth. Scans API routes that serve admin functionality and verifies that they include server-side authentication and authorization checks — not just client-side role conditionals.

ADM-02: Admin routes not accessible without auth. Checks whether admin page routes return content to unauthenticated requests. Even a momentary flash of admin content before a client-side redirect indicates missing server-side protection.

ADM-08: No unprotected debug/admin routes. Scans for common development routes (/api/seed, /api/debug, /api/test, /api/reset) that may have been left in the production build without authentication.

ADM-11: No hardcoded admin credentials. Checks for hardcoded passwords, default admin credentials, and plaintext authentication patterns in the codebase.

Real Incidents

Researcher deleted founder, promoted himself to admin. A security researcher testing a vibe-coded app found zero server-side auth on admin endpoints. He issued a DELETE request using the founder's user ID, received a 204 response, and left himself as the sole admin. "I issued a DELETE request using HIS ID... leaving me as the sole user with the ADMIN role and completely removing the founder's record from the database."

Claude-generated admin dashboard with zero auth. A developer generated an admin dashboard with Claude. It was deployed to production with zero authentication — publicly accessible to anyone with the URL. "So, here's a funny story. And by 'funny,' I mean 'I want to crawl into a hole and die of embarrassment.'"

45% of AI-generated apps had unauth API endpoints (PreBreach). An analysis of 40+ AI-generated apps found that 45% had unauthenticated API endpoints, 33% were running debug mode in production, and 87% had at least one High or Critical security finding.

Wiz research — internal AI-built apps publicly accessible. Wiz found that enterprise organizations had internal apps built with AI tools that were publicly accessible with zero login. The apps were meant for internal use but had no authentication layer.

Lovable — hardcoded passwords in client JS. Researchers found Lovable-generated apps with client-side hardcoded passwords and localStorage-based auth bypass. The password was visible in the JavaScript source to anyone who viewed page source.

Detection: How to Check Your Own App

Check 1: Can you access admin routes without logging in?

Open an incognito browser window (no session) and navigate to your admin routes:

# Test common admin paths
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/admin
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/dashboard/admin
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/admin/users

Interpretation:

200 = publicly accessible — admin content served to anyone
401 / 403 = auth enforced at this endpoint
302 / 307 to login = likely protected at route layer, but still verify the underlying API endpoints separately
404 = route not present (not a risk, but check other common paths)

Check 2: Are debug/seed routes still in production?

# Check for common development routes
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/seed
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/debug
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/test
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/api/reset

Interpretation: Any response other than 404 means the route exists in production. If it returns 200, it's likely functional and unprotected.

Check 3: Can a regular user call admin API endpoints?

curl 'https://your-app.com/api/admin/users' \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"

Interpretation: If admin data is returned, the endpoint has no role check. Authentication exists (you need a token), but authorization does not (any token works).

Related Launch Risks

Your Database Is Public. You Just Don't Know It Yet. — Missing RLS and missing admin auth often appear together. If the database has no access control, the admin panel is just the most obvious entry point.
Anyone Can Upgrade to Pro for Free. — If the user role is stored in a writable table, the same vulnerability that enables billing bypass also enables admin self-promotion.
One Exposed Key Gives Strangers Full Access to Your Database. — Hardcoded credentials and leaked keys compound admin access vulnerabilities.
Your Login Check Is Lying. — Client-side auth checks that look correct but provide no server-side enforcement.

FAQ

Our admin panel is behind a login. Isn't that enough?

Only if the login is enforced on the server for every admin route and every admin API endpoint. A client-side redirect that sends non-admin users back to the homepage is not protection — the API endpoints behind that redirect may still serve data to anyone who calls them directly.

How would a regular user know about admin routes?

Admin routes are often visible in the JavaScript bundle, in network request patterns, or guessable from common conventions (/admin, /dashboard/admin, /api/admin/*). In AI-generated apps, route definitions are frequently included in the client-side code.

We use Supabase for auth. Doesn't that protect our admin?

Supabase handles authentication — confirming who the user is. Authorization — confirming what the user is allowed to do — is your application's responsibility. Supabase does not automatically prevent a regular user from accessing admin API endpoints. Your route handlers must check the user's role on every request.

What about Next.js middleware for admin protection?

Middleware can add a layer of protection, but it has limitations. CVE-2025-29927 demonstrated that Next.js middleware could be bypassed entirely by adding a specific HTTP header. Middleware is a useful defense-in-depth measure, but admin API routes should also verify authorization independently.

Our admin panel doesn't do anything dangerous. Does it still matter?

If the admin panel shows user data, analytics, or system information, unauthorized access is a data exposure. If it has any write functionality — even something as simple as deleting a comment — it's a privilege escalation. The question isn't whether the admin panel is "dangerous." The question is whether unauthorized access to it would be acceptable.