🛡️ API Audit — Checking API Route Security...

Audit Next.js API routes for authentication, authorization, validation, and common vulnerabilities.

Activation

When this skill activates, output:

🛡️ API Audit — Checking API Route Security...

Then execute the protocol below.

Context Guard

Protocol

Step 1: Discover API Routes

Find all API route files in the project:

1. App Router (Next.js 13+):

   find . -path "*/app/api/*/route.ts" -o -path "*/app/api/*/route.js"
   

   Each file exports named functions:

   GET

   ,

   POST

   ,

   PUT

   ,

   PATCH

   ,

   DELETE

   .

2. Pages Router (legacy):

   find . -path "*/pages/api/*.ts" -o -path "*/pages/api/*.js"
   

   Each file exports a default handler.

3. Middleware:

   find . -name "middleware.ts" -o -name "middleware.js" | head -5
   

   Check if global auth middleware exists (reduces per-route auth requirements).

4. Server Actions (Next.js 14+):

   grep -r "'use server'" --include="*.ts" --include="*.tsx" -l
   

   Server actions are also attack surface — treat as API routes. For each server action function, verify it performs authentication before accessing data. Server actions are callable from any client component and receive no automatic auth — they are functionally identical to unauthenticated POST endpoints unless the function explicitly calls

   getSession()

   ,

   getAuthContext()

   , or equivalent.

Compile a list of all routes with their HTTP methods and file paths.

Step 2: Check Authentication (Check 1)

For each route, determine if it verifies the caller is authenticated:

Search for auth patterns in each route file:

• getAuthContext

  /

  getSession

  /

  getServerSession

  /

  auth()

  — framework auth

• getToken

  /

  verifyToken

  /

  jwt.verify

  — manual JWT

• cookies().get

  with session validation — cookie-based auth

• headers().get('authorization')

  with validation — bearer token

• createRouteHandlerClient

  /

  createServerComponentClient

  — Supabase auth

Classify each route:

Flag as CRITICAL if a route performs database writes or returns user-specific data with no auth.

Known public route patterns (classify as ℹ️ INFO, not CRITICAL):

• /api/health

  ,

  /api/status

  — health checks

