Overview of RESTFUL web services security

The main objective of software security is to apply a set of measures to prevent vulnerabilities that can evade privacy of controlled data or misuse of resources. From this objective, we derive two main aspects of security: authentication and authorization.

RESTful web services differentiate themselves from SOAP-based web services mainly in the simplicity of their design and implementation. However, they can become vulnerable when they are unsecured, especially when serving controlled data. 


Authentication validates if you are the right person who can login to the software system. For example, if a user, such as "i88ca", is the authenticated user to login to the server "Superman".
The following are some options that are commonly used for setting up authentication:

  * Basic authentication: Basic authentication is one of the easiest ways to implement security as it does not require overhead of additional APIs, besides the APIs used in the implementation framework itself. As the name implies, it is basic in nature where you send user name and password in Base64 encoding with no advanced options. It should always be used with SSL encryption to prevent credentials being decoded.

  * OAuth 1.0a: Oauth1 is a signature based protocol. It is a widely-used, well-tested, and very secure protocol. The protocol uses a cryptographic signature, such as HMAC-SHA1, which is a value that combines the token secret, nonce, and other request based information. The biggest advantage of OAuth 1 is that it does not require passing the token secret across the wire directly. Because of this, it completely eliminates the possibility of tapping the password from over the wire. This can be safely used without SSL. However, this higher level of security offered in this protocol comes with an overhead of complex signature generating process.

  * OAuth 2: This protocol completely eliminates signatures; hence, it is much simpler. It requires Transport Layer Security, which handles encryption. Oauth2 is less widely used and less secured as compared to OAuth 1.0a. Therefore, it can be used for less sensitive data.

  * Custom security protocol: This approach should be avoided not only because no one, besides you, will use your custom protocol. It puts the responsibility of maintenance on the creator. For very secure data, you do not want to leave open holes unless you know what you are doing.

Because of advantages and disadvantages mentioned above, it is safer and simpler to choose Basic Auth with SSL for most REST services. However, high overhead based OAuth 1.0a protocol can be used for extremely sensitive data in less common situations.


Authorization validates if you are the right person to have access to the resources. For example, whether or not a user, such as "i88ca", is authorized to perform a read or write operation on a file such as /home/it/resources on the Linux server "HdGem".

Authorization can be set up on the resource managed by an operating system using operating system groups, or on a resource in a web application deployed on a Java EE server using an LDAP user group.


Popular posts from this blog

Check MySQL query history from command line