WSO2 API Manager 3.1: API Audit for Security

APIs have become a strategic necessity for businesses of all kinds. They facilitate agility and innovation. As the demand for APIs is on the rise, API security is critical to businesses because these interfaces often expose sensitive data and expose the organization’s internal infrastructure to misuse. As APIs are being consumed by a wide range of devices and services, API developers need to ensure their APIs follow security best-practices before they are published to their consumers. Manual verification of API can often overlook security vulnerabilities and can result in API exploitation by malicious users and other cyber security attacks. Automated validation of API contracts and API implementation for security best practices during the early stages of design/development can be a lifesaver to avoid security issues for API implementations. 

Earlier this year Yenlo has formed a partnership with 42Crunch, a company offering an Automated API Security Threat Protection Platform that audits your APIs, continuously validates them against security policies and can actively protect those APIs against malicious threats and injections. Now with the new release of WSO2 API Manager 3.1.0 the security audit capability of 42Crunch has been integrated into its Publisher portal. This provides the ability to conduct a security audit on an API definition and obtain a detailed audit report for any existing gaping security holes in an API during design / development stages.

API Security audit from Publisher portal can perform static analysis on the API definition and by splitting the issues into 3 categories.

1. OpenAPI format

Is your API a valid and well-formed OpenAPI file, and does it follow the best practices and the spirit of the OpenAPI Specification? Can it be correctly parsed, reviewed, or protected?

For eg: OpenAPI spec recommends that you need to have defined servers for your API. It shows as an issue if you have not defined at least one server for your API in the top-level servers field.

"servers": {
 
 }

Remediation would be to make sure that you have defined at least one server for your API.

"servers": {
 "url": "https://my.api.server.com/",
 "description": "My API server"
 }

2. Security

How good are the security definitions in your API? Have you defined authentication and authorization methods, and is your chosen protocol secure enough?

For eg: It highlights risk if the host server of the API accepts unencrypted connections using the HTTP protocol, as HTTP traffic is not encrypted and can thus be easily intercepted.

{
"servers": [
 {
 "url": "http://my.api.com"
 }
 ]
}

Remediation: use only secure connections (using HTTPS) for the servers to avoid anyone listening to the network traffic while the calls are being transmitted through unencrypted HTTP connections.

{
"servers": [
 {
 "url": "https://my.api.com" 
 }
 ]
}

3. Data validation

What is the data definition quality of your API? How well have you defined what data your API accepts as input or can include in the output it produces, and how strong are the schemas you have defined for your API and its parameters?

For example: It highlights an issue if you have not defined any schemas for responses that should contain a body.

 "get": {
 "description": "Returns menu items from the system that the user has access to",
 ...
 "responses": {
 "200": {
 "description": "OK"
 }
 }
}
 

Remediation: Define schemas for all responses that should have a body.

 "get": {
 "description": "Returns menu items from the system that the user has access to",
 ...
 "responses": {
 "200": {
 "description": "Menu items",
 "schema": {
 "type": "array",
 "additionalProperties": "false",
 "items": {
 "$ref": "#/components/schemas/Menu"
 }
 }
 }
 }
}
 

Scores and severity levels are displayed by each of these categories to make the report easier to understand.

The reports also provide a description of the issue and suggest a remedy to fix the issue by pointing to the API Security encyclopedia that contains details on the vulnerability and how it can be fixed. Developers can apply fixes on the built-in Swagger editor in WSO2 API Manager (APIM) to edit the API Definition. They can re-run the Security Audit on the API in order to see any improvements in the score. 

In order to enable the Audit API feature on WSO2 APIM 3.1, you need to be a registered user for the 42crunch platform. This allows you to create tokens that can be used in API Manager configurations to enable Audit API features.

After you enable the Audit API feature, you can execute the following steps to audit an API:

1. Navigate to the API Publisher: https://localhost:9443/publisher

2. Click on the API that you need to audit.

3. Go to API Definitions. (The Audit API button will only appear if API Auditing is enabled.)

4. Click “Audit API”. An audit report is displayed.

Below gif shows how you can audit API’s and identify security issues.  

Summary

API security is critical. Security should be “designed in” rather than added as an afterthought. The Audit API feature in WSO2 API Manager 3.1 can automate security audit of APIs during design time. Reach out to our guru team, if you need help securing your APIs or conduct a security review of APIs or API platform, we can even take these checks a step further by doing automatic scans and add another protection layer in the form of an API firewall for your APIs.

{{cta(‘6d4fc2fb-4032-414f-88fc-25f5e81f5d0f’,’justifycenter’)}}