What Is API Security?
An application programming interface (API) is a set of definitions and protocols you can use to enable communications between applications. With APIs, you can transfer information between applications and services without understanding how the apps operate internally.
Organizations use APIs to integrate services and transfer potentially sensitive information. If the communications across APIs are intercepted, this information can be manipulated, lost, or stolen. Depending on what information is being passed and to whom, security may be a minor, major, or critical concern. In particular, APIs that transfer authentication information, banking data or payment card information (PCI) need special attention to security.
In this article, you will learn:
- 4 Quick Ways to Test if Your API is Secure
- 1. Parameter tampering
- 2. Injection
- 3. Input Fuzzing
- 4. Unhandled HTTP Methods
- API Security Best Practices
- Security by Obfuscation
- Secure APIs using Extended Detection and Response (XDR)
- Implement OAuth2
- Implement Rate Limits
- Beyond the Basics — Achieving Robust API Security with Reblaze
4 Quick Ways to Test if Your API is Secure
When implementing an API, you must ensure it is secure, both for your organization’s protection and to protect the privacy of your users.
The most important practice is code review. Many errors can, and should, be caught before the API goes into production. Unfortunately, many organizations do not place enough emphasis on this; nevertheless, it is dangerous to neglect this important practice.
Having said that, once an API is live, it should still be tested. Below are four tests you can use to verify your API security and identify areas of vulnerability.
1. Parameter tampering
Parameter tampering is when an attacker changes the values in an API request. This type of attack takes advantage of hidden parameters used in API requests to pass “secure” information. For example, this could be used to change the purchase price of a product by changing the value assigned to the price or cost parameter.
To test if parameter tampering is possible, you can examine any API related elements in your site or web app through the development console in your browser. If you change the value in your console, submit it with the included change, and the application accepts it, your API is not secure.
An injection attack occurs when an attacker inserts hostile input into an API. A common example is SQL injection, where SQL queries or commands are submitted, in the hope that they will be run against the backend database.
Another common example is command injection, where an attacker inserts commands into a request or input. When processed, these commands are read by the receiving system as separate from the request, and are executed as standalone commands.
Attackers can use these attacks for many malicious purposes, including gaining access to systems through privilege escalation, rebooting devices, or deleting data.
To test if your API is vulnerable to command injection, you can try submitting a request like the following:
This request, if successful, would reboot a Linux-based system. It is good to perform this test with various system types and command content. This can ensure that your requests are being properly validated and that injections aren’t possible. When performing these tests, take care not to test harmful commands in your production system to avoid damage.
3. Input Fuzzing
Input fuzzing is performed by providing random information to an API through automation until an unexpected effect occurs. Often, the application will crash. Other effects might include an error message indicating that an input was partially valid.
When performing fuzz tests, the two most common inputs to target are numbers and strings. To test number inputs, you should try submitting numbers outside the expected range, such as negative numbers, very large numbers, or decimal numbers. To test strings you can send very large strings, or strings with unexpected unicode.
Fuzzing reveals an application’s vulnerability to being remotely crashed by an attacker. It is unlikely to reveal significant weaknesses that an attacker could exploit, but is stlil useful in testing the robustness of an application
4. Unhandled HTTP Methods
Many APIs use HTTP to transfer request data through methods for saving, retrieving, or deleting data. However, depending on the server you’re using, methods that you don’t intend to be used might be allowed by default. For example, servers might allow users to use the HEAD method to bypass authentication, if you have not disallowed it.
To test if unsecure or unintended methods are allowed, try sending requests with known but unused and arbitrary methods. If either gets a valid response rather than an error (such as 405 or 501) you need to block those methods.
API Security Best Practices
In addition to the above tests, you can use several best practices to ensure the security of your APIs. These practices can help obscure vulnerabilities, detect or prevent attacks, and ensure the validity of users.
Security by Obfuscation
Your goal should be to make vulnerabilities as difficult as possible to find for an attacker. To do this, you need to ensure that you do not provide valuable information about your application’s inner workings through error messages. This means you need to make error messages and failed responses clear without providing extra information.
For example, if an attacker inputs an incorrect password and username combination, your error message should state only that. It should not supply information about which part of the combination was wrong or whether they are a valid user in your database.
Note: Although obfuscation is necessary, it cannot really accomplish much. Attackers often have access to client code, from which much can be learned about the structure and operation of the API. Therefore, although you should obfuscate as much as you can, you should also ensure that more robust security measures are taken.
Secure APIs using Extended Detection and Response (XDR)
XDR Security solutions offer technology that monitors endpoints (such as an APIs), detects malicious activity, and responds to potential incidents. These solutions can help you ensure that users are properly authenticated, IP addresses are filtered, access controls are applied, and inputs are validated.
XDR can also be used for active threat hunting, which involves investigating API endpoints across an organization, looking for security weaknesses, or endpoints that may have already been compromised by attackers.
OAuth2 is an open source framework you can use to authorize your user access and ensure that user sessions are appropriately limited. This framework can be combined with a variety of authentication protocols to enable user validation as well.
To properly secure your API, you need both authentication and authorization. One method for this is to also implement OpenID Connect. This protocol layers on top of OAuth2 to provide authentication and enables you to obtain user profile information.
Implement Rate Limits
Rate limiting restricts the number of requests that users can make in a given period. When the number of requests exceeds the limit—for example, 100 per minute, the user is not allowed to make additional requests.
Rate limiting is important for several reasons. First, a common method of attacking an API is to overwhelm it with requests. Rate limiting will prevent this, and it will ensure that the API remains available to legitimate users. Second, rate limiting will prevent other forms of attack as well. For example, an attacker might attempt to stuff credentials into a login form, or try to defeat 2FA (two-factor authentication) by iterating through and submitting all possible confirmation codes. In these situations, rate limiting will prevent the attacker from succeeding.
Beyond the Basics—Achieving Robust API Security with Reblaze
For robust API security, the tips above are just the beginning. Attackers can abuse an API in countless ways, from ‘mass assignment’ to slow DoS attacks to subtle exploits of the targeted application itself.
Effective API security is even more challenging in modern development environments. DevOps and other practices enable the rapid creation and delivery of new features, which often expand the size and complexity of existing APIs. Unfortunately, as APIs evolve, so do their potential attack surfaces, and many WAF solutions cannot dynamically adapt to new traffic structures. These solutions require manual retuning each time an API grows or changes.
Reblaze offers full, dynamic API protection as part of its all-in-one web security solution. Its features include:
- A client-side SDK ensures mobile/native application traffic is TLS encrypted and continuously authenticated. All communications include an HMAC signature (a cryptographic identity mechanism on the client side) to harden communications between the application and the endpoint, ensuring that only requests from legitimate users are accepted.
- API schema ingestion, validation, and enforcement provides automated protection.
- Reverse-engineering prevention stops API attacks in their earliest stages.
- UEBA (User Entity and Behavioral Analytics) and Machine Learning are used to construct behavioral profiles of legitimate API users. This defeats even subtle application-abuse attacks, which are difficult to codify as threat signatures and security rulesets. By definition, even when attackers masquerade as legitimate users, they must eventually deviate from valid user behavior. When they do, Reblaze detects the deviation and blocks them.
- Dynamic and adaptive traffic recognition allows Reblaze to reshape its security posture in response to changes in traffic structure. As an API evolves, Reblaze’s behavioral profiles evolve with them.
Reblaze’s cloud security services are fully compliant with PCI DSS, GDPR, SOC 1/SSAE 16/ISAE 3402, FISMA Moderate, ISO 27001, FIPS 140-2, HIPAA, CSA (Cloud Security Alliance), and other standards and certifications.
Reblaze Technologies is ISO 27001 Certified, AICPA SOC 2 Certified, and is a PCI DSS Certified Level 1 and Level 2 Service Provider.