A REST API's response to GET /users/me includes: {'id': 1, 'email': 'user@example.com', 'passwordHash': '$2b$10$...', 'internalNotes': 'flagged for fraud'}. What problem does this illustrate?
- A.Insecure Direct Object Reference - the API exposes internal record numbers (id 1, the notes table key) that the client should never be able to guess, trusting the URL path to hide each record
- B.Excessive Data Exposure - the API returns sensitive internal fields (password hash, internal notes) that the client should never receive, trusting the client to filter display data
- C.Security Logging Failure - the API writes sensitive fields (password hash, fraud notes) to a response that the client should never see, trusting the log pipeline to redact them later
- D.Lack of Rate Limiting - the API answers /users/me for any caller (even a bot) that should never reach it, trusting the client to throttle
Why B is correct
Returning full model objects and expecting the UI to hide sensitive fields is a common design mistake. The API must serialize only the fields the consumer legitimately needs. A serializer or response DTO should explicitly list allowed fields. Even if the frontend never displays passwordHash or internalNotes, they are visible in DevTools and intercepting proxies.
Know someone studying for Web App Fundamentals? Send them this one.