2

I'm thinking to create an API for users to change their password.
User table has some fields like firstname, lastname and so on. For this API, should I use PATCH like the below?

PATCH /users/{userId}

{
  "password": "new_password"
}

Or, should I use PUT?

PUT /users/{userId}/{password}

This seems awful for security.

By the way, I don't want users to change values of other fields. I think PATCH must let users to be able to change values of any fields. That's why I'm wondering.

Al Amin
  • 889
  • 7
  • 12
Nigiri
  • 3,469
  • 6
  • 29
  • 52

2 Answers2

4

Path info and query string will be encrypted using HTTPS/TLS - for that HTTP session. However, it is still a bad idea to put passwords there, since they are likely to be in browser history and/or server logs

PUT /users/{userId}/{password}

... that will stay in web server logs. As secure developers, we are not supposed to even store passwords in databases where they can be stolen (we are to store a hash + salt of a password). Having cleartext passwords in web server logs is worse.

Sending it in the body in a TLS session is the best. 

PATCH /users/{userId}
{
  "password": "new_password"
}

... and then hash+salt it and store that. Logins, you do the same process (one-way hashes match).

See this: HTTPS, URL path, and query string

Community
  • 1
  • 1
Raul Nohea Goodness
  • 2,549
  • 23
  • 24
1

From a security POV there is no difference. An attack can read both the query string and the request body. You should use TLS.

Both requests look fine to me. Their URLs and their bodies are good, solid REST.

If you don't want to accept changes to all fields, write logic in your server that rejects requests that trie to change fields that are not to be changed by the user. But this is not a question of PUT vs. PATCH or POST.