API Penetration Testing

Web APIs are core to the operation of web applications, mobile applications, and interactions between other systems. Weaknesses in these APIs can lead to loss of sensitive information, damage to the brand’s image, denial-of-service, and loss of revenue.  

We assess the security posture of your API. We identify risks and security issues and provide recommendations on how to address these security issues to harden the API to make it resilient to compromise. The primary source of our web application assessment methodology is the OWASP Web Security Testing Guide (WSTG) and Mobile Application Security Testing Guide (MASTG). However, reliance on a static resource would result in vulnerabilities being missed. As a result, we use a combination of our own experience and techniques. We stay up to date with cutting-edge research, resulting in a hybrid testing methodology.

To fully test modern web services and APIs, it is essential that highly skilled and experienced security consultants are deployed. Purely automated scanning can rarely be used due to the nature of web services, and when it can be used, it cannot provide good coverage of complex APIs and is prone to showing many false positive and negative findings. Skilled manual testing ensures excellent coverage, drawing on the consultant’s experience to uncover even deeply hidden issues.

What should be covered as part of an API Security Assessment?

A web API penetration test includes an assessment of the security of data transmission, proper implementation of authentication and authorisation controls, verification of data input, handling, and output, and thorough examination of HTTP methods and status codes. 

APIs should be tested for vulnerabilities such as injection flaws, cross-site scripting, XML external entity attacks, and insecure  deserialisation, among others. 

Additionally, a thorough penetration test should inspect the usage of third-party components and libraries to ensure they do not have known vulnerabilities. 

Lastly, the penetration test should also review logging, monitoring, and alerting practices to verify the system’s ability to detect and respond to security incidents promptly. 

We recommended that all web applications are tested at least once a year and after major code changes.

For systems that require a high level of security assurance, a code review can be carried out alongside testing of the API.

Areas of testing should include:

Broken Object-Level Authorization

• Excessive data exposure 
• Broken authentication
• Lack of rate limiting and resources
• Injection vulnerabilities
• Security misconfiguration
• Server-side request forgery
• Insecure business logic

Reporting 

A report is written detailing the processes carried out and the issues found. Generally, this will contain a prioritised list of vulnerabilities discovered grouped by functional area. Remediation advice will be provided, both in terms of an immediate fix and any defence-in-depth measures that could be taken to mitigate risk. Attack chains, alongside their impact, will be documented. 

Any higher-level findings that can be abstracted from the testing will be provided. Any architectural or design weaknesses will be highlighted so that these can be avoided in the future. Finally, an executive summary is produced to allow the most severe issues to be communicated quickly to stakeholders.

High and critical risk vulnerabilities

It is our policy to directly contact the designated client contact upon the discovery of a high or critical risk vulnerability, or one which poses an immediate threat to the environment or its users. Direct contact is made through email or phone with a detailed description of what the vulnerability is, how it would be exploited by an attacker, and how to remediate it.

Example attacks from previous engagements

To illustrate the type of real-world attack, these are some possible attacks based on previous tests carried out across a range of API security assessments:

An endpoint used as the primary authorisation route of an API was found to be protected by a robust account lockout policy. During testing, the consultant identified that an alternate endpoint, which was used for a “Current Password” check on the password reset mechanism, was not protected by the same account lockout policy. Due to a combined lack of rate limiting and account-wide lockout policy, the consultant was able to brute force several developer test accounts during the engagement which were found to have weak passwords set.

A common API framework was found to be in use. Using a list of known files from the Open-Source project, a brute-force search of the API was carried out. This uncovered several diagnostic pages exposing environment variables for the project, including credentials for the internal APIs that were consumed by the one being tested. Network scanning indicated that these were not exposed to the Internet. Further testing of the API found that it was possible to carry out server-side request forgery, allowing the credentials to be used against the internal APIs. This resulted in complete access to the underlying dataset that the API was intended to protect.

Common vulnerabilities can include:

Insecure Direct Object reference vulnerabilities, where object-level authorization has not been implemented correctly

Lack of rate limiting leading to brute force or availability issues

Injection vulnerabilities such as, but not limited to, NoSQL, SQL injection, and XXE

Broken authentication, such as flaws in user authentication or session management

Undocumented and unknown endpoints that can expose insecure methods to attackers

Insecure  deserialisation, where an attacker can execute code by passing crafted data in serialised objects

Weak encryption configuration leading to unnecessary risk that data is intercepted or tampered with in transit

Use of out-of-date or known vulnerable components that could be exploited to gain access to data or the underlying system