Feature flags and hidden routes

Tags: misconfig, authz, flag

Level: intermediate

Method

1. Collect routes from the client

   JavaScript, feature-flag payloads, and source maps list routes the UI does not render for your role. Write them down. Do not treat the list as proof.

   Tools: browser

2. Call one route as your user

   Request a hidden route with the session you already have, against an object you own. A 200 with data the UI refused is the note.

   Tools: Burp Suite

3. Separate 404 from 403

   A missing route and a forbidden route are different. Record the status and whether the body still contains the object.

   Tools: Burp Suite

4. Flag in the client only

   If the flag lives in local config or a JSON blob the browser can edit, change it and see whether the server agrees. The server response is the result.

   Tools: Burp Suite

5. Admin and beta

   Beta, staff, and admin flags are different roles. Do not call a staff route you were not invited to. A route your own plan already pays for is the fair test.

   Tools: browser

6. Write the missing check

   The report should say which check was only in the UI, and what the API did instead.

   Tools: browser

Field notes

• Hidden URLs that 404 for everyone are not a finding.
• A flag that hides a dangerous button but leaves the API open is the usual shape.
• Do not flip flags on a shared production tenant.

References

• https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• https://owasp.org/Top10/2025/
• https://owasp.org/API-Security/