the policy that arrives in stages, and the runtime it broke

A browser security policy is easy to write and expensive to switch on. Every directive that closes a hole is also a promise that the application already behaves well, and this application was written before anyone made that promise.

The work started as a specification rather than a deployment: which headers belong at the edge and which belong in the application, and a content policy derived from what the running product actually loaded — its fonts, its images, its own assets. The shared template defaulted the whole feature off, so a module could not silently impose it on a deployment that had not asked for it.

Rollout was deliberately staged. The policy was attached to the non-production surface first and production was left untouched; a transport-security commitment was given a ramp of increasing lifetimes rather than a leap to a long one, because browsers remember such a commitment and withdrawing it early is not possible. A rollback matrix sat next to the attach steps, and the ordering was explicit: edge first, application second.

Then live verification found the cost. The strict script policy forbade the mechanism the compiled browser runtime falls back on while loading, and the page failed hard on both desktop and mobile. The policy was correct and the application had quietly been relying on the exception.

What it proves: posture was rolled out as a staged change with a way back, and its first real defect was found by exercising the live surface rather than by trusting the directive list.