Missing auth on API routes
API routes that handle user data without checking authentication. Anyone with the URL can call them — no login required.
What this rule detects
VC003 flags Next.js route handlers, Express routes, and similar HTTP handlers that perform sensitive operations (database reads/writes, payment, file access) without an auth check at the top. The rule looks for the absence of recognized auth patterns: `await auth()`, `getServerSession()`, `requireUser()`, `currentUser()`, etc.
Vulnerable vs. safe code
// Anyone who finds this URL can read every user.
export async function GET() {
const users = await db.user.findMany();
return Response.json(users);
}import { auth } from "@clerk/nextjs/server";
export async function GET() {
const { userId } = await auth();
if (!userId) {
return Response.json({ error: "Unauthorized" }, { status: 401 });
}
// Only return data the requesting user is allowed to see.
const users = await db.user.findMany({
where: { orgId: await getOrgId(userId) },
});
return Response.json(users);
}Authentication ("who are you?") and authorization ("are you allowed to do this?") are different. VC003 catches missing authentication. VC010 catches missing authorization once you're past the auth check.
About A01:2021 — Broken Access Control
Access-control bugs let users do things they shouldn't — view another user's data, modify records they don't own, or hit admin-only endpoints without admin rights. This class moved to #1 in the 2021 OWASP Top 10 because 94% of audited apps had at least one access-control flaw.
Impact: An attacker who finds an access-control bug typically gets a much bigger blast radius than other vulnerability classes. Examples we've seen in AI-generated code: a /api/user/[id] route that returns any user's profile, a delete endpoint that doesn't check ownership, an admin dashboard with no role check.
How to fix it: Check authentication AND authorization on every server-side route. Never rely on the client to enforce permissions. Default to deny. For per-resource checks, fetch the resource and verify the requesting user owns it before returning or modifying it.
Common patterns in this category:
- Missing auth check on API routes (the resource is returned to anyone with the URL)
- Authorization based on a parameter the client controls (e.g. trusting `?userId=` in the URL)
- Direct object references where the resource ID isn't validated against the requesting user
- Public access to administrative or internal endpoints
- Privilege escalation via mass assignment (user POSTs `{role: 'admin'}` and the ORM accepts it)
Compliance coverage
Findings from this rule map to the following framework controls:
See the full compliance coverage page for how XploitScan maps every rule to SOC 2, ISO 27001, and OWASP Top 10 controls.
Scan your code for VC003 and 157 other rules
Free, no signup. Drag and drop a zip or run npx xploitscan scan .