Performing Security Audits on API Definitions
How to be pro-active with API Security
The use of APIs is continuously rising, especially due to the move towards a microservices architecture. This is made evident by the fact that, according to a recent report published by Akamai, 83% of all web traffic is now API traffic compared to the mere 17% taken up by HTML traffic. This shift in the traffic types means that many security tools in use today are not capable of dealing with the security threats and loopholes API traffic bring about with them. This is further emphasized by the Gartner research report which stated that APIs will be the “most frequently attacked vector for enterprise web application data breaches” by 2022.
A recent example would be Hostinger, the web hosting platform, which experienced a major breach into its internal system API by an unauthorized third party in late 2019. The server had contained an authorization token that was used by a public API to gain further access via escalated privileges to the internal RESTful API Server, which was used to query the details about Hostinger’s clients and their accounts.
The database accessed by the unauthorized third party included client usernames, emails, hashed passwords, first names and IP addresses of approximately 14 million Hostinger users.
The news of this breach spread overnight and resulted in a lot of negative publicity to Hostinger, especially with customers accusing Hostinger of misleading them about the scope of the breach and not being clear on the security of their financial data.
A lot of the data breaches like the above that occur could easily be mitigated using rigid API Definitions.
How can we make rigid API Definitions?
The first step that can be taken towards maintaining solid API Definitions is to make sure the API Definitions conform to the OpenAPI Specification (OAS), previously known as the Swagger Specification.
OAS defines a standard, language-insensitive interface for RESTful APIs that are both human and machine-readable. It is a common standard with a large set of community-developed tools to support developers using OpenAPI. Since the OpenAPI Specification contains a set of rules and best practices, ensuring an API Definition follows OAS will help eliminate well-known issues and loop-holes of APIs.
However, having API Definitions that conforms to OAS is not sufficient to make sure APIs are secure. This is where taking the extra step of auditing the API Definition for any security loop-holes help.
This is why WSO2 API Manager has partnered with 42Crunch, an enterprise API security platform, to bring in the ability to conduct a security audit on the API Definition and to obtain a detailed audit report in order to guide users to identify and eliminate any existing security loopholes in an API. This feature is available in API Manager v3.1.0 onward.
The following is an example of the report that will be generated for an API inside WSO2 API Manager after a security audit.
This report is divided into 4 sections:
- Audit Score and Summary
- OpenAPI Format Requirements
- Security
- Data Validation
Audit Score and Summary
This section provides an overall score out of 100 for the API Definition that was audited. The recommended score for an API is above 70 out of 100. If it is lower than that then there are some serious issues in the API Definition that has to be fixed as soon as possible!
The summary also provides the total number of errors, the overall severity of the vulnerabilities present in the API Definition and the scores given to the Security and Data Validation sections.
Note: The issues present in the OpenAPI Format Requirements section is not taken into account when calculating the score for the Security Audit Report. The Security section has a maximum score of 30 and the Data Validation section has a maximum score of 70, making up a maximum score of 100.
OpenAPI Format Requirements
This section presents any issues that arise when the API Definition does not adhere to the OpenAPI Specification. The issues found here are divided into three categories:
- Structural Errors
Errors under this category occur when the API’s structure does not comply with the OpenAPI Format. Since these errors are critical, the API Security Audit will not take place until these errors are resolved.
2. Semantic Errors
OpenAPI contracts that are structurally correct may have issues with the semantics of the fields in them. For example, more than one parameter could have the same name + in combination and invalid email and URL formats.
3. Best Practices Issues
The OpenAPI Specification includes some requirements that are not mandatory but are highly recommended to maintain the level of standard and ethics with regards to the API Definition. If these types of requirements are not met, they will be shown under this category.
Security
This section focuses on finding security issues laden in the API Definition.
If the API Definition already has security loopholes it makes no sense to apply other security measures on top of that since it will be only a matter of time before the API is breached. Thereby, the first step to take against this from happening is to make sure that an API conforms to the security best practices.
There are 3 areas where problems in Security are checked by the audit, namely: Authentication, Authorization, and Transport.
Data Validation
The Data Validation section checks whether there is inadequate validation of input and output in the API Definition. The most common errors in API Definitions occur here so it is as important as the other 2 sections when it comes to securing an API Definition.
If what the API accepts as input is not defined, then it allows for attacks like SQL injections and buffer overflow, both of which can cause catastrophe within an organization.
On the other hand, if what the API can include in the responses it sends out is not defined, then the API could leak information (possibly sensitive) that could either be used to carry out more severe targeted attacks or they could be exposed on the dark web for other hackers to exploit.
There are 4 areas where problems in Data Validation are checked by the audit, namely: Parameters, Response Headers, Response Definition, and Schema.
In addition to displaying a list of all the issues found, you are also able to view the exact place in the API Definition where each issue can be fixed and also visit the Encyclopedia offered by APISecurity.io (by 42Crunch) for a theoretical breakdown of the issue and how it can be fixed, as shown below.
What are the benefits of this Security Audit Report?
The Security Audit Report that is generated allows API Developers to check for issues in various aspects of an API Definition, including but not limited to API Security and Best Practices, at the design stage of an API.
If any issues persist, detailed information is provided to resolve such issues and what consequences they would pose if not fixed and the API Developers are able to use the built-in Swagger Editor in WSO2 API Manager to edit the API Definition. Upon saving the edited API Definition, developers are provided the option to run the Security Audit again on the API in order to see any improvements in the score.
Moreover, the fact that the report showcases the impact that each of the issues has on the overall score of the report and the severity level of each issue allows developers to easily prioritize what issues need to be addressed first. If this feature is used to its full potential, then it will make sure that pro-active measures are taken to ensure that APIs are secure even before being deployed to a run-time environment. Thereby helping to mitigate a significant amount of potential vulnerabilities in an API at its design stage.
In this article, you learned why we need to think more about securing APIs by taking an example and looking at the consequences of not doing so and why making rigid API Definitions is an important way you can secure APIs before they are even deployed in a run-time environment.
You were then introduced to the integration between WSO2 API Manager and 42Crunch to bring in the ability to perform a Security Audit on an API Definition and the features of the report it generates.
Finally, you learned how this Security Audit Report could benefit in maintaining rigid API Definitions, thereby tightening the security of APIs.
