Bits of .NET

🤖 The AI Prompt That Checks Whether Every Endpoint Actually Validates What It Receives

Input validation is the kind of thing every developer agrees is important and almost nobody consistently audits across an entire API surface after the fact – new endpoints get added over months or years, some by people who always remembered to validate, some by people in a hurry, and the result is an API where validation coverage is inconsistent in a way that’s hard to see without reading every single endpoint one at a time. This prompt asks an AI assistant to do exactly that pass, systematically.

📋 The Prompt

Here are the endpoint handlers from our API (route, method, and the
full handler code for each). For each endpoint, tell me:

1. Which parameters (route params, query string, request body fields)
   are used directly without any visible validation - no null/empty
   check, no type or range check, no length limit - before being
   used in a database query, a file path, or returned in a response
2. Whether missing validation on a given parameter looks low-risk
   (it's only ever used for something cosmetic) or high-risk (it
   flows into a query, a file operation, or a decision that affects
   another user's data)
3. For the high-risk cases, the single most likely failure mode if
   that parameter arrived malformed, empty, or unexpectedly large

Group the findings by risk level, highest first.

Endpoint handlers:
[PASTE THE ENDPOINT HANDLER CODE HERE]

✅ Why This Prompt Works

• Asking specifically which parameters flow into a database query, a file path, or a cross-user decision focuses the review on validation gaps that actually matter, rather than producing a long undifferentiated list where a missing check on a cosmetic display field gets equal billing with one that could expose another user’s data.
• Requesting the most likely failure mode for each high-risk gap turns an abstract ‘this isn’t validated’ observation into something concrete enough to prioritize and assign – a vague warning is easy to defer, a specific plausible failure is much harder to ignore.
• Reviewing handlers in bulk, across the whole API surface at once, surfaces the handlers written in a hurry or by someone newer to the codebase, which tend to cluster in specific areas rather than being evenly spread – useful context for where future review attention should actually go.

⚠️ Where to Draw the Line

• This finds the absence of validation code, not whether validation happening somewhere else (a shared middleware, a framework-level model validation attribute) already covers the same parameter – a finding here is worth confirming against the rest of the request pipeline before assuming a gap is real.
• A parameter that looks unvalidated in the handler code shown might still be effectively constrained by the database schema, a type system, or a framework’s model binding – this prompt is a starting point for a targeted review, not a definitive security audit on its own.