A per-request flag override lets a tester turn a flag on through a cookie, query parameter or header, without affecting other users. It is handy in production. It also lets any curious user try the same trick unless you require proof of who is asking. Allow overrides only for authenticated internal users.
How overrides work
Martin Fowler's article on feature toggles describes the pattern: a flag's on or off state can be overridden per request by a special cookie, query parameter or HTTP header. It lists benefits over changing the environment configuration. Behind a load balancer the override applies whichever instance you hit. You can override in production without affecting other users. And you are less likely to leave an override in place by accident.
With persistent cookies, a tester can keep a personal set of overrides in their browser.
The downside, in the source's words
The same article names the risk: curious or malicious end users may modify feature flag state themselves. It notes some organizations are uncomfortable with unreleased features being reachable by a determined member of the public.
That discomfort is justified. An unreleased feature may skip review of a permission check, expose an unfinished API, or carry a half-built payment flow.
Rules to keep the benefit
Require authentication first. Honor the override only when the request is from a signed-in employee or from a network you control. An anonymous cookie that flips a flag is a feature that is public in practice.
Sign the override. If the override travels in a cookie, make it a signed token that includes the flags allowed and an expiry. A plain flag name in a cookie is easy to guess.
Limit which flags can be overridden. Mark flags as overridable in their definition, and refuse overrides for permission, billing and security flags.
Log every honored override with the user and the flag. Quiet use of overrides is hard to audit later.
Expire them. A tester's override should end after hours, not live forever in a browser.
Test the negative case
Add one automated test: an anonymous request with an override cookie must receive the default behavior. Add a second test where a signed but expired token is refused. These two tests are small and catch the common mistakes.
Where to avoid overrides entirely
Do not allow overrides on flags that gate access to data, change who can approve actions or switch off a security control. For those, the cost of a bypass is higher than the benefit of easier testing. Test them in staging with real configuration changes instead.
A worked example
A team wants testers to try a new checkout in production. They add an override header, honored only when the request carries a valid employee session and a signed token naming the checkout flag, valid for four hours. Anonymous visitors who send the header see the old checkout. Every honored override writes a log line with the employee ID. After four hours the tester must request a new token.
The team keeps the benefit the source describes, testing in production without touching other users, and removes most of the risk it names.
Related reading
For the broader question of who can change flag state at all, see who can change a flag and how to record it.
Quick check
Is a header-based flag override safe in production?
Only if the header is honored for authenticated internal users, ideally as a signed token. Otherwise any user can try it.
Which flags should never be overridable per request?
Flags that gate data access, billing, approvals or security controls. Test those in staging with real config changes.
Sources
Last reviewed: 19 October 2026.
