APIs enable applications to exchange and use data and services. Because of their ability to access an organization’s data, APIs are attractive targets for hackers and threat actors. Organizations need to protect their APIs to protect corporate resources and other applications and organizations that use the API.
API Security Testing Checklist: 7 Best Practices
The following best practices will help ensure that an API security test program is thorough and complete.
1. Determine who has overall responsibility for testing and maintaining API security.
There are many teams involved in the life cycle of an API, and the project will go through many rapid changes and iterations as it progresses. It is important to have someone who will document all APIs and ensure that all tests are completed and that there is action on the results.
2. Budget time and resources for security testing.
Security testing takes time and money, so companies need to consider these factors when starting a new project. Threat modeling will identify potential API risks and vulnerabilities that need to be mitigated. Note, however, that a budget will also be required to maintain and update API tests once the project is live.
3. Register, classify, and document the purpose of each API and how it works.
Documenting APIs and how to use them is key. Using the information in these documents, tests can assess whether an API can handle acceptable actions and valid data, as well as unacceptable actions or invalid data. Standards like the OpenAPI specification, AsyncAPI and GraphQL Introspection enable humans and machines to discover and understand API functions. Many API tools use these specifications to speed up the development life cycle of an API.
4. Run tests early and automate them if possible.
Everyone saves time and money when security issues are identified early in the development lifecycle. Numerous API security tools are available, both open source and licensed, that can be integrated into existing workflows and continuous integration / continuous delivery pipelines. Tools with mocking services eliminate the need to create full replicas of production systems.
Also determine who will run the tests – developers, the security team, or external pen testers if the in-house skills are not in place – and when to run the tests. Ideally, tests should be run on each build of the application.
5. Define the test types to be run.
Each API should be subjected to the following tests:
- Invalid entries. Input from an API should be treated as if it came from an untrustworthy source, and should be sanitized 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 that the API rejects requests that attempt to tamper with back-end databases or execute operating system commands on the server without disclosing sensitive information.
- Parameter manipulation. Parameters sent via an API request, such as the price of an item in a shopping cart, can easily be changed by an attacker. Make sure the API validates and checks parameters before processing them.
- Unhandled HTTP methods. Send requests using all eight HTTP methods to ensure that unnecessary methods such as CONNECT, DELETE, PUT, and TRACE are not allowed on the server. These methods pose a security risk if they return a valid response instead of an error. If an application requires either of these methods, make sure that its use is correctly restricted to trusted users.
- Vulnerabilities in business logic. Errors in the design and implementation of an API could allow an attacker to induce unintended behavior by interacting with the API in ways that developers never intended – for example, to complete 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 at each stage, will help prevent this type of vulnerability from being introduced.
- Authentication, access and encryption controls. Make sure that the sender of a request is authenticated with the server and authorized to access the requested resources. Implementing identity and authorization protocols like OpenID Connect and OAuth can be as difficult as managing associated keys and tokens. It is important to allow additional time to test these security controls.
- Excessive loads. Rate limiting controls – how often an API can be called in a period of time – help stop unapproved connections and protect against DDoS. Make sure these limits are set for optimal performance.
After all, error messages, log entries, and failover handling are important aspects of testing, so verification messages and logs are recorded after each test to verify the correct information.
6. Resolve tests that fail and try again.
Test reports should be sent to a specific person to ensure that warnings and errors are resolved. Then test again to make sure that the updated code fixed the problem.
7. Stay informed about security risks and update documentation.
Everyone involved in API creation needs to understand the latest techniques cyber criminals use to attack APIs so they can update code, security controls, and testing. The security team should keep everyone involved in the project updated with new threats and best practices.
APIs are among the most exposed components of a network and have been attacked recently. Because of their increasing security risks, API testing must be the focus of every project.
Comments are closed.