Sitemap

The Bug You’ll Never See — Until You Flip the Flag 👾

3 min readJul 3, 2025

--

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):

  1. Switch roles — Log in as different user types and compare UI and network requests. Replay admin actions with a user token.
  2. Explore JS bundles — Parse and grep the JavaScript for feature names, internal routes, or debug-only logic.
  3. Check for flags — Look for localStorage, cookies, or JS variables like isFeatureXEnabled. Try flipping them.
  4. 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.
  5. 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 👾

--

--

Responses (1)