What goes wrong when setattr writes object fields named by a client-supplied payload?

## The pattern and why it appears The construct is familiar from update endpoints and internal builders: ```python for key, value in payload.items(): setattr(target, key, value) ``` It is written to avoid repeating a dozen assignments, and it works beautifully until the payload keys come from outside. `setattr` is `obj.name = value` with the name supplied as a value; it does no filtering, and assignment in Python **creates** an attribute that does not already exist rather than failing. So a client that names a field gets to write it, whether or not it is part of the API. ## Concrete failure: a silent truncation Consider a warehouse pick-list builder that accepts an update payload for a pick list. The object carries the fields the API documents — the line items, the destination — and also internal state: a `max_rows` cap that bounds how many lines a printed sheet may hold. The endpoint loops `setattr` over the payload. A client sends `max_rows` alongside the documented fields, and from then on the builder trims every list it produces to that value. Notice what does *not* happen. No exception. No validation error. No log line. The pick lists come out short, pickers work the sheet they are handed, and the stock counts drift. The report that finally surfaced it in one team's telling arrived after the change had been live across a three-week release train, by which point the wrong sheets were indistinguishable from correct ones and the reconciliation had to be done by hand. That asymmetry is the heart of the lesson: an attacker-controlled *read* usually produces an error or an obviously wrong response, while an attacker-controlled *write* produces a plausible one. The same shape reaches further when the object carries a flag the rest of the code trusts — a `validated` marker, an `is_admin` cache, a `dry_run` switch. Rebinding a boolean that some later branch reads is a complete authorisation bypass with no invalid input anywhere in sight. ## Why the usual mitigations do not hold * **"The object only has the fields we defined."** It also has whatever a base class defined, and after the first stray write, whatever the client named. `__slots__` will raise on a name outside the declared set — a real narrowing, and a side effect of a memory optimisation, not a security control. It still permits writes to every declared slot. * **"We reject keys starting with an underscore."** The interesting internal fields are usually ordinary names, because nobody marks a batch limit private. * **"We validate the values."** Type-checking the value does not authorise the *name*. A perfectly valid integer written to the wrong attribute is exactly this bug. * **"The ORM or model layer will catch it."** Only if the write goes through that layer. `setattr` on the instance frequently bypasses whatever the framework's own update path would have checked. ## The safe shape Bind the writable surface explicitly, and prefer building a new validated object over mutating a live one: ```python WRITABLE = frozenset({"destination", "line_items"}) unknown = set(payload) - WRITABLE if unknown: raise ValueError(f"fields not writable: {sorted(unknown)}") for key in WRITABLE & payload.keys(): setattr(target, key, payload[key]) ``` Two design refinements worth stating in an interview. First, **reject rather than ignore** unknown fields: silently dropping them hides both client bugs and probing, and it is the behaviour that lets a bad integration run for weeks. Second, prefer a **parse step** — a dataclass or schema layer that turns the payload into a typed object with exactly the documented fields, which you then apply field by field. Once such a layer exists, `setattr` with a computed name disappears from the code entirely, which is the real goal: not a safer dynamic write, but no dynamic write. ## In review `setattr` with a non-literal name is worth the same question as `getattr`: what is the complete set of names this can write, and who decides it? Because failures here are silent, the review is the main control — there is no exception to catch and often no log to alert on. It is also worth checking `vars(obj).update(payload)` and direct `obj.__dict__.update(payload)`, which are the same bug wearing different clothes and slip past a search for `setattr`.