REST HTTP Response Code for Unauthorized Resource Access

httprestSecurity

Suppose user A creates a private resource at, for example, /books/somebooktitle

If user B attempts to access the resource at /books/somebooktitle what code should be returned?

HTTP403: Permission denied seems obvious BUT, does this not leak information to user B that someone has created a book and named that book with the title "somebooktitle"? That's two pieces of information that user B shouldn't technically be entitled to.

HTTP404: hides the fact that the book exists.

Is there best practice?

Best Answer

There is no best practice for precisely the reason you cited in your question. It becomes a judgement call based on the kind of information you might expose. If hinting that "somebooktitle" might leak security-sensitive information, or violate a copyright or other kind a law, then go with a 404 Not Found response. You also have the option of redirecting the user to a general purpose search page that results in a 200 OK response. Which kind of response you choose will be driven by security, legal and business considerations. There is no one-size-fits-all solution here.

429 Too Many Requests

The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes. This code has been accepted in RFC 6585 Additional HTTP Status Codes.

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

Rest – HTTP Response Header for a unique Request ID for REST service

I would use a standardized body and not use the header. For example, every body can be JSON and include an ID field. As long as it's standardized across your platform it's guaranteed to work.

I would not use a custom header because of the risk of it getting stripped. I would not use a standard header because I don't know of one that fits perfectly (e.g. the ETag you mention is used to determine file changes and caching keys.)

Best Answer

Related Solutions

HTTP REST Status Code – Suggested Code for ‘Request Limit Reached’

429 Too Many Requests

Rest – HTTP Response Header for a unique Request ID for REST service

Related Topic