As we write in our blog, 95% of API Breaches are Caused By This, most security vulnerabilities in your API are related to “functional errors” or “human errors.” The actual act of hacking is rarely involved in most of the major API breaches you’ve seen or read about in our blog.
What is important to note is that there are functional tests that can help you capture some of those vulnerabilities before they are pushed live. But before we go into detail, we want to reiterate that we strongly recommend functionally testing your APIs before release, and then also use your functional tests as monitors. Many API errors don’t reveal themselves until a live environment with production data is tested.
We can designate these types of tests into three types – fuzz tests, authentication/access control, and sensitive data. We have created example test snippets that you can load from within the platform to see them in action.
PLEASE NOTE: These snippets are just examples to help convey the information more clearly. They are not meant to be security tests themselves. Only you can understand the business requirements and potential weaknesses in your APIs.
- 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.
[Found in Examples > Security > Invalid_Input_Test]
- 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.
[Found in Examples > Security > Wildcard_Test]
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.
[Found in Examples > Security > Password_Test]
- 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.
[Found in Examples > Security > Brute_Force_Test]
- Authentication Flow
It is important to create tests that validate your authentication flows. This can even include 3-leg OAuth using 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.
[Found in Examples > Security > Access_Control_Test]
- 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.
[Found in Examples > Security > Header_Validation_Test]
- 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.
[Found in Examples > Security > Sensitive_Information_Test]