2

I read many posts about passing sensible data in a GET request but didn't find an answer that would suit my needs.

I have to expose a RESTful resource that will check the password strength.

GET http://api.domain.com/security/password/P@55w0rd

I find the GET HTTP verb suitable since I only want if the password is secure enough.

The problem is that the client will be forced to pass it in the resource (i.e. URL).

Some colleagues told me to use POST and then pass it in the data body but I'm not sure how RESTful is it.

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
Toto
  • 21
  • 2
  • You might want to consider using https as well as using POST otherwise you are potentially exposing the password for all to see – Dijkgraaf May 15 '17 at 08:12
  • 1
    Possible duplicate of [POST or GET for a validation of some data endpoint in REST?](http://stackoverflow.com/questions/41673005/post-or-get-for-a-validation-of-some-data-endpoint-in-rest) – Dijkgraaf May 15 '17 at 08:16
  • @Dijkgraaf Yes I'm exposing my resources through HTTPS. The problem is that our logaccess will log every requested URL. – Toto May 15 '17 at 08:18
  • @Dijkgraaf So it's ok to use the POST verb instead of GET ? How RESTful is it ? – Toto May 15 '17 at 08:22
  • Please, never ever send sensitive data within the URI itself. If so, use HTTP headers therefore. Especially the `Authorization` header is a very good one therefore. Whether the request succeeded or failed can be determined via the status code received. In regards to the actual HTTP operation to use, I'd opt for POST as responses to this are by default not cacheable and the intention is not to retrieve some status but just to verify whether the request worked or not – Roman Vottner Mar 15 '21 at 18:32

2 Answers2

3

The REST standard just says to use HTTP Verbs. It doesn't actually mandate that you use particular ones. However some conventions have arisen about which verb to use, POST to create & GET to retrieve data, however this should not be followed religiously if it will cause an issue.

As per the following article you should not use GET for password, and yes you can use POST or pass something in the HTTP headers instead.

REST Security Cheat Sheet

Session management RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
1

I went with this:

GET /api/public/check-password
Authorization: Basic <base64(test:<password>)>

The username must literally be either '' (empty string) or 'test'.

I chose to use

  • test because it's obviously not a real user
  • GET because no modifications are made
  • The Authorization header because the security middleware in (most?) application stacks already removes that from logging - so no special care is needed.
  • /api/public because it doesn't require authentication to do the check

I'm not in love with check-password - that sounds more RPC-ish than REST-ish... but what can you do? At least it's obvious. I'm open to other suggestions.

coolaj86
  • 74,004
  • 20
  • 105
  • 125