hunt-exceptional-conditions

# HUNT-EXCEPTIONAL-CONDITIONS — Verbose Errors / Fail-Open (A10:2025) ## What actually pays Well-built apps catch errors and return a clean, generic message. A broken app, when handed input it didn't expect, throws an unhandled exception and renders a **developer error page** straight to the client — leaking the stack trace, the ORM/query internals, server-side file paths, and framework/library versions. That disclosure is the finding (and it arms SQLi/RCE/path attacks next). ## Recon Any endpoint that parses input is a candidate; the richest are: ``` JSON APIs that expect typed fields: POST /api/* with {numbers, ids, enums} Endpoints with numeric/id path or query params: /item/{id}, ?page=, ?quantity= Search / filter / sort params File or content-type sensitive uploads ``` ## Attack — send what the code didn't anticipate Take a known-good request and break ONE assumption at a time: - **Wrong type:** a field the app expects to be a number/string is sent as an array or object — `{"rating":"x","comment":[1,2,3]}`, `{"quantity":{}}`. - **Malformed body:** truncated/!invalid JSON, an unterminated string, a stray brace, a wrong/missing Content-Type. - **Boundary/oversized:** a very long string, a huge/negative/overflow number. - **Null byte / control chars** embedded in a value. ``` POST /api/Feedbacks {"rating":"notanumber","comment":[1,2,3]} GET /item/' OR /item/%00 (also exercises the error path) ``` Watch the RESPONSE BODY, not just the status: a 500 (or e...