What you can detect
This workflow can detect whether a page depends on a third-party flag vendor, whether hidden modules appear only for certain users or routes, whether rollout logic hints at undocumented service relationships, and whether browser-visible experiment context changes the way you should prioritize security review. It is especially useful when a frontend looks simple on the surface but behaves like a shell for many conditional services underneath.
Signals to look for
- Flag payload sources: requests to known experimentation vendors or internal endpoints that clearly return feature state.
- Capability-shaped names: flags referencing billing, AI, moderation, exports, uploads, admin surfaces, or other meaningful modules.
- Session-sensitive changes: flag state shifts after login, route changes, workspace changes, or one specific product action.
- Context fields: tenant, region, plan, role, org, environment, or cohort values that explain why behavior differs.
- Cross-evidence alignment: the flag clues line up with matching scripts, requests, or asset families elsewhere in the browser.
How to verify
1. Find the source of truth for flag state
Some sites fetch flags from a vendor endpoint. Others inline them in a bootstrap payload. Start there. Until you know the source, it is easy to mistake generic frontend config for meaningful feature state.
2. Capture a baseline session
Record the exact state before interacting: logged out or logged in, route, workspace, locale, and visible product context. Feature flags make more sense when they are tied to one clear session shape rather than vague browsing notes.
3. Change one variable at a time
Login, switch route, trigger one product action, or move between user states one step at a time. If the flag payload changes, ask what dependency story that change suggests. A controlled comparison beats a noisy capture every time.
4. Connect flag clues to runtime behavior
Flag review gets much stronger when a capability hint matches a loaded script, endpoint family, or request pattern. A name by itself may be interesting. A name plus matching runtime evidence is usually actionable.
Common false positives
- Legacy experiment residue: old flag names can survive long after a feature was retired.
- Generic labels: names like
variant_aortest_togglerarely mean much alone. - UI-only experiments: a visible experiment can change presentation without changing backend trust boundaries.
- Staging-like vocabulary: environment-looking names may reveal process detail without confirming active exposure.
Limits and what this does not prove
Feature flag review does not prove a vulnerability, unauthorized access, or exploitability. It does not prove that a hidden module is reachable in the current session, or that a service named in the flag system is exposed in a meaningful way. Treat the output as architecture evidence and dependency mapping, not automatic proof of risk.
When to escalate
- A flag payload reveals a hidden service or capability that materially changes the app's trust model.
- Flag state changes are clearly tied to sensitive flows like billing, uploads, AI requests, moderation, or exports.
- The same hidden dependency appears in both flag data and runtime network behavior.
- The browser is receiving richer internal context than expected for that surface, even if impact remains unproven.
Methodology + last reviewed
This article is based on browser-visible evidence only: feature flag payloads, initialization context, downstream requests, and loaded assets observed during normal browsing. It keeps architecture clues separate from vulnerability claims. Last reviewed: 2026-04-06.
Use Source Detector to connect feature flag clues with the rest of the frontend evidence
Source Detector helps you inspect source maps, client-side assets, and suspicious browser behavior in one place, so hidden-dependency review stays grounded in evidence instead of guesswork.
FAQs
Why review feature flags during browser recon?
Because they often reveal hidden modules, vendors, rollout logic, and environment context that the visible UI does not explain.
Does a flag payload mean I found a security issue?
No. It usually means you found useful architecture evidence that may justify deeper review.
What makes a flag clue stronger?
It gets stronger when the flag data lines up with loaded scripts, request families, or a sensitive product flow.