Talk:REST Security Cheat Sheet
- Giving access to objects simply by the key value in the URL rather than checking proper authorization for that entity. (i.e., this user doesn't have access to object 1235, but we allow the method simply because 1235 was in the URL rather than checking to see if this user is allowed to modify/view it)
- Giving away sensitive information simply by including the object ID in the URL. Users tend to copy/paste URL's and they get cached in many different places and included in the history (even if the response gives the right Expires, Cache-control, and Pragma headers), so the URL shouldn't directly include anything sensitive like account number. http://some.service/account/128420482 should be a no-no.
I would love to add a section on validating incoming entity definitions via XML or JSON. In XML, you have to deal first with entity expansion (death by a million laughs) because entities are expanded before the XML itself is validated, then need to validate against a DTD, XML-Schema, etc.
I'm just now finding out that there is a loose definition of a JSON validation scheme , but I'm not sure if any of the popular server-side JSON frameworks support this built-in, or what the maturity is of any of the implementations at . Anybody have any knowledge on this?
REST short definition
REST is not an architecture, but it is an architectural style to build services on top of the Web. Basically, REST style aimed to show how the Web works in terms of architecture(URI,URL,Web Methods). According with the HTTP specification, the verbs or methods already defined were designed to accomplish a specific task (Get to retrieve a resource without modifying it, POST for the creation, PUT to modify an existing one represented by the URI).
On top of REST based services,there is a protocol called OData(The Open Data Protocol), OData follows the architectural style of the Web, and allows the HTTP Content negotiation using standard media formats, including XML, JSON, Atom, RSS. Serving data in this formats also increment the risk of payloads attacks. Do you think we should include payloads attacks in this section?
In HTTP, the centric piece of functionality is a resource. So it is very important that only those authorized guys can access to each resource(if the guy does not have permision, a HTTP status code should be displayed 401 unauthorized. Also it is important to use SSL for all HTTP traffic. Does that make sense as a part of this Cheat Sheet?
Authentication in Header
I've seen quite a few examples of REST services available over HTTPS where the authentication mechanism (API key or the Username and Password) are added to the Headers of a GET rather than send via cookie or POST, this is TLS encrypted and doesn't suffer the exposure problems of having this information in the URI. I wondered if anyone had an opinion on this method, good or bad, how could it be exploited? Could you add something about it to this cheat sheet stating if it is acceptable practice.
I don't agree with the advice that authentication should be session-based. I would avoid keeping track of sessions on the server side if at all possible and require the client to pass a security token, e.g. OIDC JWT, in the Authorization header with each request. Thoughts anyone?
Protect Session State
Under 'Protect Session State" I think there should be a short discussion of HMAC'ing anything sent to the client. For stateless applications this especially important; many will encrypted (AES-CBC for example), but not use authenticated encrypted or HMAC the blob. I also posted this on reddit /r/netsec and there is some additional points in that thread --> http://www.reddit.com/r/netsec/comments/2ogjkv/rest_security_cheat_sheet/