Security considerations for status codes #311
Description
As HTTP response status codes indicate the result of a request, there are security considerations to take into account depending on the state of the target resource of an HTTP request.
Depending on the request semantics, both success and error responses can reveal both the past and current state of a target resource.
Example:
The 201 status code in the response of a PUT request indicates that the target resource did not have a current representation and that one was created successfully, and 200 or 204 indicates that the target did have a representation and that the target was modified ( https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4 ). There are other 2xx codes that can occur but that's irrelevant for this discussion.
View the RFC 7231 requirement for successful responses to PUT
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.
Access control mechanisms typically make the distinction between permissions to view the state of a resource from permissions to change the state of a resource. Here, "change" may create or update the target resource of an HTTP request.
This brings us to the following question:
Do operations to create and update resources encompass read permissions on the target resource within the framework of HTTP?
For instance, a client may have write-only access on the target resource, and while it would be authorized to change its state, it would not be authorized to know about its state. Whether the class of write operations split into specific operations is irrelevant here.
Noting that the use cases to write-only are rare, so in practice both read and write would be given to allow a write operation. However, this is orthogonal to how authorization rules could be set.
One way to implement an authorization system that makes a clear distinction between read and write operations that also conforms to RFC 7231 would be: Only when a client has both read and write permissions, a successful response to a PUT request can be 201, 200 or 204. A less "strict" implementation however may reveal the same status codes when client has only write permission. See for example the table on PUT in #14 (comment) that currently gives importance to using 7231's status codes, i.e., read permission on target resource is not required to reveal its past state.
Another approach here is to use the same status code whether the resource state is created or replaced. However, that raises the question whether such implementation strictly conforms to RFC 7231 or if there is some leniency that can be worked out, or if some degree of wilful violation is necessary for the Solid Protocol.
There are others examples - like with POST, PATCH or append-only operation, or even when specific headers like If-None-Match are in play - that can be classified under the same security considerations but I'd like to keep it simple for the moment by focusing on what the status codes reveal. But feel free to raise them in the comments in any case.