Should the HTTP status code for password validation failure be 400?

Question

I have an API endpoint that checks if a password is valid based on a predefined set of password policy rules. When the password conforms to the policy, the endpoint returns 200; otherwise it should return something else.

I'm wondering if returning 400 would be appropriate, because the request which contains a bad password isn't a bad request per se. The server understands the request perfectly well, and a bad password is totally anticipated, just like a good one; it's just that we need to tell the client the password isn't good to be used for creating account or changing password.

Is there any HTTP status that is meant for this purpose? Or should both good and bad password be responded with 200 but the details should be in the response body, e.g. {"validPassword": true}, or {"validPassword": false, "reason": "too long"}?

NOTE: This question is not about invalid data for a request. This is about calling an API that's specifically designed to check if a password is of valid format. An invalid password is still valid data for the request. Please do not suggest the other question about "invalid request".

Does this answer your question? [REST response code for invalid data](https://stackoverflow.com/questions/6123425/rest-response-code-for-invalid-data) — D M, Mar 03 '21 at 14:48
From the dupe target I linked, you should respond with `400` and change the reason phrase or include any error details in the body. — D M, Mar 03 '21 at 14:49

VoiceOfUnreason · Answer 1 · 2021-03-03T16:41:00.567

HTTP status codes belong to the transfer of documents over a network domain, not to the domain the documents are about.

For example, if I have a document that describes whether the password "walrus" complies with some policy, I might try to retrieve that document with a request like

GET /policy?password=walrus

The document returned to me might be an explanation that the "walrus" is compliant with the policy, or it might be a list of policy violations. But in the transfer of documents domain, the response to the query is a current representation of the document, and therefore the appropriate status code is 200.

400 would NOT be appropriate, because that code indicates that (a) the message body of the response is a representation of an explanation of an error (rather than being a copy of the document we asked for) and (b) more precisely indicates that the request was improperly formed.

More generally, a successfully retrieved document that explains that you are not on your domain's happy path is still a successfully retrieved document, and should get a 2xx status code, just the same as if you were simply downloading a web page about that password from a website.

There are more possibilities when you are sending changes to the server, rather than fetching information from it.

POST /e363c9c3-03a9-43fa-9e1c-fe5cad95fb04 HTTP/x.y
Content-Type: application/x-www-form-urlencoded

action=changePassword&password=walrus

Here, it is perfectly reasonable to report a client error, on the grounds that the payload is supposed to be a changePassword message, and "walrus" is semantically nonsense as a value in the message because it violates policy. So 422 Unprocessable Entity might be an option, or 409 Conflict, or 403 Forbidden -- all valid ways of announcing to the transfer of documents over a network domain that the request is unsatisfactory.

Imagine a puzzle game, like mastermind, where the player tries to solve the puzzle. Such a request might look like

POST /puzzles/59bfc5a5-8e5b-4bf9-b6fd-52c7b3634b3c HTTP/x.y
Content-Type: application/x-www-form-urlencoded

guess=red,blue,blue,white

Even when this guess is "wrong", it's still a valid request within the game domain; the game itself updates, the player gets hints, a row of the decoding board is consumed, and so on. A 2xx success code is still appropriate even though the player didn't win the game.

POST /puzzles/59bfc5a5-8e5b-4bf9-b6fd-52c7b3634b3c HTTP/x.y
Content-Type: application/x-www-form-urlencoded

guess=red,blue,blue,walrus

Here, we'd return a 422, because the request itself is broken (walrus is "semantically erroneous" in this context).

Should the HTTP status code for password validation failure be 400?

1 Answers1