API security testing checklist: 7 key steps

API security testing checklist

The following best practices can help ensure an API security testing program is thorough enough to effectively protect against API security risks.

1. Establish who has overall responsibility for testing and maintaining API security

Many teams are involved in the API lifecycle, and the project will undergo plenty of rapid changes and iterations as it progresses. It’s important to designate a person to document all APIs, ensure all tests are completed and results are acted upon.

With an increasing emphasis on cloud services and web application environments, more business units and other application owners might be involved in API security governance than in years past. This makes it even more important to have a central point of contact.

2. Budget time and resources for security testing

Security testing takes time and money, so organizations need to consider these factors when starting a new project. Threat modeling highlights potential API risks and common vulnerabilities that need mitigation, but note that a budget for maintaining and updating API tests once the project is live is necessary, too.

Be aware that any APIs developed and maintained by third-party providers can change at any time. Security and application teams should ensure dynamic API tests are accommodated in planning and project cycles.

3. Register, classify and document the purpose of each API and how it should function

Document APIs and their use. This information helps tests assess if an API can handle acceptable actions and valid data, as well as unacceptable actions or invalid data. Standards such as the OpenAPI Specification, AsyncAPI and GraphQL Introspection enable humans and machines to discover and understand API responses and capabilities. Many API tools use these specifications to speed up an API’s development lifecycle.

4. Run tests early and automate them when possible

Everyone saves time and money if security issues are caught early in the development lifecycle. There are plenty of API security tools available, both open source and licensed, which can be integrated into existing workflows and continuous integration/continuous delivery pipelines. Tools with mocking services eradicate the need to build full-scale replicas of production systems.

Also, establish who is going to perform the tests — developers, the security team or external pen testers if lacking the skills in-house — and when the tests should be run. Ideally, run tests on each build of the application. Many API testing tools can now be wholly integrated for continuous or triggered testing on demand.

5. Define the types of tests to run

Subject API security assessments to the following tests:

• Invalid inputs. Inputs from an API should be handled as if they’re from an untrusted source and cleaned and validated accordingly. Fuzzing can be used to send random data to an API to see if it can handle unexpected data without crashing.
• Injection attacks. Use these test attacks to ensure the API rejects requests that try to manipulate back-end databases or execute OS commands on the server without exposing any sensitive information.
• Parameter tampering. Parameters sent through an API request, such as the price of an item in a shopping cart, are easy for an attacker to alter. Parameter tampering checks that the API validates and sense-checks parameters before processing them.
• Unhandled HTTP methods. Send requests using all eight HTTP methods to ensure unnecessary methods, such as CONNECT, DELETE, PUT and TRACE, aren’t allowed on the server. These methods pose a security risk if they return a valid response rather than an error. If an application does require one of these methods, ensure its usage is correctly limited to trusted users.
• Business logic vulnerabilities. Flaws in the design and implementation of an API can enable an attacker to induce unintended behavior by interacting with the API in ways that developers never intended — for example, completing a transaction without going through the intended purchase workflow. Testing for this type of vulnerability is often difficult with automated tools because the vulnerability is usually unique to the application and its specific functionality. Clear design and data flow documents detailing transactions and workflows, including assumptions made at each stage, help prevent the introduction of this type of vulnerability.
• Authentication, access and encryption controls. Ensure the originator of a request is authenticated at the server and authorized to access the requested resources. Implementing identity and authorization protocols, such as OpenID Connect and OAuth 2.0, can be difficult, as can the management of related keys and tokens. It’s important to allocate additional time to test these security controls.
• Excessive loads. Rate limit controls — the number of times an API can be called in a period — help stop unsanctioned connections and protect against DDoS attacks. Ensure these limits are set for optimal performance.

Finally, error messages, log entries and failover handling are important aspects of testing, so review messages and logs to check the correct information is recorded after each test.

6. Fix tests that fail and retest

Send test reports to a designated person to ensure warnings and errors get fixed. Then, retest to ensure the updated code fixed the problem. Vulnerability management teams should also plan for exceptions that need approval from responsible stakeholders. For any third-party APIs that don’t meet security requirements, develop a plan to coordinate with the service provider, and retest as needed.

7. Stay current with security risks and update documentation

Everyone involved in building APIs needs to understand the latest techniques used by cybercriminals to attack APIs so they can update code, security controls and tests. The security team should regularly update everyone involved in the project on new threats and best practices.

The OWASP API Security Top 10 list, which includes protecting against the following vulnerabilities, is a good place to start:

1. Broken object level authorization.
2. Broken authentication.
3. Broken object property level authorization.
4. Unrestricted resource consumption.
5. Broken function level authorization.
6. Unrestricted access to sensitive business flows.
7. Server side request forgery.
8. Security misconfiguration.
9. Improper inventory management.
10. Unsafe consumption of APIs.

APIs are some of the most exposed components of a network and have come under attack as of late, resulting in numerous data breaches. Due to their rising security risks, API testing must be at the heart of any project.

Dave Shackleford is founder and principal consultant at Voodoo Security, as well as a SANS analyst, instructor and course author, and GIAC technical director.

Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 20 years of experience in the IT industry.