REST API?
REST is an acronym for Representational State Transfer. This is a software architectural style that allows for many protocols and underlying characteristics the government of client and server behavior.
Application Programming Interface (API) is a set of clearly defined methods of communication between various software components. A good API makes it easier to develop a computer program by providing all the building blocks.
Does Security Matter?
Security aspects should be a serious consideration when designing, testing and deploying a RESTful API.
In today’s connected world — where information is being shared via APIs to external stakeholders and within internal teams — security is a top concern and the single biggest challenge organizations want to see solved in the years ahead.
According to research by SmartBear presented in their State of APIs Report 2016:
- Security is the #1 technology challenge teams want to see solved; 41.2% of respondents say security is the biggest API technology challenge they hope to see solved.
- Security is the #4 technology area expected to drive the most API growth in the next two years; 24% of API providers say digital security will drive the most API growth in the next two years.
- 40.4% of API providers are currently utilizing a tool for testing API security
With the explosive growth of RESTful APIs, the security layer is often the one that is most overlooked in the architectural design of the API.
Some of the guidelines that should be considered in the security aspects when testing and developing REST APIs I will try to explain below.
Authorization
It is also important to have whitelist permissible methods. Sensitive resource collections and privileged actions should be protected. The API key or session token should be sent as a body parameter or cookie to make sure that privileged actions or collections are efficiently protected from unauthorized use.
You should ensure that the HTTP method is valid for the API key/session token and linked collection of resources, record, and action.
Clear access rights must be defined especially for methods like DELETE (deletes a resource) and PUT (updates a resource). Those methods must be accessed only by authenticated users only and for each such call, an audit must be saved.
Care should also be taken against cross-site request forgery. Here, one should be familiar with the prevention of XSS.
Authentication
It is important to be in a position to verify the authenticity of any calls made to one’s API. The ideal way would be to have a shared secret with all authorized users.
The simplest form of authentication is the username and password credentials one. Other types would include multi-factor authentication and token-based authentication.
Authentication goes hand in hand with authorization.
Auditing
Once in a while, security related events could take place in an organization. It is imperative that thorough auditing is conducted on the system.
This would involve writing audit logs both before and after the said event.
Token validation errors should also be logged in so as to ensure that attacks are detected. Log data should be sanitized beforehand for purposes of taking care of log injection attacks.
Input Validation
Automated tools have the capability to distort one’s interfaces when on high velocity. It is very important to assist the user, in line with the “problem exists between the chair” (PEBKAC) scenario.
Web services should require the input of high-quality data (validated data) or that that makes sense. If that is not the case, the input should be rejected.
Further options would include input sanitization and in some cases, SQL or XSS injection. The application’s output encoding should be very strong.
Other measures that would be taken include URL validations, the validation of incoming content types, the validation of response types, JSON and XML input validation should also be enforced when possible on the fields level. If for example, we know that the JSON includes a name, perhaps we can validate that it does not contain any special characters.
One more aspect is trying to follow URI design rules, to be consistent throughout your entire REST API.
TLS
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over a computer network.
When secured by TLS, connections between a client and a server have one or more of the following properties:
- The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
- The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
- The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.
TLS is quite heavy and in terms of performance, it is not the best solution. However, when used along with http/2, it will compensate for the speed and performance. You can read more about it here - http/2 benefits for REST APIs.
Cryptography
When it comes to security, this is probably the most important of the guidelines when building a REST API. REST APIs mostly handle data, coming to them and from them. It is also a very important doing security testing for your REST APIs.
In order to secure the DATA, you have to consider the following:
- Data in transit - The encryption of data transmitted to your API, this is mostly done on the infrastructure level like TLS and SSL support.
- Data in storage - The data you store, especially sensitive data must be encrypted or have restricted access (DB access, File Storage and etc..)
- Message integrity - The integrity of the data transmitted from your API to storage or to the client should be kept. Except for TLS, you can also calculate checksums (when it comes to files or objects that are uploaded in parts) or hashes of certain data in order to verify that no one handled the data while it was transmitted.
Here you always need to consider whether the API you are creating is internal or external API.
DOS Attacks
In a Denial of Service (DOS) attack, the attacker usually sends excessive messages asking the network or server to authenticate requests that have invalid return addresses. DOS attacks can render a RESTful API into a non-functional state if the right security measures are not taken.
Today, even if your API is not exposed to the public, it still might be accessible by others. This means that REST API security is getting more and more valuable and important.
Consider that someone succeeds in making a DOS attack, it means that all the connected clients (Partners, Apps, Mobile Devices and more...) will not be able to access your API.
RestCase - REST API Development, Supercharged!
Anti-Farming
There are always several marketing-heavy websites that offer consumers the best deal on everything from flights to vehicles and even groceries.
In many of these cases, the aggregated service is taking advantage of other APIs to obtain the information they want you to utilize. When this happens, the RESTful API is being farmed out for the benefit of another entity.
In case your API does not have an Authorization / Authentication mechanism, it might lead to miss-use of your API, loading the servers and the API itself making it less responsive to others.
HTTP Status Codes
It is important to consider numerous REST API status return codes, and not just using 404 for errors and 200 for success.
I wrote about those codes already but I think it is worth to mention again that other codes should be considered:
- 400 bad request - for the case when the validation did not pass.
- 401 unauthorized - When authorization of the user has failed, like
- incorrect username or password.
- 403 forbidden - This status is mostly for Authentication and Data Access Rights. It should indicate the user, that he does not have access to a specific resource in the API.
- 405 method not allowed - In case you do not support a method (like PATCH or DELETE for example)
- 429 too many requests - Can be used to signal that too many requests came from the same origin.
Summary
The above are some of the most important RESTful API security guidelines and issues and how to go about them. By at least trying to work with these guidelines, you will experience a more quality and secure REST API services and it will give you many benefits in the future.
For more about REST API security guidelines you can see checkout the following articles: