4. Functionally Test the Security of an API

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…

2. The IF Component

One of the most powerful components in API Fortress (and in programming) is the IF. This gives you the flexibility to create assertions that can be specific to certain conditions. For example, IF statuscode==200 vs statuscode=400. Meaning you can create positive and negative validations in a single test.

3. Dealing with Authentications

API Fortress can handle just about any sort of authentication scheme your API is using, including simple, oAuth, etc… The only authentication that is a problem is because that is specifically built to not allow for automation. We have details on that here.