A feature flag can hide a new export button from most users. That is useful for a gradual release, but it does not prove that the export endpoint rejects users who lack permission.
Rollout and authorisation answer different questions. Rollout asks whether a feature should be available to a selected audience or environment. Authorisation asks whether this authenticated actor may perform this action on this resource now.
The OWASP Authorisation Cheat Sheet recommends denying access by default and validating permissions on every request. Apply that principle at the server boundary, even when the interface already hides the relevant control.
Trace one action from button to data
Consider an internal report download. The page may check a rollout flag before showing its button. The server should independently check the user’s identity, organisation membership and permission to access the requested report. A caller should not gain access merely by knowing the route or changing a resource identifier.
Keep security decisions out of untrusted client-supplied flags. If a request says that a feature is enabled or that a user is an administrator, those claims need a trusted basis rather than being accepted as facts.
Test the combinations that matter
- Feature enabled, authorised user: expected access.
- Feature enabled, unauthorised user: denied access.
- Feature disabled: behaviour consistent with the rollout design.
- Missing or unavailable policy information: no accidental permission.
Run these checks in an authorised test environment, including direct requests that bypass the normal interface. Verify both the response and whether sensitive data or side effects occurred.
Document which system owns each decision. Removing an old feature flag after a successful rollout should not remove the permission check with it. That separation makes the release process easier to change while keeping the security rule understandable and testable.