Api security

API Security — OWASP API Security Top 10 (2023) for Next.js

Production-grade API security patterns for Next.js App Router. Covers every category in the OWASP API Security Top 10 (2023) with cross-references to the OWASP Web Top 10 (2021). Verified against the official OWASP specifications.

Architecture

Request → proxy.ts (auth gate) → Route Handler / Server Action
                                       ↓
                                  Input Validation (Zod)
                                       ↓
                                  Data Access Layer (auth + authz + DTO)
                                       ↓
                                  Database (parameterized queries)
                                       ↓
                                  Filtered Response (DTO, no raw records)

The Data Access Layer (DAL) is the central security architecture recommended by Next.js. All database access, authorization checks, and response filtering happen in one server-only module — never in components or actions directly.

Quick Reference

Resource	OWASP API	OWASP Web	What It Covers
Access Control	API1, API5	A01	BOLA/IDOR, function-level auth, ownership checks
Authentication	API2	A07, A02	Session management, JWT, Clerk/Auth0, proxy.ts
Input Validation	API3, API8	A03	Zod schemas, SQL injection, XSS, Server Action validation
Rate Limiting	API4	A04	Per-endpoint limits, cost attacks, Upstash patterns
Security Headers	API8	A05	CSP, HSTS, CORS, Permissions-Policy, next.config
Data Exposure	API3, API6	A04	DAL pattern, DTOs, error sanitization, response filtering
Supply Chain	API9, API10	A06, A08	Dependencies, env vars, CI/CD, third-party APIs
SSRF & Logging	API7	A09, A10	URL validation, fetch safety, secure logging, audit trails

Decision Matrix: "Where Do I Add Security?"

Layer	What to Check	Why
proxy.ts	Auth redirect, CSP nonce, rate limit headers	First line — blocks unauthenticated requests early
Route Handler (route.ts)	Auth + authz, input validation, CORS, CSRF	Public HTTP endpoint — treat as untrusted
Server Action ('use server')	Auth + authz, input validation, return filtering	Also a public HTTP endpoint — not protected by the UI
Data Access Layer (data/*.ts)	Ownership checks, field filtering, parameterized queries	Last line — defense in depth
next.config.ts	Security headers, redirects, allowed image domains	Static security baseline

The #1 Mistake: Server Actions Are Public Endpoints

Every exported 'use server' function is reachable via direct POST request. Page-level auth does NOT protect actions on that page.

// FAIL — no auth check, anyone can call this via POST
'use server'
export async function deleteAccount(userId: string) {
  await db.delete(users).where(eq(users.id, userId))
}

// PASS — validates auth AND ownership inside the action
'use server'
import { getCurrentUser } from '@/data/auth'

export async function deleteAccount() {
  const user = await getCurrentUser()
  if (!user) throw new Error('Unauthorized')
  await db.delete(users).where(eq(users.id, user.id))
}

Notice: the PASS version doesn't accept userId as a parameter — it derives it from the session. This prevents IDOR (Insecure Direct Object Reference).

Decision Matrix: "Is This Secure?"

Question	If No →	Resource
Does every Server Action re-verify auth?	Add getCurrentUser() check	Access Control
Does every Route Handler validate input with Zod?	Add schema validation	Input Validation
Are database queries parameterized?	Use tagged templates or ORM	Input Validation
Does the response return only needed fields?	Add DTO layer	Data Exposure
Are rate limits in place for auth endpoints?	Add Upstash/Arcjet	Rate Limiting
Are security headers configured?	Add to next.config.ts	Security Headers
Is proxy.ts checking auth before page access?	Add auth middleware	Authentication
Are env vars only accessed in the DAL?	Move to server-only module	Supply Chain
Does fetch() in server code validate URLs?	Add URL allowlist	SSRF & Logging
Are errors sanitized before returning to client?	Return generic messages	Data Exposure

OWASP API Security Top 10 (2023) — Full Mapping

#	Category	Severity	Resource
API1	Broken Object Level Authorization (BOLA)	Critical	access-control
API2	Broken Authentication	Critical	authentication
API3	Broken Object Property Level Authorization	High	input-validation, data-exposure
API4	Unrestricted Resource Consumption	High	rate-limiting
API5	Broken Function Level Authorization	Critical	access-control
API6	Unrestricted Access to Sensitive Business Flows	Medium	data-exposure
API7	Server Side Request Forgery	High	ssrf-and-logging
API8	Security Misconfiguration	Medium	security-headers, input-validation
API9	Improper Inventory Management	Medium	supply-chain
API10	Unsafe Consumption of APIs	Medium	supply-chain

OWASP Web Top 10 (2021) — Cross-Reference

#	Category	Mapped To
A01	Broken Access Control	access-control
A02	Cryptographic Failures	authentication
A03	Injection	input-validation
A04	Insecure Design	rate-limiting, data-exposure
A05	Security Misconfiguration	security-headers
A06	Vulnerable & Outdated Components	supply-chain
A07	Auth Failures	authentication
A08	Software & Data Integrity Failures	supply-chain
A09	Logging & Monitoring Failures	ssrf-and-logging
A10	SSRF	ssrf-and-logging

Code Review Checklist

When reviewing API code in Next.js, verify:

• Every 'use server' function checks auth — no exceptions
• No user-supplied IDs used for ownership — derive from session
• All inputs validated with Zod before use
• Database queries use parameterized queries or ORM
• Responses return DTOs, not raw database records
• Error messages don't leak stack traces, SQL, or internal paths
• Security headers set in next.config.ts (CSP, HSTS, X-Frame-Options)
• Rate limiting on auth endpoints and expensive operations
• proxy.ts gates auth before page/action access
• Environment variables accessed only in server-only modules
• No fetch() to user-controlled URLs without allowlist
• Dependencies audited — no known vulnerabilities
• .env*.local in .gitignore