Fix the design · Incident triage

Leaky Entity: The Order API That Exposed a Password Field

An order API returns the database object directly, and a security review found a sensitive hash field from a nested customer object in the JSON response.

In a low-level design interview, the interviewer opens getOrder() and explains that a security review found sensitive fields in the JSON response, then asks what concerns you about this approach.

We need your help. Identify what is risky about returning the database object, then fix the path from “load order” → “JSON response” so the API only exposes a public shape and does not leak nested sensitive fields or trigger extra queries while building JSON.

Problem

Fix the team’s existing getOrder API — it already loads an Order from the database and returns that database object as the HTTP JSON response.

Incident summary

  • A security review found a password hash field on a nested customer object in the JSON response.
  • The response payload grew large when an order had many line items.
  • QA logs showed extra database activity while the JSON response was being built.
  • The team said mapping to a public response object was boilerplate they did not need yet.

Assumptions made by the team

  • Returning database objects is faster than mapping to a response shape.
  • Sensitive fields can be hidden one by one later if a review finds them.
  • Clients only read the fields they need, so extra fields in JSON are harmless.
  • Related rows load on their own when we read them, and that path is always fast enough.

Impacted services

  • API contract (critical) — Database shape exposed on the wire.
  • Security (critical) — Sensitive fields can leak via nested objects.
  • Performance (degraded) — Extra DB lookup per item while building JSON.
  • Clients (degraded) — Break when schema changes — tight coupling.

Triage questions

  1. What concerns you about returning the database Order object directly from the controller?
  2. What would you return instead and where would mapping happen?
  3. Why is hiding fields one-by-one a weak fix compared to a dedicated response object?
  4. If we add a new column to Order, does the API change — and when is returning the database object still okay?

← All design challenges

Loading scenario…