Dozens of services each carry their own CORS allow-list, edited by whoever last needed a partner unblocked. How would you make that grant surface governable?

## The failure is organisational, not syntactic Each individual allow-list in this estate may be written correctly. The problem is the shape of the whole: the set of origins that may read the organisation's data is spread across dozens of independently edited values, each added under time pressure by whoever was unblocking a partner that week, with no record of why and no date it stops being true. The symptoms of that shape are recognisable: - Nobody can answer **who may read our data today** without reading dozens of files, and the answer changes between reading and deploying. - Entries survive the relationship that created them; the partner left, the grant did not. - Each team meets the same problem independently and solves it differently, so the estate contains an exact comparison here, a suffix test there, and an echo in the service that was hardest to onboard. - Widening is invisible. Making a pattern looser is a smaller-looking change than adding a name, so review pressure runs in exactly the wrong direction. ## Making the allowed set data The move is to stop treating the grant as behaviour and start treating it as a record. Each entry should carry: 1. **The resource it grants**, not merely the service — a public schedule endpoint and an attendee-records endpoint are different decisions and should not share a value. 2. **The origin**, written in full as it appears on the wire. 3. **An owner** — a team that will be asked about it, not the person who typed it. 4. **A reason**, in a sentence, so the next reader can judge whether it still holds. 5. **An expiry**, so the entry lapses unless somebody renews it. Default to removal; entries that matter get renewed and the rest disappear without an audit. Services then **consume** the list and select from it per request. This matters more than it looks: the pressure that produces reflection is a team being asked to grant an origin they cannot know at build time. If the list is data they load rather than code they edit, the per-request selection stays a selection. ## Proving it, rather than reviewing it Configuration review cannot establish that no service reflects, because reflection is often not in any configuration — it is a line in request handling, or an inherited default in a middleware layer nobody has looked at. The check that works is behavioural: - Send a request carrying an origin nobody has ever registered, at every route in the estate, and read the grant that comes back. - Flag anything that **echoes** the value sent, anything that answers the wildcard on a route that is not reachable anonymously from outside, and anything granting the literal token that names a class rather than a party. - Run it continuously rather than at release, because the change that introduces it is usually an urgent one made outside the normal path. This also gives the inventory the list alone cannot: the difference between what was declared and what the estate actually does. ## What the central artifact costs Be honest about the tradeoff, because it is the part an interviewer is listening for: | The cost | What it looks like | What blunts it | |---|---|---| | Bottleneck | Every partner onboarding waits on one reviewer | Delegate by resource class; only sensitive resources need the slow path | | Rot | The list drifts from what services do | Keep it beside the services and verify behaviourally | | False centralisation | Teams route around a list that does not fit their case | Allow per-resource entries rather than one estate-wide value | | Blast radius | One wrong edit widens many services at once | Scope entries to resources, and make review proportional to what the resource returns | ## What to decide per resource The governing question is not how many origins are allowed but **what each one can read**. A grant on an endpoint returning a public schedule is cheap at any width; a grant on an endpoint returning attendee records is expensive at width one. Classifying resources by what they return is what lets the slow review path apply to the few endpoints that deserve it, and it is the difference between a policy that holds and one that teams quietly work around.