10

I am writing a User Management system that has to include a change of password utility. We don't front end hash passwords (hopefully we will soon). As a result passwords are passed over https in the clear whenever a user is edited or his password is changed. Is there any difference in using "PUT" vs. "POST" requests in this use case. I would typically use "PUT" because it is a replacement/edit but I know for authentication the standard is "POST"

6
  • 1
    "Over https in the clear" sounds paradoxical :)
    – Jack
    Jul 22, 2014 at 11:00
  • @Jack I am new to security but I thought in the clear referred to unhashed Jul 22, 2014 at 13:19
  • @Jack, Depends on the location of the man-in-the-middle he can mitm certain requests/responses send over https in the clear.
    – Pacerier
    Dec 11, 2014 at 9:08
  • @Pacerier I don't see how that's at all relevant.
    – Jack
    Dec 11, 2014 at 10:24
  • @Jack, Well you stated "Over https in the clear" sounds paradoxical, so I stated that it isn't.
    – Pacerier
    Dec 12, 2014 at 2:42

1 Answer 1

14

The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that respect, PUT and GET mimic the expected behaviour of FTP.

On the other hand, a "POST" is the generic verb for API-like calls: orders sent to a server for immediate execution. Such API calls are not idempotent. A "change password" call should probably be envisioned as an API call, not a file transfer. Therefore, you should use POST instead of PUT.

See for instance this blog post for further discussion about PUT vs POST.


From a security point of view, there is no real difference between PUT and POST: everything goes through the SSL, and it is mostly a matter of convention between client and server. As long as the client and server understand each other, then the security offered by both requests is the same.

The theoretical difference is that a client might take upon itself to issue a PUT call again in case of network failure, while it would not for a POST. Generally, you prefer the POST semantics, and keep PUT only for bulk file transfer where such reemission would be a nice feature, and not a problem.

4
  • So you are saying that the safest method of HTTP transport is via POST among all the possible methods? What about PATCH ?
    – Pacerier
    Dec 11, 2014 at 9:10
  • Thank you @Tom Leek. Superb Description. Facing same issue but you are the Hero.
    – Mihir Oza
    Apr 26, 2016 at 12:00
  • @Tom Leek what is your answer to Pacerier question?
    – JonyD
    Feb 19, 2019 at 15:22
  • some password policies don't allow to set the same password twice. so in a put scenario a second call might result in an error, which is not real idempotent and could cause unwanted effects.
    – snap
    Jul 16, 2020 at 9:34

You must log in to answer this question.

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