APIs enable applications to exchange and consume data and services. Due to their ability to access an organization's data, APIs are an attractive target for hackers and threat actors. Organizations must secure their APIs to protect enterprise resources, as well as other applications and organizations that use the API.
API security testing checklist: 7 best practices
The following best practices will help ensure an API security testing program is thorough and complete.
1. Establish who has overall responsibility for testing and maintaining API security.
Many teams are involved in the lifecycle of an API, 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 and ensure all tests are completed and results are acted upon.
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 will highlight potential API risks and vulnerabilities that need mitigation, but note that a budget for maintaining and updating API tests once the project is live is necessary, too.
3. Register, classify and document the purpose of each API and how it should function.
Documenting APIs and their use is key. Using information from these documents, tests can 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 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, tests should be run on each build of the application.
5. Define the types of tests to run.
Each API should be subject 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. Check 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 may 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 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 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.
Test reports should be sent to a designated person to ensure warnings and errors get fixed. Then, retest to ensure the updated code fixed the problem.
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.
APIs are some of the most exposed components of a network and have come under attack as of late. Due to their rising security risks, API testing must be at the heart of any project.