While intercepting HTTPS using Burp and Burp's certificate is added to the browser, I intercepted a login request and the password shows as plaintext. Does this indicate a vulnerability or is it the expected behavior?


1 Answer 1


It's not a vulnerability.

Since the page transmits the password via HTTPS, it's encrypted before being sent on the network.

You allowed Burp to decrypt any encrypted traffic by adding their certificate into your trusted certificates store: that's the only reason why Burp is able to perform a man-in-the-middle attack and see the password in plaintext format.

Anyone else will only see encrypted traffic, and won't even be able to tell if a password is being transmitted.

  • If user will use public network which monitored by proxy, then? Commented May 18, 2017 at 8:19
  • 2
    @BugTechies the user will get one of those big red screens in their browser stating that their connection isn't secure, you told your computer to trust the proxy you're using to be 100% safe by installing the certificate
    – Paradoxis
    Commented May 18, 2017 at 8:33
  • But what if they're using webviews like through an app? There wouldn't be a red screen or anything to notify the user. @Paradoxis
    – isopach
    Commented Feb 10, 2018 at 13:52
  • 2
    @Yuu if apps are properly designed, they will let the user know they can't fetch the resource due to the fact that the underlying libraries can't verify the SSL certificate (or output some other generic error). If poorly designed they will downright crash (unless some idiot turned off certificate checking, which is a vulnerability in it of itself).
    – Paradoxis
    Commented Feb 10, 2018 at 14:05

You must log in to answer this question.

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