This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Since the REST architecture style is based on the HTTP protocol, these services are prone to the same vulnerabilities as standard web applications, including broken authentication, injection attacks, cross-site scripting and cross-site request forgery. Also REST services face unique security challenges with Web 2.0 applications such as mash-ups.
This article explains how REST security differs from HTTP security and suggests various security mechanisms to address REST security challenges.Â
This article also throws some light on industry wide initiatives to provide standards based security mechanism for REST services.
What is REST?
The REST approach is one of the major approaches to building distributed systems using "pure" web technologies (HTTP, HTML etc) and is widely known as the resource-oriented approach. REST (REpresentational State Transfer) is a term coined by Roy Fielding in his PhD dissertation describing a resource-oriented architecture style for networked systems  .
An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (such as an HTTP URI). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (such as HTTP) and exchange representations of these resources (the actual documents conveying the information)  .
Security for REST services and APIs
Because of the inherent HTTP attributes of REST like simplicity, openness, and scalability, more and more Application Programming Interfaces (API) are being developed using REST principles. While doing so existing HTTP Web application security models (such as HTTPS and other authorization and authentication mechanisms) are also adopted to provide security for REST applications.
Differences between REST security and SOAP security
Though it's interesting to compare REST to SOAP, strictly speaking they are not directly comparable, since REST is an approach while SOAP is a protocol. Still, they're often treated as alternatives, so we will look at them together. SOAP allows invocation of remote procedure calls (RPC) via HTTP ports to provide web services support across organizational boundaries. Many REST developers consider this as a major flaw that compromises network security.
This occurs because policies have been made around standard port numbers to distinguish applications, such as port 80 for HTTP. Any service can be blocked by doing the necessary configuration at the firewall level, an approach that makes it easy to have control over the applications that may be used. However, SOAP over HTTP shifts this problem to the layer above by tunneling remote methods pver the standard HTTP port. At the TCP level it is no longer possible to distinguish the application or service being used the port number instead content of the HTTP messages or SOAP messages must be analyzed to control access to certain applications or services.
REST calls also go over HTTP or HTTPS but with the help of firewall or similar software one can easily identify the intent of the REST message by analyzing the HTTP commands used in the request (for example, GET is always considered safe as it cannot modify any data or state of the server)
It is not possible for a firewall to identify the intent of a SOAP request sent using the HTTP POST method to communicate with a given service, without inspecting the SOAP envelope. For example, there is no way to tell whether intent is to query the data or erase the data.
For implementing authentication and authorization, SOAP places the burden on the application developer whereas the REST methodology relies on Web servers.
Challenges faced by REST APIs and Applications
Since the REST architecture style is based on the HTTP protocol, these services are prone to the same vulnerabilities as standard web applications such as:
Unvalidated Input: Attackers can use these flaws to attack backend components through a web applications or REST API. It is very important to validate input data as it traverses the application layer. A large number of attacks can be avoided by validating input data, whether obtained from the client, from the infrastructure, from external entities or from database systems.
"Never trust inputs without verifying them"
REST APIs should never trust inputs without verifying them. Here are some of the standard web application security techniques that can be applied to REST :
Validating the size of parameters on the query string
Validating the content of parameters on the query string
Examining parameters in the query string for known attacks such as SQL Injection
Applying regular expressions to query string parameters
Broken Authentication: If restrictions on what authenticated users are allowed to do are not properly enforced, attackers can exploit these flaws to gain control of other users' accounts, access sensitive data, or perform unauthorized functions.
Injection Attacks: Web applications pass parameters when they access external systems or the local operating system. If an attacker can inject malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
Some of the input validation techniques mentioned above can be used to guard REST APIs against Injection attacks.
Immature Protocols: New protocols may not always properly handle security. For example, OAuth 1.0 (E. Hammer-Lahav, 2010) is vulnerable to a session-fixation attack that could allow an attacker to steal the identity of an API end-user (OAuth Security Advisory: 2009.1, 2009)
Also REST services face additional security challenges from browser scripting and Web 2.0 approaches like mash-ups:
Cross-site scripting (XSS) and cross-site request forgery where a web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.
Web 2.0 and Rich Internet Applications (RIA) rely heavily on REST APIs, making these APIs prone to XSS attacks.
A mash-up that retrieves data from multiple APIs might require user credentials. It's up to the mash-up provider to authenticate end-users' access credentials (such as same-origin bypass).
End users must trust the mash-up provider not to steal (or inadvertently reveal) their credentials and the API providers must trust that the mash-up provider has authenticated the valid user of this account, not a hacker or malicious user.
Best practices for REST services security
Unlike WS-* that specifies a well-defined security model that is protocol independent and is built specifically for SOAP web services, REST does not currently have its own security model. Instead, today's REST security best practices leverage existing HTTP security implementation approaches.
Following are the some of the rules recommended for securing REST services by Comerford and Soderling (Soderling, 2010) 
Do employ the same security mechanisms for your APIs as any web application your organization deploys. For example, if you are filtering for XSS on the web front-end, you must do it for your APIs, preferably with the same tools.
Don't invent or roll out your own security. Use a framework or existing library that has been peer-reviewed and tested.
Unless your REST API is a read-only public API, don't use single key-based authentication. This is not enough. Add a password requirement.
Don't pass unencrypted static keys. If you are using HTTP Basic and sending it across the wire, encrypt it.
If possible, use a hash-based message authentication code (HMAC) because it's the most secure
Filtering query strings is important. For this REST security can follow standard to Web Application Security approaches.
Web Application security mechanisms and REST services
Let us look at some of the major HTTP security approaches within the scope of REST to see how they help in securing REST services.
The following are some of the some of the main HTTP approaches for securing web applications
Token based authentication
Transport Layer Security (TLS) protecting sessions over the Internet
HTTP Authentication Schemes
HTTP authentication mechanisms can be divided into two categories:
Basic Authentication scheme
Digest Authentication scheme
Basic Authentication Scheme
The Basic Authentication scheme is the simplest authentication scheme  defined in RFC 2617  . It sends a HTTP header called 'Authorization' with the Base64 encoding of the "<username>:<password>" string .
If the provided authentication information is valid, the content of the requested resource is returned along with HTTP status code of 200 . If authentication information is not valid; that is, if the request is issued without the 'Authorization' header or if the provided credentials are invalid, the server responds back to the client with a HTTP status code of 401 requesting authentication .
The Basic Authentication scheme is also called pre-emptive authentication as it requires clients to send the authentication header in the first request, with no additional client interaction required. Because of this pre-emptive nature, Basic Authentication can be considered as performing slightly better than Digest (challenge-response) authentication that requires a re-issuing of the request with a response to the challenge presented.
Simple and easy to use
Almost all HTTP libraries support it
Transmits the username and password in a clear and easily decryptable manner (Base64 coding)
Because of its simplicity, the Basic Authentication scheme is widely popular and supported by the majority of REST API implementations. It is usually appropriate only over secure connections i.e. HTTPS.
Digest Authentication Scheme
Digest access authentication is one of the agreed methods a web server can use to negotiate credentials with a client (such as a web user's browser). It uses encryption to send the password over the network which is safer than the Basic access authentication. Technically, digest authentication is an application of Message-Digest algorithm 5 (MD5) cryptographic hashing using nonce values (defined below) to discourage cryptanalysis. Digest access authentication was originally specified by RFC 2069 
Digest authentication is a challenge-response mechanism, where a client application (such as a browser) sends an HTTP request (such as GET) to a web server. The server sees the resource (or URL) being accessed has been configured to require Digest authentication and replies with a 401 "Authentication Required" status along with a "nonce" - a unique hash of several data items, one of which is a secret key known only to the server.
The client application computes an MD5 hash of the username, password, nonce and URL and resends the original request along with the hash.
The web server compares that hash with its own computation of the same values. If they match, the original HTTP request is allowed to access the specified resource.
The password is not used directly in the digest. Instead, the stored value is a hash generated using MD5 (username:realm:password).
The client nonce introduced in RFC2617 allows the client to prevent chosen plaintext attacks, by generating different nonces each time that the 401 authentication challenge response code is presented
Replay attacks can be prevented by including a timestamp in the server nonce submitted by client.
The server can maintain a list of recently issued or used server nonce values to prevent reuse
Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode
Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack
Digest authentication involves too much traffic HTTP authentication is usually a two-step process to establish a session, but RESTful services don't usually have any kind of session.
Token Based Authentication
Token based authentication is the approach used by Amazon Web Services (AWS) for authenticating REST services. In the context of Amazon Web Services (AWS) requests, authentication is the process AWS uses to both confirm that a request came from a registered user, and obtain the identity of that registered user.
To enable authentication, each request must carry information about the identity of the request sender. The request must also contain additional information that AWS can use to verify that the request can only have been produced by the sender identified. If the request passes this verification test it is determined to be "authentic" and AWS has sufficient information to verify the identity of the sender.
Verifying the identity of the sender of a request is important, as it ensures that only those requests made by the person or party responsible for the AWS account specified in the request are accepted and allowed to interact with AWS services. In this manner, request authentication allows Amazon to track the usage of AWS services on a per request basis. This enables Amazon to charge and bill AWS subscribers for use of AWS paid (not free) services.
The following steps are the basic steps used in authenticating requests to AWS. It is assumed that the developer has already registered with AWS and received an Access Key ID and Secret Access Key.
The sender constructs a request to AWS.
The sender calculates a Keyed-Hashing for Message Authentication code (HMAC), the request signature using the sender's Secret Access Key and the values of the Service, Operation, and Timestamp parameters as input.
The sender of the request sends the request data, the signature, and Access Key ID (the key-identifier of the Secret Access Key used) to AWS.
AWS uses the Access Key ID to look up the Secret Access Key
This not truly private as Amazon also knows the sender's private key.
AWS generates a signature from the request data and the Secret Access Key using the same algorithm used to calculate the signature in the request.
If the signature generated by AWS matches the one sent in the request, the request is considered to be authentic. If the comparison fails, the request is discarded, and AWS returns an error response.
This approach is a reinvention of a subset of SOAP/WS-Security functionality for REST. Concepts used from WS-Security are:
WS-Security UsernameTokens with timestamp support, for sending username tokens
WS-Security's support for XML Signature
No need to exchange user credentials
Helps in validating the identity of the sender of a request
Helps is in tracking, applying Access Control List (ACL )and policies; for example, the number of request per hour;
No proof of possession of the Secret Access Key
This approach is better than Basic or digest authentications approaches and provides better security with for RESTful services much overhead.
Transport Layer Security (TLS) and Secure Socket Layer (SSL)
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability. Transport Layer Security (TLS) or Secure Socket Layer (SSL) provides transport level, point-to-point security  .
In the TSL approach client and server negotiate a Stateful connection by using a handshaking procedure and agreeing on various parameters used to establish the connection's security.
The client application initiates handshaking by connecting to a server, requesting a secure connection, presenting a list of supported ciphers and hash functions. From this list, the server picks the strongest cipher and hash function supported by the server and notifies the client of the decision.
The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key.
The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is valid before proceeding.
In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key. From the random number, both parties generate key material for encryption and decryption.
This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.
Encryption protects request and response bodies from intermediate prying eyes.
Server authenticated - Clients can store the server's SSL certificate and monitor the server to ensure it does not change over time to guard against a man-in-the-middle type attack.
Using a certificate signed by a signing authority can also provide a similar level of assurance for the client application.
Easy setup and can be configured at web server. No additional coding is required.
Increased load - Encrypting and decrypting communication is noticeably more CPU-intensive than unencrypted communications
One issue with both TLS and SSL is that every request requires additional back and forth communications to set up the secure socket. This overhead can be minimized using the Stateful connection feature of HTTP 1.1. Though all REST implementations take advantage of this approach to secure authentication mechanisms like basic authentication, the SSL or TSL security approach does not naturally align with the REST architecture. TLS secure sessions are user specific and keys are generated dynamically. The content is encrypted again and again as it travels via a secure tunnel making it impossible to cache this data as the web caches cannot access the data inside the tunnel. However, clients receiving the content can copy it locally. This heavily reduces the scalability of the REST architectural style for applications and services that require access control to the data and for this reason provide the data through e.g. TLS tunnels or require HTTP authorization.
"The fundamental challenge with existing HTTP security models is that they offer IP-to-IP security solutions and not application-to-application ones"
Some Industry wide standards for REST services security
OAuth (OAuth Community Site)
Open Authorization (OAuth ) is an open standard for authorization. It allows users to share their private resources stored on one site with another site without having to hand out their credentials, typically username and password.
OAuth allows users to hand out tokens instead of credentials to their data hosted by a given service provider. Each token grants access to a specific site (e.g. a video editing site) for a specific resources (e.g. just videos from a specific album) and for a defined duration (e.g. the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.
OAuth tokens are nothing but session identifier. Interaction is not stateless between requests in the OAuth token negotiation protocol as the requests must be performed in a specific sequence and they do require per-client storage on the server as needs to track things like when they were issued. So OAuth does violate the strict principles of a RESTful architecture.
OAuth can be potentially used as an authorizing mechanism to consume secured (i.e. authenticated) RSS/ATOM feeds. In general consumption of RSS/ATOM feeds that requires authentication has always been an issue.
OAuth is a service that is complementary to, but distinct from, OpenID.
OpenID (OpenID Foundation )
OpenID is an open standard that describes how users can be authenticated in a decentralized (brokered authentication) manner, avoiding the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Brokered authentication standards like OpenID accommodate RESTful web services for browser driven client or use cases. However, they don't address RESTful service patterns where identities need to be propagated across nested service invocations, or any RESTful Web service client that is not browser based for that matter.
Current security models around HTTP are built to address the traditional request response patterns such as stateful communication, server side sessions, and long connection timeouts. whereas the REST approach brings its own set of request response paradigms such as statelessness, caching more requests to the server (than traditional web applications), non browser based clients etc. Moreover REST services are widely used for API design unlike traditional web services. The existing HTTP security models in most of the cases reduce the REST service capabilities (for example, the SSL and REST caching mentioned above etc).
The current HTTP security approaches are not sufficient to address the security needs of REST services. Hence there is a definite need to extend the existing HTTP security models to adequately address the specific needs for REST services and Web 2.0 applications.
Initiatives like OAuth and OpenID are very encouraging in terms of providing security approaches for modern web applications. Providing more space for inclusion of REST approach in these standards will augment in bringing up standardization of REST services security instead ending up with multiple and custom security implementations.
An access control list (ACL), with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects (Access control list (ACL))
Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (pronounced sea-surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser (Cross-site scripting)
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy (Cross-site request forgery)
Message-Digest algorithm 5 (MD5) is a widely used cryptographic hash function with a 128-bit (16-byte) hash value. Specified in RFC 1321, MD5 has been employed in a wide variety of security applications, and is also commonly used to check the integrity of files. (MD5 (Message-Digest algorithm 5))
Rich Internet Application (RIA) is a web application that has many of the characteristics of desktop applications, typically delivered either by way of a site-specific browser, via a browser plug-in, independent sandboxes, or virtual machines (Rich Internet application (RIA))
ACL Access Control List
API Application Programming interface
Atom The Atom Syndication Format
AWS Amazon Web Services
CA Certificate Authority
HMAC Hashing for Message Authentication code
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
POX Plain Old Xml
REST REpresentational State Transfer
RPC Remote procedure calls
RSS Really Simple Syndication
S3 Amazon Simple Storage Service
SSL Secure Socket Layer
TLS Transport Layer Security
URI Uniform Resource Identifier
XSS Cross-site scripting
References and Acknowledgements
RESTful Security by Dan Forsberg, Nokia Research Center, Helsinki, Finland email@example.com , firstname.lastname@example.org
Representational State Transfer (REST) WiKi
RFC 1321 The MD5 Message-Digest Algorithm
RFC 2069 An Extension to HTTP : Digest Access Authentication
RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
Why REST security doesn't exist - Chris Comerford and Pete Soderling
Security for REST and Web 2.0 - Richard Mooney - Senior Solution Architect
OAuth Core 1.0
OAuth Security Advisory: 2009.1
Is OAuth 2.0 Bad for the Web?
Acknowledgement of the OAuth security issue
Cross-site scripting (XSS) Wiki
Cross-site request forgery Wiki
Rich Internet application
MD5 (Message-Digest algorithm 5)
Access control list (ACL) Wiki