As an increasing number of organizations provide API access to make their information available to a wider audience, securing that access is likewise of increasing importance. With the growing adoption of cloud, mobile, and hybrid environments the risks are increasing. Cyber threats and DDoS attacks are targeting enterprise applications as back-end systems become more accessible. In such situations, the API can be a significant point of vulnerability with its ability to offer programmatic access to external developers.
The previous wave of security breaches occurred when organizations opened access to their web applications. Defenses, such as web application firewalls (WAF), were introduced to mitigate those security breaches. However, these defenses are not effective against all API attacks, and you’ll need to focus on security of your API interfaces.
API Security
The predominant API interface is the REST API, which is based on HTTP protocol, and generally JSON formatted responses. Securing your API interfaces has much in common with web access security, but present additional challenges due to:
- Exposure to a wider range of data
- Direct access to the back-end server
- Ability to download large volumes of data
- Different usage patterns
This topic has been covered in several sites such as OWASP REST Security, and we will summarize the main challenges and defenses for API security.
Authentication
The first defense is to identify the user, human or application, and determine that the user has permission to invoke your API. We are all familiar with entering a user ID and password, and possibly an additional identifier, to access a web interface. Corresponding for API, there is an API ID and an API key that are specified on the request to authenticate the user. The API key is a unique string generated for the application for each user of the API.
Access Control
Not all authenticated users will necessarily be authorized to access all provided APIs. For example, some users require access to retrieve (GET) information, but should not be able to change (PUT) any information. Using an access control framework, such as OAuth, you control the list of APIs that each specific API key can access.
To prevent a massive amount of API requests that can cause a DDoS attack or other misuse of the API service, apply a limit to the number of requests in a given time interval for each API. When the rate is exceeded, block access from the API key at least temporarily, and return the 429 (too many requests) HTTP error code.
Encryption
To protect the request in transit, require HTTPS for all access so that the messages are secured and encoded with TLS.
To protect the JSON formatted response, consider employing the JSON Web Token (JWT) standard. As stated in that site,
JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.
Confidentiality
As a best practice, we do not want to expose any more information than is required. For that reason, be careful that error messages do not reveal too much information.
Application Layer Attacks
Some actors can target your system after they circumvent your secured access and data interface. For example, they could obtain authorization credentials via phishing. You’ll need to validate all data to prevent application layer attacks, such as:
- Cross-site scripting – Malicious scripts are injected into one of the request parameters
- Code injection – Inject valid code to services, such as SQL (SQL injection) or XQuery, to open the interface to user control
- Business logic –Allows the attacker to circumvent the business rules
- Parameter pollution attacks – Exploit the data sent in the API request by modifying the parameters of the API request
Apply strict input validation as you would on any interface, including:
- Restrict, where possible, parameter values to a whitelist of expected values
- To facilitate a whitelist, have strong typing of input value
- Validate posted structures data against a formal schema language, to restrict the content and structure
- Blacklist risky content, such as SQL schema manipulation statements
Log all API access. This is essential to assist resolving any issues. From these logs you can easily monitor activity and potentially discover any patterns or excessive usage activity.
Security Framework
Consider using an existing API framework that has many of the security features built in. If you must develop your own, separate out the security portion from the application portion. In this way, security is uniformly built in and developers can focus on the application logic.
After all that don’t neglect to allocate resources to test security of the APIs. Make sure to test all the defenses mentioned in this article.
What’s Ahead?
Incapsula builds security into its API design and infrastructure from the beginning. We will discuss the details in a future blog.
Try Imperva for Free
Protect your business for 30 days on Imperva.
