Home / Knowledge hub / Feature flag security
Knowledge hub
Feature flag security
Making sure switches that turn features on or off cannot be flipped by outsiders.
What it means
A feature flag is a switch that turns a feature on or off without a new release. Feature flag security is the work of making sure those switches cannot be read, changed or trusted by the wrong people, and that a flag never stands in for a real permission check.
Flags are used for gradual rollouts, paid tiers, internal testing and quick shutdowns. That makes them powerful. Whoever controls a flag can change what the product does for thousands of customers, so the flag system deserves the same care as any other admin tool.
Why it matters
The common failure is treating a flag as an access rule. A paid feature is hidden in the interface, but the server behind it still answers anyone who calls it directly. A customer on a free plan can then use it, because the check lived in the front end only.
The other failure is the management side. If an attacker or a careless employee can change a flag, they can switch off a security control, open a hidden admin page or enable a half-built feature that was never tested. That is a quick route to an outage or a data leak.
How it shows up
You meet it in client-side flags delivered to the browser, which any visitor can read, and in flag dashboards with broad access. Old flags are another source: a switch for a retired feature stays in the code, and later someone turns it on without remembering what it unlocks.
Keep sensitive decisions on the server, and enforce server-side authorisation whatever the flag says. Protect the dashboard with multi-factor sign-in and an audit trail. Give client keys no more than they need, and remove flags once a rollout ends. Test with a direct request.
Questions people ask
Feature flag security, answered
Is a feature flag a security control?
No. A flag decides whether a feature is offered, not whether a particular person may use it. Always enforce permissions on the server, as if the flag did not exist.
Can users see our feature flags?
If flags are sent to the browser, yes. Anyone can read them in the page data or network traffic. Do not put secrets or sensitive rules in a client-side flag, and assume users can see its name and value.
What is the risk of old feature flags?
Dead flags guard code that nobody maintains. If someone turns one on, a forgotten and untested path goes live. Remove flags when the rollout is done, and review the list regularly.
Who should be allowed to change a flag?
A small group, with sign-in protected by a second factor, and every change recorded in a log. Treat flag changes in production like deployments, because they can have the same effect.
How do we test that a flag cannot be bypassed?
Turn the flag off, then call the feature's endpoint directly with an account that should not have it. If the server answers, the flag was only hiding a button and the access check is missing.
Sources
Where this comes from
Related
Terms that sit next to this one
Server-side authorisation
Enforcing permissions on the server, because hiding a button in the page protects nothing.
Broken access control
An application failing to enforce its own rules about who may do what.
Missing function-level access control
A sensitive action that checks you are signed in but not whether you may use it.
Forced browsing
Typing the address of a page you were never linked to and finding it opens.
Admin panel exposure
A management page left reachable by the public or by ordinary accounts.
What if the switch is bypassed?
Hidden features that the server still answers are a classic access flaw. We check cross-account access and business-logic gaps in the running app, and show the exact request that proves them. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.