How do you prevent password_hash from appearing in a FastAPI response?

What's really being asked

FastAPI response model filtering and the security-critical separation between internal data models and external API contracts. Interviewers want to see that you prefer declarative serialization control over imperative workarounds, and that you understand how FastAPI uses Pydantic to guarantee what leaves the server.

The full answer

First, the preferred approach is to create a separate Pydantic output model that simply does not include the password_hash field at all. This keeps the database schema isolated from the API contract and prevents accidental leaks when new sensitive fields are added later. Second, mention the decorator-level option response_model_exclude which accepts a set of field names to omit during serialization. This is useful for quick fixes or legacy endpoints but is less maintainable than a dedicated model because the contract is not explicit in the type system. Third, note that FastAPI performs data filtering automatically when the return type or response_model is declared, so the conversion happens declaratively without manual intervention.

The mistakes people make

A major red flag is suggesting manual dictionary manipulation such as deleting the key before returning the model. Another is proposing runtime mutation of the Pydantic model or using monkey-patching to hide fields dynamically. Relying on client-side filtering is also unacceptable from a security standpoint. Finally, using the same model for both database representation and API responses without any exclusion mechanism shows a lack of architectural boundaries and invites data leaks.

What usually comes next

The interviewer might ask how you would handle a field that should be included on creation but hidden on read, which points to having separate input and output models. They might also ask about response_model_include versus response_model_exclude, or how to handle nested models where sensitive data appears at multiple levels. Another angle is asking how Pydantic version two serialization behavior or model configuration interacts with FastAPI's automatic filtering.

A concrete example

Suppose you have a UserDB model with id, email, and password_hash. Define a UserOut model with only id and email. In the FastAPI path operation decorator, set response_model=UserOut. When the endpoint returns a UserDB instance, FastAPI filters the data to match UserOut and password_hash never reaches the JSON response. Alternatively, you could keep a single model and use response_model_exclude with a set containing password_hash in the decorator, though this is riskier for long-term maintenance because the original model still carries the sensitive field.