Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11A feature flag is a runtime switch that selects which behavior an application runs. It can let a team deploy a feature but enable it only for employees, beta users, or a gradual rollout. A flag can control what appears in an interface; it does not, by itself, stop an unauthorized person from calling the feature’s underlying API. The server must still enforce authentication and authorization.
How a feature flag works
Application code checks a flag and follows the behavior associated with its current value. A simple flag may be on or off; others can select among multiple variations. Teams configure flags by environment and can use targeting rules or percentage rollouts to decide which users or contexts receive each variation. LaunchDarkly describes these capabilities in its Feature Flags API documentation.
As an Amazon Associate I earn from qualifying purchases.
Because the decision can be made while the application is running, a team can deploy code before making its feature generally available. The code may already be present, while the flag determines whether a particular user sees or uses the new behavior.
Recommended Free Tools
How flags expose an internal feature
Teams often target an early feature to employee accounts or a beta group. Martin Fowler describes this as a permissioning toggle: access is granted to a specific cohort, rather than to a randomly selected canary group. That can be useful for internal testing, but the targeting rule is a rollout mechanism—not proof that a user is authorized to perform a sensitive operation. See Fowler’s Feature Toggles (aka Feature Flags).
#1 Best Overall
The security problem arises when a flag gates only the visible entry point. Hiding a button, page, or menu item does not necessarily protect a direct URL or the API behind it. A caller might reach that functionality by changing a client-visible value or making the request directly. Whether this becomes a security issue depends on whether the backend independently checks the caller’s identity and permissions. OWASP recommends testing for client-side manipulation and verifying that backend controls remain enforced.
What to test before relying on a flag
OWASP’s Web Security Testing Guide calls this “Feature Flag Security Bypass.” Its testing objective is to determine whether an unauthorized client can manipulate flag states and whether backend security controls remain enforced regardless of client-side flag state. Perform these checks only on systems you own or are authorized to assess.
- Try the underlying operation directly. With an authorized test account, replay the relevant request or visit a direct URL while the feature is disabled for that account. Confirm that the server checks authentication and authorization rather than trusting the interface’s flag state.
- Change client-visible values. Where the flag is available in the browser, test whether changing it alters only presentation or also grants an operation the account is not permitted to perform.
- Inspect client data. Review shipped JavaScript and network responses for flag keys, targeting rules, defaults, or unrelated configuration data that should not be exposed to that client.
- Compare rollout states. Check behavior across the intended cohorts and rollout stages, including what happens when a user’s eligibility changes.
- Test transitions and failures. Exercise rollbacks, stale sessions or assertions, service outages, and unavailable flag services. Verify that a transition or failure does not bypass the backend’s security checks.
OWASP’s guidance identifies these as testing concerns; their presence is not evidence that any particular flag platform or application is vulnerable.
Use the right kind of flag—and plan its lifetime
Flags serve different purposes, so they differ in who controls or evaluates them, how long they should remain, and what can happen if their state is wrong. LaunchDarkly’s guide recommends keeping a flag’s scope small and removing temporary flags when their purpose is complete.
| Flag category | Typical purpose | Lifetime guidance | Security consideration |
|---|---|---|---|
| Release | Gradually expose a new feature | Temporary; remove after full rollout | Do not treat rollout eligibility as authorization for sensitive operations. |
| Experiment | Compare variations or test a hypothesis | Temporary; remove when the experiment ends | Keep experimental presentation decisions separate from access checks. |
| Migration | Shift traffic or behavior between systems | Temporary; remove after migration | Test transitions so inconsistent flag states do not weaken backend controls. |
| Kill switch or operational | Disable or degrade a feature during an incident or load | Often long-lived, with clear ownership | Define and test its behavior during failure and rollback. |
| Entitlement or permissioning | Make a capability available to eligible accounts or internal/beta users | May be long-lived | Eligibility in a flag is not a substitute for server-side authorization. |
These categories and lifecycle recommendations are described in LaunchDarkly’s official flag-creation guide. A long-lived flag still needs an owner and a clearly defined purpose; a temporary release, experiment, or migration flag should not become permanent by accident.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Keep flag state separate from security policy
For authentication, multifactor authentication, authorization, fraud checks, rate limits, account recovery, administration, and security monitoring, inventory any flags that affect the relevant behavior. Decide explicitly what should happen if the flag is misconfigured, stale, unavailable, or inconsistent across services. The backend should make the authoritative access decision for each sensitive operation; a client-side flag should control presentation or rollout, not serve as permission proof.
Flag-management guidance also emphasizes lifecycle discipline: give each flag a limited purpose, record its owner and intended lifetime, and remove temporary flags when the associated work ends. That reduces the chance that forgotten or conflicting conditions will influence behavior long after a rollout or migration is complete. LaunchDarkly’s guide to creating flags covers flag scope and lifecycle considerations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
