Home / Attacks & tests / Error Handling Security Issues
2 test cases
Error Handling Security Issues
Error handling testing examines what the application says when something goes wrong. A failure is a legitimate outcome; the question is whether the response tells the caller only that it failed, or also how the application is built and what exists inside it.
What an attacker is trying to achieve
The attacker uses errors as an oracle. A verbose failure supplies component versions, file paths and query structure; a merely different failure supplies confirmation that a record, a username or a file exists. The second is quieter and often more useful than the first.
Test cases
2 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-ERRH-01 Analysis of Error Codes
Objective — Determine whether error responses disclose internal detail, and whether differences between error responses disclose the existence of resources the caller is not entitled to know about.
How it is tested — Submit input that fails at each distinct layer — malformed syntax, wrong types, absent required fields, oversized values, and references to objects that do not exist versus objects that exist but belong to another principal. Record status, body, headers and timing for each and compare. Repeat on non-HTML entry points, which commonly return the raw framework error the web interface suppresses.
Prerequisites — Two accounts in different ownership scopes; the entry point list; a proxy able to send malformed requests without the interface correcting them.
Indicators — Component names, versions, paths or query fragments in a response; distinguishable responses for non-existent versus unauthorised objects; a candid error on an API route where the web route is generic.
Coverage — WSTG-ERRH-01V7.4.1CWE-209CWE-203
Depth — Hybrid Verbose errors are found automatically; the distinguishable-failure comparison has to be set up deliberately with two ownership scopes.
WEB-ERRH-02 Analysis of Stack Traces
Objective — Determine whether unhandled exceptions reach the caller, exposing source structure, dependency versions and the internal call path.
How it is tested — Provoke unhandled conditions rather than validated ones: type confusion in parameters the application converts, values beyond the range a downstream component accepts, malformed structured payloads, and requests that break an assumption made after validation. Check error responses on every content type the application returns, and inspect responses delivered to client-side code, where traces are often present but never displayed on screen.
Prerequisites — Entry points accepting structured or typed input; a proxy; a non-production environment, since provoking unhandled exceptions can leave state inconsistent.
Indicators — A stack trace, source path or class name in a response; framework and dependency versions disclosed; a trace present in a response consumed by script but not rendered.
Coverage — WSTG-ERRH-02V7.4.1V14.3.2CWE-209CWE-497
Depth — Hybrid A scanner triggers common traces. Reaching the handler that was never expected to fail usually requires understanding what the code does after validation.
What we need from you
The ability to send deliberately malformed input to every entry point; two accounts in different ownership scopes so existence and permission failures can be compared; and a non-production environment, since the most informative errors are provoked by input that may disturb state.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-ERRH-01 — Testing for Improper Error Handling
- V7.4.1 — Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate.
- CWE-209 — Generation of Error Message Containing Sensitive Information
- CWE-203 — Observable Discrepancy
- WSTG-ERRH-02 — Testing for Stack Traces
- V14.3.2 — Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.
- CWE-497 — Exposure of Sensitive System Information to an Unauthorized Control Sphere
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.