Exception and debug paths
Failures are a second API. Compare a normal response with a handled error and record what the error adds: a stack, a tenant, a token, or a route that skips a check.
Tags: debug, errors, info-leak, config
Checklist
- Error shape: HTML, JSON, or problem details, plus any trace id. Note fields that appear only on a client or server error.
- Extra detail: Framework banner, file path, query fragment, or dependency version. A banner is inventory unless it exposes a secret or an internal host.
- Ids in errors: Object ids, tenant ids, or emails for objects you should not see. Use two accounts you own to make that comparison.
- Debug routes: Health, metrics, env, schema UI, and admin toggles. Record which ones answer without the session the rest of the app requires.
- Flags the server trusts: Feature flags in the client. A flag that only hides a button is not a boundary. Note whether the API checks the same flag.
- Fail closed: When a token is rejected or a dependency errors, record whether the route denies or continues. Do not stress the dependency to force the error.
- Impersonation: Support login, view-as, and break-glass. Who can start them, whose data they open, and whether the action is audited.
- Client-visible logs: Your request id in a page, a source map, or a debug bundle. Stop before you would need someone else's data to go further.