Exception paths and fail-open

Tags: misconfig, authz, fail-open

Level: advanced

Method

1. Pick one state change you own

   Choose a single action on an account you control: login, invite accept, export, payment step, or role change. Write down the happy-path result before you touch error cases.

   Tools: Burp Suite

2. Compare the error handler

   Send the same request with an empty body, a truncated body, a duplicate parameter, and a content type the route does not document. Record status, body, and whether the object changed.

   Tools: Burp Suite, Caido

3. Watch fail-open

   A fail-open bug applies the change, issues the token, or skips the check when a dependency errors or times out. The error string is not the finding. The resulting state is.

   Tools: Burp Suite

4. Auth on the error path

   Some stacks authenticate in middleware and authorize in the handler. If the handler throws before the check, a generic error page can still have performed a write. Compare an anonymous error with an authenticated one.

   Tools: Burp Suite

5. Retries and partial work

   Repeat a request that the server says failed. If the second call shows the first one actually landed, the client and the server disagree about the outcome. That is the note.

   Tools: Burp Suite

6. Stop at your object

   Do not force errors on shared jobs, other tenants, or production payment providers. One owned object is enough to show the state change.

   Tools: browser

Field notes

• SSRF is not this category in the 2025 list. SSRF sits under broken access control.
• A stack trace is context. Report it when it reveals a trust boundary, not as the bug itself.
• Name the exception and the state change in the first sentence of the report.

References

• https://owasp.org/Top10/2025/
• https://owasp.org/www-project-web-security-testing-guide/