With REST client sessions are not handled by maintaining server side state. Any such state needed for subsequent calls is passed to the client and then passed back to the server as part of those calls.
So what's the standard approach to state that you don't want the client to have?
E.g. I have a resource X, internally instances of this resource have simple names like "A", "B" and "C". Multiple instances of resource X can be associated with a given user - and in each REST call I want to specify which specific instance of X is currently being operated on.
In the simple case I'd just include something like this in my REST calls:
"xId" : "B"
However there are a number of things I want to prevent...
- I want to prevent the user fishing for other instances, by e.g. specifying arbitrary IDs like "Z" in the their calls.
- I don't want the internal names of the resources ending up on client machines (these might be useful in attacks via completely different vectors).
- If a given instance of X is reassigned to another user I want to prevent the old owner using its ID (that they validly obtained) in further calls now that it is no longer assigned to them.
I'm guessing people will reply that there are two issues here:
- That I'm not talking about session state here but rather the assignment of resources to users and that on the server side I just need to validate that the resource specified in a call is really associated with that user.
- That there's a separate ID masking issue here - that if I have internal IDs that I don't want exposed to the client I should just create long lived aliases.
Are there a good set of guidelines covering the specific security issues that arise with REST as a result of storing session state on the client side (as opposed to keeping it on the server side)? E.g. the trusted client problem isn't REST specific but perhaps there are REST specific aspects to this and other problems that one should generally be aware of.
In the specific situation I've described I would assign random UUIDs generated by a CSPRNG as aliases to my underlying resources, validate that a given resource is associated with a user when it's specified in a call and assign a new alias to the underlying resource whenever it is reassigned to another user (a step that shouldn't actually be necessary given that one always validates the current association of an ID with a user). However with security I generally find that when non-experts think they've got all the angles covered they're generally wrong!