Remove Sensitive API Error Details

An API can deny a request correctly and still leak data in its error. Database messages may include a private table value. Validation errors may echo a token or a customer filename. A stack trace may expose service names and paths. Review the error serializer as part of the boundary. The OWASP REST Security Cheat Sheet supports restrained error responses.

Error-field allowlist

A correlation ID helps support find the internal event without giving the caller the raw event. Keep the internal event behind access control and retention limits. Do not put complete request bodies in error logs by default.

Exercise failure paths

Use synthetic tenants and values. Trigger an invalid field, a missing token, a foreign record, a failed downstream service, and a malformed upload reference. Compare the response body and headers. Search test logs for the synthetic secret marker. A denied API call should reveal neither B's data nor the existence of a protected field unless product policy permits it.

The OWASP API Security Top 10 includes improper inventory and authorization risks; a safe error shape does not replace those controls. This artifact is an explicit error contract. Add it to route tests so a new framework default cannot return a verbose exception in production.

Keep error messages useful for the caller's next safe step. “Invalid input” is often too vague for an authorized user, while “record belongs to Tenant B” is too specific. State the failed field only when it is already known to the caller. If the team cannot decide whether a detail is public, omit it from the response and review the need later.