Input length limits are enforced on user prompts

Unbounded user input flowing into LLM calls enables two distinct attack classes. First, context-window flooding: an attacker sends 50,000 characters designed to push your system prompt out of the model's effective attention range, weakening instruction adherence—a pattern consistent with OWASP LLM01:2025 evasion techniques. Second, cost amplification: a single API call with a maxed-out context window can cost 10–50× a normal request, making your AI feature a direct financial target (NIST AI RMF MANAGE 1.3). CWE-20 covers the missing input validation directly. For applications with per-seat or consumption billing models, uncontrolled token spend can eliminate margin on every request.

Enforce a maximum length constraint at the schema layer, before the value ever reaches the AI call. A 4,000-character ceiling works for most chat UIs; document-analysis flows should apply per-chunk limits instead.

// Zod schema with enforced upper bound
const ChatInputSchema = z.object({
  message: z.string().min(1).max(4000),
  conversationId: z.string().uuid().optional()
})

export async function POST(req: Request) {
  const body = ChatInputSchema.safeParse(await req.json())
  if (!body.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 })
  }
  // body.data.message is now bounded before reaching the AI provider
}

For token-sensitive flows (RAG, document analysis), add a token counting step using tiktoken or your provider's counting endpoint after length validation, so character limits alone don't mask large-token inputs from compact Unicode.