REST Services - Security Best Practices

As most of us know, REST (Representational State Transfer) is an architectural principle and is gaining increasing reckoning amongst architects for the inherent advantages that it offers. REST does recommend the use of standards such as HTTP, URI, XML and JSON and formats such as GIF, MPEG, etc. Twitter, iPhone apps, Google Maps, and Amazon Web Services (AWS) demonstrate heavy use of REST services. The basic tenets of REST is statelessness and is all about utilizing the HTTP commands GET, PUT, POST, DELETE as outlined in the HTTP RFC.


Obviously, Architects see some key advantages with the REST services, and so REST implementation becomes an important consideration in responsive, service oriented applications. Let us have a recap of some of the key advantages as below:

• The resources can be uniquely identified using URI and facilitates interconnection of these resources.
• Resource manipulation is accomplished using the standard HTTP verbs, viz GET, PUT, POST, DELETE
• The data payload is minimal and thus offers the capacity and efficiency benefits.
• Easier implementation offers shorter learning curve, maintainability and time to market advantage.
• Increased support from the JavaScript offers the client side computing benefits and thus improve the responsiveness.

Needless to mention, there are certain disadvantages too with the REST Services and here are some:

• Prone for same level of threats and vulnerabilities as the HTTP and Web
• Improper use of the HTTP commands could lead to problems and complicate the design.
• Relies on very few standards.

Some of the security challenges with REST Service implementations are outlined below:

Chained trust is challenging for web service implementations and the situation is no different with REST. Unlike in case of SOAP, standards like WS-Security, SAML cannot be used in case of REST services. This call for relying on a combination security implementations which are specific to different implementations. Here are some such security implementations, which in combination may help overcome this concern:

• Use Digital Certificates for authenticating the server and the user. 
• Pass the user's identity from server to server and necessary validation and authorization at the data source.

Cross site request forgery (CSRF) attacks, which attempt to force an authenticated user to execute functionality without their knowledge. Being stateless, REST is inherently vulnerable to CSRF attacks. The work arounds for this security concern are:

• Use of a custom header - Setting a custom header such as X-XSRF header is known to be a solution for this concern. The endpoints receiving the REST service requests would reject or drop such requests if the intended custom header is not part of the request. It is to be noted that this is not a fool proof technique, but at the same time offers some bit of protection than nothing.
• Another approach is to deviate from the basic tenets of REST and maintaining state, in which case a token can be generated and maintained to authenticate the requests, so that requests carrying an invalid or no tokens can be dropped or rejected.

While the above are just an example of the concerns, REST services being based on HTTP specifications is prone to all the security vulnerabilities as that of a web application. Thus REST implementation while it is the easier choice due to its advantages listed above, should also be implemented with due considerations to some or all of the following security best practices:

• All data must be sent over HTTPS and this will ensure securing of the data in transit.
• Use of PKI or HTTP Digest Authentication for authentication.
• Always perform authorization for every request upon receipt. 
• Scan HTTP headers, query strings and POST data and look for reasons to reject a request.
• Don't combine multiple resources with a single URI, always uniquely identify each resource, so that the security implementation can be simple and relevant to the specific resource.
• Always perform validation of the JSON / XML data.
• Ensure appropriate use of the HTTP commands for managing the resources and enable selective restriction of these commands.
• Design URIs to be persistent. If a URI needs to change, honor the old URI and issue a redirect to the client.
• Caching should generally be avoided where possible and sensitive data should never be cached.
• When developing REST solutions, care needs to be taken not to create URIs that contain sensitive information. 
• The requester should be authenticated and authorized prior to completing an access control decision. 
• All access control decisions shall be logged. 
• Code as if protecting the application.

Here are certain useful readings on securing the REST services:

• REST vs. SOAP: How to choose the best Web service
• Enabling Message Security for RESTful Services
• Securing RESTful Web Services with OAuth2
• Securing RESTful services
• REST Assessment Cheat Sheet
• Configuring Spring Security for a RESTful Web Services
• Comparison of Security Techniques for RESTful Services