How do you harden a getattr-based dispatcher that genuinely has to stay dynamic?

## When dynamic really is required Most `getattr` dispatch should simply become a dict. But some designs genuinely resolve names at runtime: a plugin system where third-party packages contribute actions, a rules engine where operators enable checks by name, a formatter table generated from a schema. The interview question is what disciplines make that defensible, and the answer has more structure than "validate the input". ## 1. Allowlist, never blocklist The single decision that matters. A blocklist asks "is this name forbidden?" and must be re-derived every time any class in the hierarchy changes. An allowlist asks "is this name one of the ones I published?" and is stable under those changes. ```python ALLOWED = frozenset({"pick", "pack", "ship"}) if action not in ALLOWED: raise ValueError(f"unknown action: {action!r}") ``` The specific blocklist to reject in review is filtering by leading underscore. It stops `_internal_helper` and `__class__`, and leaves untouched every public method the object has, including ones inherited from a framework base class that nobody on the team has read. Underscore filtering is a signal that the author was thinking about the attributes they could remember, not the attributes that exist. The strongest version of the allowlist is a **registry built at import time**, because it makes the public surface a deliberate act: ```python ACTIONS = {} def action(fn): ACTIONS[fn.__name__] = fn return fn ``` Now a new method is private by default and becomes reachable only when someone types the decorator — a diff a reviewer will notice. ## 2. Narrow the target object `getattr(self, name)` inside a controller resolves against everything that controller is: database handles, configuration, credentials held as attributes, template helpers, and every method of every mixin. Even with a correct allowlist, that object is a large blast radius if the check is ever bypassed or a name is added carelessly. Resolve instead against a small object whose entire attribute surface is actions — a module of plain functions, a class with nothing but the handlers, or the registry dict itself. Then the worst case of a check failure is bounded by an object that holds nothing else. This is defence in depth: the allowlist is the control, the narrow target is what makes a mistake in the control survivable. ## 3. Validate the resolved object, not only the name After lookup, confirm what you got: it is callable, and where relevant it carries the marker your registration applied. Two real bugs this catches — an attribute that shadows a method with data, and a callable inherited from somewhere you did not intend. A signature check with `inspect` before calling with request-derived arguments is cheap insurance in a plugin system where the contract is not enforced by anything else. ## 4. The failure path Three habits that show production experience: * **Do not echo the rejected name** into an HTML response or an error page; treat it as untrusted data everywhere it travels, including into logs, where a newline in the name can forge log lines. * **Log rejections with enough context to alert on.** A spike of unknown-action errors from one client is reconnaissance, and it is often the earliest signal you get. * **Fail closed and identically.** An `AttributeError` escaping as a 500 with a traceback tells the caller which names exist; a uniform "unknown action" for both "forbidden" and "does not exist" tells them nothing. Timing differences between the two branches are rarely worth engineering around here, but the message should not differ. ## 5. What the review question is When you see `getattr` with a non-literal name in a diff, the question is not "is this sanitised?" but **"what is the complete set of names this can resolve, and who decides it?"** If the answer is "whatever attributes that object happens to have", it is a finding regardless of the filtering. If the answer is "these five, listed here", the pattern is fine. `setattr` gets the same question in the write direction, and `hasattr` deserves a look too, since it answers existence questions about the same surface without ever calling anything. One more construct belongs on that list. `operator.attrgetter` takes a name string and, notably, follows dots: a single attrgetter call built from an untrusted string can walk a chain of attributes rather than fetching one. Anything that resolves a *dotted* name from input — an attrgetter, a hand-rolled loop that splits on `.` and calls `getattr` repeatedly, a template engine given a raw path — has a far larger reachable set than a single lookup, because each hop lands on a new object with its own surface. If a dotted path really is the feature, resolve each segment against a per-level allowlist rather than validating the whole string once.