During a private bug bounty engagement, I came across an admin portal that blocked unauthorized users with a JSON response from the server:

json

None
{"success":false,"errMsg":"User not Authorised"}

The frontend read that response and turned you away.

Here's the problem: the server was telling the client to make the decision. And clients can be lied to.

The Bug

When I saw that JSON response, I immediately recognized the pattern. The server wasn't enforcing the restriction itself — it was just sending a flag, and trusting the browser to act on it.

That's not how authorization should work. The server should refuse to serve the data. Instead, it was saying "hey, the answer is no" — and the page was listening.

What happens if the page hears "yes" instead?

The Exploit

I opened Burp Suite, went to Proxy → Match and Replace, and added one rule:

  • Match: {"success":false,"errMsg":"User not Authorised"}
  • Replace: {"success":true}
None

That's it. One rule. No credentials. No token stealing. No session hijacking.

With the rule enabled, I reloaded the admin page. Burp silently swapped the response on every request. The frontend saw success: true, concluded I was authorized, and opened the admin panel wide open.

None

Admin data — orders, users, the works — was now fully accessible.

Why This Happens

Client-side authorization is a pattern that feels secure but isn't. The flow looks like this:

  1. User requests the admin page
  2. Server checks something and responds with a flag
  3. Frontend reads the flag and decides whether to show the content

The fatal flaw is step 3. The frontend is running on the attacker's machine. They can intercept, modify, or replay any response before the page ever sees it.

Real authorization lives on the server. Every sensitive endpoint should independently verify: does this session actually have permission to access this resource? If the answer is no, the server returns nothing — no data, no JSON flag, just a 401 or 403.

Trusting the client to make that call is like putting a lock on the inside of a window and telling burglars it's secured.

Impact

With this bypass, any attacker could:

  • Access the full admin panel with zero credentials
  • View sensitive order and user data
  • Potentially modify or delete records
  • Do all of this repeatedly and automatically, since the Burp rule fires on every single request

The persistent nature is what makes this especially serious. This isn't a one-time trick — it's a reliable, repeatable backdoor into the admin interface.

The Lesson

Whenever you see a JSON response controlling access — success: true/false, isAdmin: true/false, authorized: true/false — always ask: what happens if I flip that?

Match and Replace in Burp makes this test trivially easy. Add the rule, reload the page, see what the frontend does when it thinks you're allowed in.

If the answer is "it lets me in", you've found a client-side authorization bypass. The server handed the keys to the browser, and the browser believed whatever you told it.

This class of vulnerability is simple to find, simple to explain, and surprisingly common. It's one of the first things I look for when testing any authenticated portal.

HackerOne: @iamabdelaal