The security fixes I deliberately did NOT ship
Restraint is a senior skill nobody blogs about. Three hardening ideas that were correct in theory and would have broken production.
A good security review produces a list of things you could do. A good engineer then crosses half of them out. Here are three fixes I researched, wrote up, and chose not to ship.
Require a token where there is no browser
Adding a CAPTCHA token to a server-rendered search endpoint would have hardened it against scraping and broken search for every real user at the same time. There is no browser on that path to solve the challenge.
Bind the CDN token to client IP
Pinning signed media URLs to the requester’s IP sounds airtight. It also breaks IPv6 and mobile users, whose addresses shift mid-session. The fix would have generated a support queue longer than the abuse it prevented.
Relocate a database extension
Moving a Postgres extension to a tidier schema is the kind of cleanup that feels responsible and can break everything referencing its types.
Knowing what not to touch in production is the whole job on the days it matters.