When resetting the password, we opened the developer console and found both the old and new passwords in plain text. Is this a security concern? Attached is the image for reference.
I see that the PUT request is sent over HTTPS (the lock icon is partially visible right next to your masking of the URL). So no, from what we can see in the screenshot there’s no security concern - no third party would be able to read the API request in transit.
We don’t know anything about the authentication and authorisation of the API itself, of course, but that’s a different problem than what you’re asking about.
2 Likes
Couple unrelated concerns though:
Why is the API returning a 400? Is there some meaningful reason in the response body?
Why is the API sending both Password and retypePassword in the JSON body? The validation that they match would be IMHO better done on the frontend as the user is typing - before the request is sent. Doing the validation on backend is much slower → worse UX.
2 Likes
Okay, noted. If we have someone’s username and we ensure that it cannot be changed by modifying this call, our API authentication and authorization should work fine. Is that correct?
If you have someone’s username and you ensure that it cannot be changed by modifying this call, then you know that the username cannot be changed by modifying this call. That fact by itself doesn’t say almost anything about your API authentication and authorisation.
1 Like
FYI, the dev console (network inspector and dev/javascript console) generally is not a good way to validate security of data in browser and network/API calls.
It’s named dev console for a reason, and gives you a dev view into the browser state and data, providing data as unecrypted before it is sent over the network.
If you wanted to verify state of what is sent over the network, you are better off checking the data by sniffing the network (Wireshark), or routing the browser traffic over a proxy, and checking the data at the proxy side (without enabling the man in the middle decoding of encrypted data at the proxy).
I could capture the request between browser and the server . It had the password as plan text , What do you think about this ?
Still alright 
The request is sent over HTTPS. Your proxy is able to decrypt HTTPS traffic from your browser only because you have the proxy’s CA certificate set up and trusted by your browser. That wouldn’t be the case for a proxy anywhere else in the way between your computer and the server. A “man in the middle” would be able to see that there is a request but not view its contents.
That’s why David specified that you need to view the traffic while having the decryption disabled. Right now you have it enabled. TBH I have no idea where the setting lives in Burp. But as long as the request is sent over HTTPS you’re good - this is exactly what HTTPS is for and why you don’t send sensitive data over plain HTTP.
1 Like
Thank you very much for your clarification
This is kind of a “meta” response. As testers, I would suggest it’s much better to frame a question as “what risks/concerns could approach X have?” rather than “is approach X free of concerns?”
It’s a subtle distinction but important, because we fundamentally can’t prove that concerns or bugs don’t exist, we can only prove or demonstrate that they do exist (a famous computing pioneer named Dijkstra articulated this more succinctly).
1 Like