Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A feature flag can decide whether a feature is shown or rolled out; it cannot, by itself, decide whether a user is allowed to use it. Every protected operation still needs an authorization check at a trusted enforcement point—regardless of what the interface displays or what flag value a client can change.
What a feature flag does—and what authorization does
A feature flag controls functionality exposure: it can enable a feature for a subset of users, support a gradual rollout, or switch a code path on or off. Authorization answers a different question: may this particular subject perform this operation on this resource? A flag can affect presentation or behavior, but it is not proof of permission.
The distinction matters whenever a protected action can be reached outside the interface. Hiding a button does not prevent a direct API request, and changing a client-side flag does not establish that the request is authorized. OWASP’s feature-flag security testing guidance recommends testing the operation behind the flag, not just the visible control.
Free tools Windows power users keep installed
One-click scans. No signup required.
Where the authorization decision belongs
Authorization must be enforced where the application can make a trusted decision about the requested operation. OWASP ASVS 5.0 control 8.3.1 says: “Verify that the application enforces authorization rules at a trusted service layer and doesn’t rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.” See OWASP ASVS 5.0, V8 Authorization.
#1 Best Overall
In practice, that usually means checking permission in the server-side handler or service that performs the action, rather than relying on a browser state, hidden control, or configuration value exposed to the user. The rule should reflect the protected function and data. Depending on the system, it may evaluate the subject’s permissions, the requested operation, attributes of the resource, and relevant context. NIST SP 800-205 describes access-control decisions based on attributes of the subject, object, operation, and sometimes the environment; it was published June 18, 2019. See NIST SP 800-205.
How to test that a flag is not acting as the permission check
- Inventory security-relevant flags. Include configuration that affects authentication, multifactor authentication, authorization, fraud controls, rate limits, account recovery, administrative actions, or security monitoring. Finding a flag is an inventory task, not evidence that it provides access control.
- Find the operation behind each flag. Identify the API endpoint, service call, message handler, or other execution path that actually performs the protected action.
- Call the operation as an unauthorized identity. Test it with the feature both enabled and disabled. The unauthorized request must remain denied independently of rollout state; OWASP cites HTTP 401 or 403 as examples of denial responses.
- Try client-side manipulation. Change any client-visible flag or interface state and repeat the request. The result should still be determined by authorization at the trusted enforcement layer.
- Compare paths and deployment states. Test black-box behavior and, where available, inspect flag evaluation and configuration visibility. Compare responses across rollout states, services, and instances, including rollback conditions.
OWASP’s testing guidance is useful for identifying bypass cases; authorization requirements should also be checked against the trusted-layer controls in ASVS V8.
Failure modes to account for
- UI-only protection: The interface hides a control, but a user can invoke the underlying endpoint directly.
- Client-controlled state: A user changes a flag or configuration value in the client and reaches a code path that should require permission.
- Inconsistent rollout state: Services or instances disagree about a flag, leaving an access path that behaves differently from the rest of the application.
- Rollback mismatch: A code rollback restores a path that expects security configuration no longer present, or configuration and code versions no longer agree.
- Exposed targeting configuration: Client-visible settings reveal more rollout or targeting information than the current user and context require.
- Stale gated paths: Old flag checks or alternate paths remain after rollout and create overlooked routes to the operation.
Document fail-safe behavior for flag-service outages, coordinate feature configuration with releases and rollbacks, limit client exposure to the configuration needed for the current context, and remove stale flags and gated paths after rollout.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Apply authorization across every route to the same capability
A permission check on one screen or API is not enough if another route reaches the same business operation. Align checks across websites, APIs, business-logic layers, and any other path that can perform the action. OWASP distinguishes authentication from authorization and recommends applying access controls consistently across an application’s access paths; see OWASP C1: Implement Access Control and the OWASP Developer Guide’s access-control guidance.
For a private operation, default to denying access unless the request is explicitly permitted. A feature flag may decide who sees or receives a rollout, but the authorization policy must independently decide who can execute the protected operation.
Quick Recap
Best Value
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.