• /api/webhooks/*

  — external webhooks (need signature verification instead)

• /api/auth/*

  — auth flow endpoints (login, callback, register)

• /api/public/*

  — explicitly named public routes

• /api/cron/*

  — cron jobs (need secret verification instead)

Step 3: Check Authorization (Check 2)

For authenticated routes, verify they check what the user can access:

Search for authorization patterns:

• verifyOrgAccess

  /

  checkOrgMembership

  /

  requireRole

  — org-level authz
• Comparing

  user.id

  against resource

  user_id

  /

  owner_id

  — ownership check
• Role checks:

  user.role === 'admin'

  or similar
• Supabase RLS (may handle authz at database layer — note as INFO)

Flag as WARNING if:

• Route fetches data by ID from params without ownership verification
• Route accepts

  organization_id

  from request body instead of deriving from session
• Multi-tenant route returns data without org scope filter
• DELETE route has no ownership check

Pattern to enforce:

// BAD — trusts client-provided org ID
const { orgId } = await req.json();
const data = await db.from('documents').select().eq('org_id', orgId);

// GOOD — derives org from authenticated session
const { orgId } = await getAuthContext(req);
const data = await db.from('documents').select().eq('org_id', orgId);

Step 4: Check Input Validation (Check 3)

For routes that accept request body or query params:

Search for validation patterns:

• z.object

  /

  z.string()

  /

  .parse(

  /

  .safeParse(

  — Zod

• Joi.object

  /

  .validate(

  — Joi

• yup.object

  /

  .validate(

  — Yup

• body.

  or

  req.json()

  followed by manual type checks — weak validation

Flag as WARNING if:

• Route reads

  req.json()

  or

  request.body

  without schema validation
• Route uses query params in database queries without validation
• Route passes user input directly to external APIs

Flag as CRITICAL if:

• Route uses dynamic code execution with user input (see Check 5)
• Route constructs file paths from user input without sanitization

Step 5: Check Rate Limiting (Check 4)

For public-facing routes:

Search for rate limiting patterns:

• rateLimit

  /

  rateLimiter

  /

  limiter

  imports

• @upstash/ratelimit

  — serverless rate limiting

• X-RateLimit

  header setting
• Middleware-level rate limiting (check

  middleware.ts

  )

Flag as WARNING if:

• Login/register routes have no rate limiting (brute force risk)
• Public data endpoints have no rate limiting (scraping/abuse risk)
• Webhook endpoints have no rate limiting (replay attack risk)

Step 5b: Check Request Size Limits (Check 4b)

For POST/PUT/PATCH routes that accept request bodies:

Search for size enforcement patterns:

• Content-Length

  header checks before parsing body

• bodyParser

  config with

  sizeLimit

  option

• export const config = { api: { bodyParser: { sizeLimit: '...' } } }

  — Next.js Pages Router
• Next.js App Router: check if

  request.text()

  /

  request.json()

  is called without upstream size limits
• Middleware-level body size restrictions

Flag as WARNING if:

• Routes that accept file uploads, JSON bodies, or form data have no explicit size limit
• No global body size limit configured in middleware or framework config
• A route reads

  await request.json()

  on an unbounded body — a malicious client can send gigabytes of JSON, causing memory exhaustion (DoS)

Note: Next.js App Router does NOT enforce a default body size limit on route handlers. Unlike the Pages Router (which defaults to 1MB via

bodyParser

Correct pattern:

// Check Content-Length before parsing
const contentLength = parseInt(request.headers.get('content-length') || '0');
if (contentLength > 1_000_000) { // 1MB
  return NextResponse.json({ error: 'Request too large' }, { status: 413 });
}
const body = await request.json();

Step 5c: Check Idempotency Keys (Check 4c)

For routes that create payments, charges, transfers, or financial transactions:

Search for idempotency patterns:

• idempotencyKey

  /

  idempotency_key

  /

  Idempotency-Key

  header
• Stripe:

  stripe.paymentIntents.create({}, { idempotencyKey: ... })

  — built-in support
• Square:

  idempotency_key

  field in request bodies — built-in support
• Custom: checking for duplicate request IDs before processing

Identify payment mutation routes: Search for routes that call:

• stripe.paymentIntents.create

  ,

  stripe.charges.create

  ,

  stripe.invoices.pay

• stripe.checkout.sessions.create

  ,

  stripe.subscriptions.create

• squareClient.payments.create

  ,

  squareClient.orders.create

• Any route that inserts into

  invoices

  ,

  payments

  ,

  orders

  , or

  transactions

  tables

Flag as WARNING if:

• Payment-creating routes don't use idempotency keys — network retries can cause duplicate charges
• Routes that create financial records have no duplicate-request protection

Correct pattern:

// Stripe — pass idempotency key from client or generate deterministically
const session = await stripe.checkout.sessions.create(
  { ... },
  { idempotencyKey: `order-${orderId}-${timestamp}` }
);

Step 6: Check SQL Injection (Check 5)

Search for dangerous query patterns:

• Template literals in raw SQL strings with interpolated variables — CRITICAL
• String concatenation in queries:

  "SELECT * FROM " + table

  — CRITICAL

• .rpc()

  calls with unsanitized user input — WARNING
• Raw SQL via

  prisma.$queryRawUnsafe

  or

  sql.unsafe

  — CRITICAL

Safe patterns (do not flag):

• Parameterized queries with tagged templates (Prisma)
• Supabase client

  .from().select().eq()

  chain — safe by design
• Prepared statements with

  $1, $2

  placeholders

Step 7: Check Data Exposure (Check 6)

Search for sensitive data in responses:

• Returning full user objects:

  return NextResponse.json(user)

  — may include password hash
• Returning

  select('*')

  results without column filtering — WARNING
• Logging request bodies that may contain passwords — WARNING
• Returning internal IDs, database errors, or stack traces — WARNING

Fields that should never appear in API responses:

password

password_hash

hashed_password

secret

token

refresh_token

api_key

private_key

ssn

credit_card

Search each route file for these field names, then check if they appear in return/response paths.

Step 8: Check CORS Configuration (Check 7)

Search for CORS patterns:

• Access-Control-Allow-Origin: *

  — overly permissive (WARNING)

• Access-Control-Allow-Credentials: true

  with wildcard origin — CRITICAL
• Missing CORS headers on routes that need cross-origin access — INFO

• next.config.js

  headers configuration for CORS

Check

next.config.js

next.config.mjs

grep -A5 "Access-Control\|headers\(\)" next.config.*

Step 9: Check Error Handling (Check 8)

Search for error patterns in each route:

• Bare

  catch (e) { return NextResponse.json(e) }

  — leaks stack traces (WARNING)

• catch (e) { return NextResponse.json({ error: e.message }) }

  — leaks internal errors (WARNING)
• No try/catch around database operations — unhandled errors become 500s with stack traces (WARNING)

• console.error

  with full error objects in production — log exposure (INFO)

Correct pattern:

catch (error) {
  console.error('Route /api/items failed:', error);
  return NextResponse.json(
    { error: 'Internal server error' },
    { status: 500 }
  );
}

Step 10: Check Webhook & Special Routes (Check 9)

For webhook routes (

/api/webhooks/*

• Stripe: must call

  stripe.webhooks.constructEvent(body, sig, secret)

  — CRITICAL if missing
• GitHub: must verify

  X-Hub-Signature-256

  header
• Generic: must verify shared secret or HMAC signature
• Must use raw body (

  req.text()

  not

  req.json()

  ) for signature verification

For file upload routes:

• Must enforce file size limits — WARNING if missing
• Must validate file type / MIME type — WARNING if missing
• Must not store uploads in publicly accessible paths without auth — CRITICAL

For DELETE routes:

• Must verify resource ownership before deletion — CRITICAL if missing
• Should use soft delete pattern where appropriate — INFO

Step 11: Generate Report

🛡️ API Security Audit Report
Project: <project-name>
Routes found: <count>
Server actions: <count>
Global middleware auth: <yes/no>

## Route Audit

| Route | Method | Auth | Authz | Validation | Risk | Issues |
|-------|--------|------|-------|------------|------|--------|
| /api/users | GET | ✅ | ✅ | ✅ | ✅ OK | — |
| /api/users | POST | ✅ | ✅ | 🔴 | ⚠️ WARN | No input validation |
| /api/items/[id] | DELETE | 🔴 | 🔴 | — | 🔴 CRIT | No auth, no ownership check |
| /api/webhooks/stripe | POST | ℹ️ | — | — | ✅ OK | Signature verified |
| /api/admin/users | GET | ✅ | ⚠️ | ✅ | ⚠️ WARN | No role check for admin route |

## Critical Issues
1. **DELETE /api/items/[id]** — No authentication. Any request can delete any item.
   → Fix: Add `getAuthContext(req)` and verify `item.user_id === user.id` before deleting.

2. **POST /api/upload** — No file size limit. Server vulnerable to resource exhaustion.
   → Fix: Add size limit config or check `Content-Length` header.

## Warnings
1. **POST /api/users** — Request body parsed without schema validation.
   → Fix: Add Zod schema and parse before processing.

2. **GET /api/admin/users** — Authenticated but no admin role verification.
   → Fix: Add role check before returning data.

## Info
1. **Supabase RLS active** — Authorization may be handled at database layer for some routes.
   Verify RLS policies cover the same access patterns. Run `rls-checker` for full RLS audit.

## Summary
- 🔴 Critical: <count>
- ⚠️ Warning: <count>
- ℹ️ Info: <count>
- ✅ OK: <count>
- Total routes: <count>

## Checklist
- [ ] All non-public routes authenticate callers
- [ ] All data-access routes verify ownership/org membership
- [ ] All POST/PUT/PATCH routes validate input with schema
- [ ] Login/register routes have rate limiting
- [ ] Webhook routes verify signatures
- [ ] No raw SQL with user input
- [ ] API responses exclude sensitive fields
- [ ] Error responses don't leak stack traces
- [ ] CORS configured for specific origins, not wildcard
- [ ] POST/PUT/PATCH routes enforce request body size limits
- [ ] Payment-creating routes use idempotency keys
- [ ] Server actions verify auth before data access

Step 12: Suggest Fixes

For each CRITICAL and WARNING issue, provide:

1. The exact code fix with file path and line number
2. Any new dependencies needed (e.g.,

   @upstash/ratelimit

   for rate limiting)
3. Whether the fix requires changes to other files (middleware, types, etc.)

Offer to apply fixes directly if the user approves.

Risk Levels

Related Skills

• rls-checker — Audit Supabase RLS policies (database-level security)
• secrets-scanner — Find exposed API keys and credentials
• owasp-top10 — Full OWASP Top 10 vulnerability assessment

Level History

• Lv.1 — Base: Route discovery (App Router, Pages Router, Server Actions, middleware), 9-point analysis (auth, authz, validation, rate limiting, SQLi, data exposure, CORS, error handling, webhooks/uploads/deletes), structured report with risk levels, inline fix suggestions. Patterns derived from AdminStack (getAuthContext, verifyOrgAccess) and 10+ production Next.js apps. (Origin: MemStack Pro v1.0, Mar 2026)
• Lv.2 — Audit feedback: Added request body size limit check (App Router has no default limit), idempotency key check for payment mutations (Stripe/Square), Server Actions auth verification (callable from any client, no automatic auth). (Origin: AdminStack audit, Mar 2026)