According to Gartner over 95% of security vulnerabilities in APIs are related to “functional” or “human” errors. That is why functional testing of your APIs is so important to general API security. A good API security policy includes testing of API functionality before release, as well as constant monitoring of those APIs using the same detailed functional tests.
Below we list some of the types of tests we suggest that will help you not be in the 95% of API breaches. PLEASE NOTE: This is by no means a comprehensive list, but a series of suggestions that will constantly be evolving.
Fuzz Tests:
- Invalid Input Test
The goal of this test is to validate how the API functions when given invalid data. Fundamentally, it’s a data-driven test with a series of invalid inputs that helps to reveal potential exceptions. Some of these exceptions may include crashes, assertion failures, error responses that give out too much information, and potential memory leaks. - Wildcard Testing
This one is pretty straightforward, and yet it is one of the reasons for a major breach at the US Postal Service. The goal here is to see how the API reacts when a wildcard (*) is used in place of an input value. For most APIs, it shouldn’t be allowed as it would return a broad dataset.
Authentication / Access Control:
- Common Logins
This test is meant to simply go through the most common username and password combinations to try to see if one of those is valid. This includes logins such as admin/admin. These tests are particularly useful before pushing an API live when you have internal credentials used for debugging. - Brute Force
This test randomly generates login credentials such as usernames and passwords in an attempt to brute force its way in. The goal here is to validate that the API only allows a certain amount of login attempts before forcing a timeout. - Your Authentication Flow
It is important to create tests that validate your authentication flows. This can even include 3-leg OAuth using something like our open source 3loa project. - Access Control
In this test, the goal is to confirm that a user with permissions of X can only achieve X. For example, in API Fortress, a person with “analyst” rights should only be able to view results and tests. They cannot edit tests or change settings.
Sensitive Data
- Header Validation
Headers contain critical details of the API transaction, but they can also sometimes contain sensitive information. In this test, we analyze the header and give some examples of potential weaknesses. This can include revealing an Apache server version that has a known weakness, or the authentication type. - Sensitive Information
In this test, the goal is to search for string patterns that should never appear in a payload, such as credit cards, and social security numbers, etc…