Preventing a rest call in a statless context

Question

Let's suppose an application with a table with pagination.

The table shows indexed items (item1, item2,... itemN).

The pagination result is provided by a REST GET call like /items

The detail of an item is provided by a GET call like /items/1 or /items/N

The question is: Which is the best way to secure accessing a not allowed item.

For instance.

a) user call to /items results in {1 ,2, 3, 4, 5} whichs prints a table with links to each detailed item.
b) prevent a call to /item/6

Only stateless solution please, Thanks!

Answer 1

Not sure I completely understand your problem. What it seems to me is that you want to have item level authorization. For example, user A should only see items 1, 3 and 5, while user B should see items 1, 2, 3 and 6. If that is the case, you should enforce the authorization constraints for both the list and for the individual items.

If what you want is that a user can only access items he has listed before, you are not in a stateless context. The result of the call to the item is dependent on the previous call. So you have a state. You can move the state around, move it to the client, but it will still be state.

If what you want is the second option and you want your service to remain mostly stateless, have a look into capability base security. Basically, your list needs to return a cryptographic token that needs to be used by the client in order to access the individual items.

Basically, instead of returning just the items IDs, add a cryptographic token with it:

[
  { id = 1, token = 'XXX'},
  { id = 2, token = 'YYY'}
]

The token will be composed of :

• a nonce
• en expiry date
• the item ID to be authorized
• a cryptographic signature of the above elements

You sign the authorization token with your server private key, so nobody can forge it. You ask the client to add this token to any request (as an HTTP header). So the server can validate that the client has received an authorization.

You can add the username to the token to make sure the authorization cannot be reused by someone else.

Note that I just describe this implementation from memory. As always with security, please double check anything I tell you ;-)