Validation failures return useful error responses
Why it matters
When Body.parse(body) throws a ZodError inside an uncaught handler, most frameworks return a generic 500 Internal Server Error. The client has no idea what field was invalid, and your server logs expose the full Zod error tree — which reveals your schema structure to anyone reading logs or observing error responses. CWE-755 (Improper Handling of Exceptional Conditions) applies: a validation library that crashes the handler instead of returning a 400 teaches clients nothing useful and may leak internal schema details.
Severity rationale
Low because the primary failure is poor error communication and log leakage rather than direct exploitation, though repeated 500s from malformed inputs can mask real errors.
Remediation
Use .safeParse() to get a typed success/error result without throwing, then return an explicit 400 with the validation issues.
export async function POST(req: Request) {
const body = await req.json()
const result = Body.safeParse(body)
if (!result.success) {
return Response.json(
{ error: 'Invalid input', issues: result.error.issues },
{ status: 400 }
)
}
const user = await prisma.user.create({ data: result.data })
return Response.json(user, { status: 201 })
}
Alternatively, wrap .parse() in a try/catch and return a 422 with a sanitized error message. Avoid forwarding the raw ZodError.issues array to clients in production — it reveals your schema.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Implementation Validation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-390 — Detection of Error Condition Without Action
- cwe · CWE-755 — Improper Handling of Exceptional Conditions
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-security-theater·automated