Protect APIs against attacks with this security testing guide
API security cannot be overlooked. Learn how security testing can detect API vulnerabilities and weaknesses before attackers can take advantage of them.
APIs are the core of modern application architecture and provide access to an organization's data and resources. This makes them an attractive target for hackers.
API weaknesses and vulnerabilities can lead to unauthorized access, data manipulation and loss, and malware installation and can even negatively affect other applications and organizations using those APIs.
Protecting APIs is a growing challenge. Verizon's "2021 Data Breach Investigations Report" found that web applications were the top attack vector in more than 80% of cases. Similarly, Gartner predicted that APIs will become the most commonly targeted vulnerability by 2022.
What to look for in API security testing
APIs need security controls, such as authentication, access permissions and encryption, added to the earliest stages of development. Validating controls and the workflow of APIs is critical to ensure API endpoints and connected applications can withstand attacks.
API security testing begins by defining the target API. Using standards, such as the OpenAPI Specification, AsyncAPI and GraphQL Introspection, enables humans and machines to discover and understand the capabilities of a service without access to source code, documentation or network traffic inspections. Many testing tools use these specifications to generate code, servers, clients, tests and documentation to speed up an API's development lifecycle.
API security testing does two things:
- ensures the API works as designed; and
- ensures the API cannot be used to do anything else.
This means the basic outcome for any API test is, for a given input, the API must provide the expected output. Inputs sent via API must be handled as from an untrusted source and validated and sense-checked, accordingly. It is not easy to test that all possible input permutations, headers, access tokens, data types and values produce the correct output, however, which would be anything ranging from an error message to a complex data payload.
Testing must also ensure APIs don't contain vulnerabilities, such as those listed in the Open Web Application Security Project API Security Top 10:
- broken object level authorization
- broken user authentication
- excessive data exposure
- lack of resources and rate limiting
- broken function level authorization
- mass assignment
- security misconfiguration
- improper assets management
- insufficient logging and monitoring
To further complicate the matter, the number of APIs used in enterprise environments is growing exponentially, and many organizations are unsure of the APIs created and in use.
Automating API security testing
The only way developers and testers can ensure each API is comprehensively analyzed is to automate the generation and running of tests.
There are three main types of API security tests:
- Static application security testing (SAST). Manual or automated SAST tools review API source code to identify potential vulnerabilities. SAST tools must understand the language and data types used in the API.
- Software composition analysis (SCA). SCA tools check the libraries and third-party components used by an API for known vulnerabilities. However, SCA tools cannot determine if a vulnerability is exploitable within the API or whether a security flaw has been introduced by the development team while integrating a third-party component.
- Dynamic application security testing (DAST). DAST tools send both positive requests (acceptable action and valid data) and negative requests (unacceptable actions or invalid data). Positive test cases ensure users can perform appropriate actions. Negative test cases check whether an API can gracefully handle invalid data or unexpected and unacceptable actions without breaking, executing undefined behavior or returning error messages that reveal information that could be useful to an attacker.
While all these tests should be completed, DAST is the most important to get right, and dedicated API testing tools are essential. Conventional DAST scanners are unlikely to be able to effectively invoke and test all of an API's endpoints, whereas specialized API scanners understand what an API for a single-page web app, IoT device or mobile app expects and can thus test it thoroughly and check to ensure it is consistent with published specifications.
DevSecOps and API security testing
Many teams run API security tests as part of the continuous integration/continuous delivery (CI/CD) pipeline to ensure security issues are caught early in the development lifecycle. This makes security part of development, which has the benefit of shifting security left.
Standalone on-premises products are great for scanning internal APIs. Mock local or internet API servers can imitate a real API server by providing realistic responses to API requests. Most tools can also handle API authentication requirements and fully scan all endpoints to identify authorization and authentication bypass issues.
There is a wide variety of API security testing tools to choose from. It is important to understand which features are most effective for a particular team or project.
Use tools that can automate testing CI/CD pipelines to ensure developers are alerted of potential errors or vulnerabilities when they try to commit or make a pull request. Developers should explicitly test their own APIs. Their tools should also discover API routes via crawling and proxying staging and production traffic to ensure no API routes are missed.
Testing can be complicated by the fact that teams push new code several times a day. Development teams must consider the time it takes to run API security tests, especially when run in the CI/CD pipeline. Too many false positives can cause frustration and erode trust in the testing process, so fine-tuning configurations is important.
When selecting a tool, ensure it supports all types of APIs, including REST APIs, GraphQL and Simple Object Access Protocol. Even if they are not used presently, they may be in the future.
Complex projects need the ability to chain requests, where a test has multiple HTTP requests, using values from one request in the next one.