API security is an undervalued but crucial aspect of information security. Some of the most common cyber attacks exploit APIs and web applications, and if organisations are to stay secure, they must test their systems to identify and eradicate weaknesses.
Organisations can achieve this with API penetration tests. An ethical hacker (or ‘penetration tester’) will examine your applications using the same techniques that a cyber criminal would use. This gives you a real-world insight into the way someone might compromise your systems.
Web application and API tests look specifically at security vulnerabilities introduced during the development or implementation of software or websites. There is no single checklist of how exactly the test should be conducted, but there are general guidelines.
Benefits of API penetration testing
The primary purpose of an API penetration test is to protect your organisation from data breaches. This is crucial given the increased risk of cyber attacks in recent years; according to a UK government report, 39% of surveyed organisations said they suffered a security breach in the past year.
By conducting an API penetration test, you will gain a real-world overview of one of the biggest security threats that organisations face. The tester will use their experience to provide guidance on specific risks and advise you on how to address them.
But penetration tests aren’t only about closing security vulnerabilities. Mitigating the risk of security incidents has several other benefits. For instance, you protect brand loyalty and corporate image by reducing the likelihood of a costly and potentially embarrassing incident.
Penetration testing also helps you demonstrate to clients and potential partners that you take cyber security seriously. This gives you a competitive advantage and could help you land higher-value contracts.
Perhaps most notably, penetration testing is a requirement for several laws and regulations. Article 32 of the GDPR (General Data Protection Regulation), for example, mandates that organisations regularly test and evaluate the effectiveness of their technical and organisational measures employed to protect personal data.
Likewise, if your organisation is subject to the PCI DSS (Payment Card Industry Data Security Standard), you must conduct external penetration tests at least once per year and after any significant changes are made to your systems.
API penetration testing checklist
IT Governance has its own proprietary checklist when conducting API and web application penetration tests.
The system is modelled on the OSSTMM (Open Source Security Testing Methodology Manual) and the OWASP (Open Web Application Security Project) methodologies.
A high-level overview of our process is outlined below, with a brief description of what is assessed during each section.
1. Authentication
The penetration tester ensures that appropriate mechanisms are in place to confirm a user’s identity. They then review how the authentication process works, using that information to circumvent the authentication mechanism.
2. Authorisation
The tester verifies that access to resources is provided only to those permitted to use them.
Once roles and privileges are understood, the tester attempts to bypass the authorisation schema, finding path-traversal vulnerabilities and ways to escalate the privileges assigned to the tester’s user role.
3. Session management
The tester ensures that effective session management configurations are implemented. This broadly covers anything from how user authentication is performed to what happens when logging out.
4. Input validation and sanitisation
The tester checks that the application appropriately validates and sanitises all input from the user or the environment before using it.
This includes checking common input validation vulnerabilities such as cross-site scripting and SQL injection, as well as other checks such as file uploads, antivirus detection and file download weaknesses.
5. Server configuration
The tester analyses the deployed configuration of the server that hosts the web application. They then verify that the application server has gone through an appropriate hardening process.
6. Encryption
The tester assesses encryption security around the transmission of communication. This includes checking for common weaknesses in SSL/TLS configurations and verifying that all sensitive data is being securely transferred.
7. Information leakage
The tester reviews the application configuration to ensure that information is not being leaked.
This is assessed by reviewing configurations and examining how the application communicates to discover any information disclosure that could cause a security risk.
8. Application workflow
The tester determines whether the application processes and workflows can be bypassed.
Tests are conducted to ensure that application workflows cannot be bypassed by either tampering with the parameters or forcefully browsing. This ensures the integrity of the data.
9. Application logic
The tester analyses how the application uses, stores and maintains data. They do this by checking the underlying technology and any mitigating controls that may affect the risk to the application.
10. Report
The tester documents their findings. Their reports contains an executive summary, which provides a high-level, non-technical summary of any identified vulnerabilities, alongside a summary of the organisation’s business risks and an overall risk rating.
It also contains a comprehensive review of testing details, such as the scope of the assessment, descriptions of the vulnerabilities identified and their impact, plus proofs of concept that support the findings.
Finally, the report provides the tester’s commentary, where they discuss the issues identified and how the vulnerabilities could be linked within an attack chain. This is supplemented with remediation advice and supporting references.
