I have created an authentication API to manage user sessions and the works. To log a user in, the user send their credentials to my API endpoint and it returns “true” or “false” based on their login. I recently received an issue report stating that using “a burp and intercept”, the response of “false” can be changed to “true”, bypassing a failed login attempt and tricking the browser into thinking the user is logged in.

I’ll be honest: I have no clue how to prevent this. And if I cannot prevent it, is there a better way to be authenticating users?

  • Will they be able to access confidential information afterwards?
    – Arminius
    Dec 16, 2017 at 20:09
  • 4
    It should not matter what the browser thinks. On successful login, you should return a token to the browser to be presented on further requests (usually stored in cookies). If the login fails, you do not return a token and the browser will get a 401 from the server. You may want to read up on web api authentication.
    – Marc
    Dec 16, 2017 at 20:09

2 Answers 2


You may want to ask the reporter to explain what they think the security implications are.

Tricking the browser into showing a successful login via a locally forged API response does no harm unless the user can use that to actually bypass authentication or access confidential information. An attack would have to trick the server into assuming the authentication succeeded, not the client.

I have no clue how to prevent this.

You can't prevent a user from tampering with data which has left your server. You have no control over the client (their browser) and can't stop them from using Burp (or the developer console for that matter) to rewrite requests and responses in ways that you web application didn't intend.

And if I cannot prevent it, is there a better way to be authenticating users?

As Marc outlined, one possible approach is to have the API endpoint return a session token once the authentication succeeds. The client would then use this token to make further authenticated requests.


Security Researcher 'Joel Aviad Ossi' from https://websec.nl has shared a code that does exactly this on his github:


  • interesting. One way to defeat BurpBuster, then, is to add a match and Replace rule to mess up that javascript code.... I added a Match and Replace for the Response body that replaced isLoaded == true with 0 == 1 and BurpBuster stopped working
    – mcgyver5
    Oct 14, 2021 at 2:12
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Oct 14, 2021 at 9:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .