The Bug You’ll Never See — Until You Flip the Flag 👾
Recon didn’t show it. My scanner didn’t see it. Even my browser’s DevTools stayed quiet.
But that’s the thing about feature flags and role-based logic — they don’t break things openly. They bury them in layers of assumptions, behind toggles and A/B tests, waiting for someone curious (or lucky) enough to stumble onto them.
This is the story of how a single flipped flag revealed an entire vulnerable feature — one the developers assumed no regular user would ever find.
The Invisible Vulnerability 🚩
I was deep into a bug bounty target that looked clean on the surface. The recon phase was smooth. No exposed endpoints, nothing juicy in robots.txt, and all APIs responded as expected.
But then I noticed something odd in the JavaScript bundle — an unused component called AdminCommentEditor. There was no link to it in the UI. No menu. Nothing. But the code was there.
Even stranger, I saw a feature flag named enableNewCommentEditor being checked in multiple places.
That was the moment I paused.
Why would there be an entire editor hidden behind a flag?
Curiosity Unlocked the Bug 🔍
I started poking around the client-side storage — localStorage, sessionStorage, and cookies. Sure enough, there was a key:
“enableNewCommentEditor”: false
I changed it to true, refreshed the app, and boom — the hidden editor appeared.
And within minutes of playing with it, I found the jackpot: a stored XSS vulnerability. No input sanitization, no content filtering. Just raw HTML being rendered as-is.
Why? Because the devs thought “only internal testers will see this editor”. So they didn’t lock it down. No auth checks. No input validation. Just a UI behind a flag and a developer’s assumption.
The Psychology Behind Hidden Bugs 🧠
This bug wasn’t just technical — it was human.
Developers often think in terms of intended flows. They assume:
- “Only admins will ever hit this route.”
- “This feature is off, so we don’t need to secure it yet.”
- “It’s just a test. No harm.”
But the internet doesn’t care about intentions. If a feature is live in production — even if it’s hidden — it can be abused.
These bugs are the hardest to catch because your tools don’t see what the app doesn’t show you.
How You Can Find Hidden Bugs Too 🛠️
Here are some of the tactics I used (and you can use too):
- Switch roles — Log in as different user types and compare UI and network requests. Replay admin actions with a user token.
- Explore JS bundles — Parse and grep the JavaScript for feature names, internal routes, or debug-only logic.
- Check for flags — Look for localStorage, cookies, or JS variables like isFeatureXEnabled. Try flipping them.
- Force alternate flows — Use your proxy to hit API endpoints that aren’t linked in the UI. Sometimes the frontend hides them, but the backend is still listening.
- Spoof A/B tests — Some apps assign tests via headers or cookies. Change your variant and recheck behavior.
And don’t forget: time-based features can also hide bugs. I once found a bypass that only triggered after midnight because of an expiring flag. Always test edge conditions.
The Lesson: Recon Isn’t Enough 🎯
This bug didn’t show up in Burp’s sitemap. It wasn’t in the unauthenticated surface. It wasn’t even visible in the DOM unless the flag was flipped.
If I hadn’t stopped to read that JavaScript…
If I hadn’t been curious enough to toggle a single flag…
If I had trusted recon alone…
I would’ve missed it.
What’s Your Weirdest Hidden Bug? 💬
Have you ever caught a vulnerability that only appeared for a certain user role? Or maybe one that only existed after flipping a feature flag, changing time zones, or spoofing A/B variants?
Drop your strangest hidden bug stories in the comments👇
Let’s swap war stories. Someone else’s bug might just be your next bounty.
Thanks for reading — and until next time,
Happy Hunting 👾
—