API Security: Network Level Controls, Threat Protection & Content Based Security Checks

 

API Management plays a significant role in securing APIs. In previous blog-posts in this series, we introduced you to the need for securing APIs wit API Management and Authentication and Authorization aspects that can secure APIs, including how this can be achieved using industry-standard security design patterns. In this blog-post, we will go on with the security patterns and talk about Network Level Controls, Transport Security, Quality Of Service, Threat Protection and Content-Based Security Checks.

Securing APIs with Network Level Controls / Transport Security

Securing the data in transit

To ensure the utmost data integrity while exchanging the data between consumer, API Management platform and the provider, secure communications need to be established between these parties. Irrespective of which authentication and authorization pattern used, any inbound or outbound traffic from the API Management platform needs to be secured using SSL handshaking. SSL v3 must be used to avoid any vulnerabilities present in the lower version.

Two-way mutual certificate validation

Used in: Internal application or secure cloud-based application to Resource an API

Mutual SSL Authentication, also known as Client Certificate validation, is another popular security pattern to authenticate and authorize consuming applications to access the backend APIs via the API Management platform. Being considered as one of the most secure ways to access an API, mutual SSL authentication can only be used by the server-based consuming application. 

The consuming application must generate a certificate signing request (CSR) and send it to the organization security team to generate the client certificate and the private key. The consuming application then stores this information in its trusted key store. The certificate signing request must contain a unique client_id in its subject name. This client_id should also be registered in the API management platform as a registered consuming application. 

The consuming application wishes to access the backend API securely via the API Management platform, using two way mutual SSL authentication. On invocation, the API Management platform sends the server certificate details to the consuming application for verification. On successful verification, the platform demands the client certificate from the consuming application. The consuming application sends the client certificate, which is then parsed using the public key of the certificate, and verified by client_id from the subject name, to ensure that it’s a legitimate consuming application trying to access the API. On successful verification, API access is granted.

Quality Of Service / Threat Protection

Quality of service is a different mechanism in the form of API Management policies to ensure the service availability and performance are managed. It is also used to protect the service from possible misuse. Regardless of which authentication and authorization pattern used, the quality of service policies is always applied.

Concurrency Limit

This limits the number of concurrent requests that a consuming application or end-user can make towards the endpoint exposed by the API Management platform. The concurrency limit ensures that the number of concurrent requests doesn’t cross the limit mentioned at any given point in time.

Quota Limit

This limits the number of requests that a consuming application or end-user can make towards the endpoint exposed by API Management in a given time frame duration.

Denial Of Service

This blocks the traffic coming from a list of IP sources or a particular domain. The API Management platform offers a wide range of rules and policies to mitigate Denial Of Service attacks. Blacklisting IPs and domains halts traffic from a source or payload when bigger than a particular size. Various combinations can be used to mitigate Denial Of Service attacks. It is highly recommended to use industry-standard products like Arbor or equivalents for handling denial of service attacks in conjunction with this policy.

Content-Based Security Checks

Content-based security checks are a mechanism to filter out the malicious content present in the request body. Sometimes it is possible for a rogue consumer to provide malicious content which can be a threat to the backend APIs. To protect the backend, the API Management platform has policies to mitigate different types of content-based security attacks.

Regular Expression Threat Protection

This is mainly used to mitigate SQL Injection threats but can be used for any kind of malicious content in the payload. Available as a policy, it is configured in the platform by defining various regular expressions to check for a match in the payload. Once the API Management platform receives the request, it extracts the payload and other necessary information and evaluates the content against predefined regular expressions configured in the policy.

XML Threat Protection

This is mainly used to mitigate anomalies in the request payload. Attackers use recursive techniques to consume memory resources. A drastic change in the size of the application data often signals security issues. Once this policy gets enabled in the API Management platform the payload gets validated against the XML schema to ensure the request is in the right format and structure.  Additionally, the platform can check for blacklisted keywords or patterns. 

JSON Threat Protection

This is just like XML Threat protection but used in scenarios where the request payload is in JSON format. Attackers use recursive techniques to consume memory resources. A drastic change in the arrays and loops indicates security issues. Once this policy gets enabled in the API Management platform, the payload gets validated against the number of objects and array elements, to ensure the request is in the right format and structure. Additionally, the platform can check for blacklisted keywords or patterns.

Virus Scanning

This pattern scans for virus threats sent as content over a file. Sometimes there is a requirement to expose a file upload API to the public user. It is possible to send malicious content in a file to break through the system. Usually available as a policy, the API gateway receives the file and forwards to an antivirus enabled server that scans for malicious content. The server returns results and advises to proceed or not. Based on the response, the gateway allows the file to be pushed to the backend or rejects it if it contains a virus. 

Our next blog-post on the use of security patterns in API Management

In the next blog-post, we will go into the use of the above-described security patterns through an Unauthenticated journey and an Authenticated Journey. Follow our LinkedIn channel and stay tuned for the next blog in this API Security series.