Overview
How an API handles and reports errors affects security: overly detailed errors leak information, while good error handling reveals nothing sensitive yet remains useful. This capstone lesson covers error handling and consolidates API security.
Learning objectives
- Explain the security risk of verbose error responses.
- Describe safe error-handling practices.
- Consolidate the API-security checklist.
Core concept
APIs should return errors that are useful to legitimate clients but reveal nothing sensitive to attackers. Verbose errors — stack traces, database messages, internal paths, library/versions, or messages that confirm whether a resource/account exists — provide reconnaissance and can expose implementation details or aid enumeration. Safe practice: return generic, consistent error messages and appropriate status codes to clients, while logging the detailed error server-side for developers.
How it works
On an error, the API sends the client a suitable status code (e.g. 400 for bad input, 401/403 for auth, 404, 500) with a generic message, and records full details (stack trace, context) in server logs not exposed to clients. Messages should be consistent so they do not leak whether an account/resource exists (tying to enumeration defenses from the authentication module). This avoids handing attackers internal details or existence oracles while still allowing legitimate clients to understand and developers to debug. It also prevents accidental disclosure of secrets in error output.
Practical example
A request triggers a database error. A poorly designed API returns the raw database exception and a stack trace, revealing the query structure, table names, and framework version — a gift to an attacker. A well-designed API instead returns a generic 500 Internal Server Error (or 400 for bad input) with a neutral message, while logging the full exception server-side for the developers. Similarly, login/lookup errors are phrased uniformly so they don't reveal whether an account exists.
Cybersecurity relevance
Information disclosure through verbose errors is a common finding and aids attackers in reconnaissance and enumeration; it can even leak secrets. Safe error handling is standard hardening and complements the module's other controls. This capstone consolidates the API-security checklist: authenticate every request (scoped, short-lived credentials), enforce object-level authorization (top risk), validate input (schema/allowlist, prevent mass assignment), apply rate limiting, use HTTPS and security headers, and handle errors without leaking details — all following from REST's stateless, directly-callable model.
Common mistakes
- Returning stack traces, DB messages, or internal details to clients.
- Inconsistent error messages that reveal whether accounts/resources exist (enumeration).
- Logging sensitive data or, conversely, not logging enough server-side to debug.
Key takeaways
- Return generic, consistent client-facing errors with appropriate status codes; log detailed errors server-side only.
- Verbose errors (stack traces, DB messages, existence oracles) aid reconnaissance and enumeration and can leak secrets.
- The API-security checklist: per-request authentication, object-level authorization (top risk), input validation (anti-mass-assignment), rate limiting, HTTPS/security headers, and safe error handling — all rooted in REST's stateless, directly-callable model.
Check your understanding
- Why are verbose error responses (stack traces, database messages) a security risk?
- Summarize the core controls in the API-security checklist.