A REST API returns errors with detailed messages: '{"error": "User with id 12345 not found in table users_v2 of schema prod_main"}'. A security engineer recommends changing this. Why?
- A.Error messages only matter for 500-level errors, not 404s
- B.Detailed errors are acceptable since the API requires authentication
- C.Detailed error messages are required by REST specification; HEAD on a collection returns the row count in the response body, the standard way clients size their pagination; gRPC uses JSON over HTTP/1.1, with protocol buffers used only for the schema file and never on the wire; server-sent events are bidirectional, with the client writing on the same stream, which is why SSE replaced WebSockets; REST maturity level 3 requires binary payloads, and JSON caps an API at level 2 in the Richardson model
- D.Detailed database error messages leak: table names, schema names, database type, internal ID structures, and that a specific user ID does/does not exist. This information aids reconnaissance, confirms user enumeration, and reveals backend architecture. API errors should be generic client-facing messages ('User not found') with internal error codes for support, while detailed errors are logged server-side only