Input validation on all endpoints

A single unvalidated endpoint — one handler that reads req.body.email directly into a database query without a validation step — is all an attacker needs to trigger injection (CWE-20, OWASP A03:2021), corrupt data with unexpected types, or crash the application with oversized inputs. OWASP A08:2021 (software and data integrity failures) also applies when schema-less input reaches business logic unguarded. TypeScript types do not enforce runtime shapes: JSON.parse gives you any, and type assertions are compile-time fiction.

Add runtime validation via Zod to every route handler that accepts input. Define schemas in src/lib/validations/ and import them into route files:

// src/lib/validations/user.ts
export const createUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
})

// app/api/users/route.ts
const result = createUserSchema.safeParse(await req.json())
if (!result.success) {
  return apiError('VALIDATION_ERROR', result.error.message, 400)
}

Also validate path parameters — confirm that ID segments are valid UUIDs (z.string().uuid()) before using them in database queries. A validation schema is not optional polish; it is your first defense against injection and your contract with every caller.

• ID: input-validation-all
• Severity: critical
• What to look for: Enumerate all POST/PUT/PATCH route handlers. Count the ratio of validated routes to total. Check each for input validation before the data reaches business logic or database queries. Look for: Zod parse() or safeParse(), Yup validate(), Joi validate(), class-validator validate(), custom validation functions, or TypeScript type assertions used in place of runtime validation. Also check: are query parameters validated (not just body)? Are path parameters validated (e.g., is an ID checked to be a valid UUID before use)? Look specifically for handlers that use req.body.fieldName or params.id directly without any validation step.
• Pass criteria: At least 100% of routes that accept user input (request body, query params, path params) runs that input through a validation library or explicit validation logic before using it. Validation errors return 400 responses with clear error messages.
• Fail criteria: Any route handler that uses req.body, req.query, or req.params directly in database queries or business logic without validation. Even a single unvalidated endpoint constitutes a failure. Must not pass when validation exists on most routes but even 1 endpoint accepts raw input.
• Skip (N/A) when: The project has no routes that accept any user input (read-only GET endpoints only with no parameters). Signal: all routes are GET with no query parameters and no path parameters.
• Detail on fail: Name the specific unvalidated routes (e.g., "POST /api/users uses req.body.email directly in DB query without Zod or other validation; PATCH /api/posts/:id uses req.params.id without UUID validation"). Max 500 chars.
• Remediation: Add runtime validation in app/api/ route files to every endpoint that accepts input. The recommended approach for TypeScript projects is Zod: define a schema for each request shape, then call schema.safeParse(req.body) and return a 400 if parsing fails. Keep schemas in a dedicated lib/validations/ or schemas/ directory and import them into route handlers. Also validate path parameters — check that IDs are valid UUIDs before querying the database. Input validation is your first defense against injection attacks, data corruption, and application errors from unexpected input.
• Cross-reference: For a deeper look at injection and injection-adjacent vulnerabilities, the SaaS Security Hardening Audit covers SQL injection, XSS, and command injection in detail.