API vulnerabilities are often introduced unintentionally by developers in early development stages. We’ll explore some best practices in the lens of a 2023 OWASP API Security Top 10 candidate on unsafe consumption and how to avoid downstream vulnerabilities for users.

1. Validation

It is easy to assume all API requests and responses will conform to expected formats from a reputable third party. This assumption often puts organizations at risk because API requests may have inputs that can be malicious or destructive, and API responses may contain unintended sensitive data like personally identifiable information (PII). Validating the request can protect against unauthorized access or other anomalies as well as data leakage.

1.1 Validating requests against unauthorized access or other anomalies

When publishing an API, each item (headers, path parameters, query parameters, body) has expected formats. For example, an authorization header might contain an authorization token value prefixed with the “Bearer” text or the path parameter might have a unique identifier. The query parameter might have start and end dates or the body might contain JSON data used to update the database. Although the development team knows what all these items should be and how they are formatted, the API infrastructure must also be built to validate to be fully trusted.

Creating an API schema will help the teams implement APIs more consistently and securely. Teams can use the OpenAPI specification, JSON schema, and other tools to create the API schema document. The team can use the document for reviews and capture it in source control. Additionally, they can make a policy only to deploy APIs with an API schema document. The schema can help verify API requests too. An API Gateway, WAF, and API security tool can use the API schema to block API requests that fail to conform. Furthermore, the code that processes that API request should also use the schema to verify the incoming request.

OpenAPI example:

paths:
 /profile:
   post:
     requestBody:
       content:
         application/json:
           schema:
             type: object
             required:
               - email
             properties:
               email:
                 type: string
                 format: email
               nickname:
                 type: string
                 format: email
     responses:
       '200':
         content:
           application/json:
             schema:
               type: object
               required:
                 - message
               properties:
                 message:
                   type: string

The “/profile” API path will accept an HTTP POST request with a request body. The API Gateway and the code that processes the request and verifies that the request body is a JSON string has the required “email” property that it is a string with the email format. If the API request fails to confirm, the API can respond with a 400 or 500 HTTP status code.

1.2 Validating responses to prevent data leakage

On the other end, there is the risk of transmitting information the recipient does not need or should have access to. Data leakage is preventable by checking the API response against the schema before sending a response.

OpenAPI example:

paths:
 /profile:
   get:
     responses:
       '200':
         content:
           application/json:
             schema:
               type: object
               required:
                 - email
               properties:
                 email:
                   type: string
                   format: email
                 nickname:
                   type: string
       '500':
         content:
           application/json:
             schema:
               type: object
               required:
                 - message
               properties:
                 message:
                   type: string

In this example, an application makes an API call to get a user’s profile. The API’s code gets data from the user database table and uses it to send the API request. The code might send the entire database response in the API response body that looks something like this:

{ "email": "brianjoe@somedomain.com", "firstName": "Brian", "lastName": "Joe", "ssn": "987-65-4321" }

As you can see, the database query response failed to omit the “ssn” property (the user’s social security number). The API has now inadvertently disclosed a social security number. Use an API schema to check whether the “ssn” property is part of a valid response. If the schema lacks the “ssn” property in the 200 response section, the API can respond with a 500 HTTP status code. Furthermore, leveraging an API security tool that inspects for sensitive data (like PII, PCI, or PHI) will further fortify the API security.

Gartner predicts by 2025, less than 50% of enterprise APIs will be managed, so the ability to discover non-conforming APIs will be critical to a strong security posture. We’re seeing our customers benefit from the ability to tag non-conforming APIs and alert teams before a compromise or data leak happens.

2. Enforcing secure protocols

Some APIs may be configured to accept HTTP requests instead of rejecting them or force-upgrading the request to HTTPS. Without enforcing secure protocols, sensitive data can be transmitted in plain text, making it susceptible to a malicious actor reading it. Configuring the API to accept HTTPS connections and upgrade HTTP requests to HTTPS is best.

3. Using least privileged access

The API’s code needs privileges to access specific system resources. Overly permissive privileges increase the risk that an attack may succeed, whereas restricting them to only the required permissions limits the blast radius of a successful exploit. Suppose a malicious payload that attempts to exfiltrate data happens to get past input validation. In that case, the exploit will fail if the API code has no permission to access the target data or execute any malicious commands.

4. Avoiding direct system calls

Software languages allow development teams to access system resources through direct and indirect system calls. The indirect system calls have predefined methods to interact with the host system with the lowest security risk. The direct system calls provide the ability to interact with the system like running a shell command. These interactions increase the chance that the API code can execute malicious commands. Development teams should rely on the indirect system calls provided by the software runtime to reduce risk.

5. Implementing inline anomaly detection and real-time incident response

Adding inspection tools can detect all API requests and responses will help detect shadow APIs that were accidentally deployed, forgotten, or deployed without permission. Comparing the detected API requests and responses against the API schema is useful in evaluating how effectively the APIs conform. However, inline inspection without prevention still leaves the organization vulnerable when an endpoint is compromised.

Real-time response capabilities are necessary when threats are detected for true efficacy. Suppose an API attack targets a zero-day vulnerability where a successful exploit has critical implications. Even if the inline solution detected the attack, the response time would be slow because the security operations team would need to see the alert, understand the implications, determine the response plan and execute it. The response time significantly increases if the remediation plan affects existing infrastructure and modifications require internal approvals. In the time it takes to implement the incident response, a malicious actor may have caused much damage or exfiltrated large amounts of data. Speed and efficacy is crucial in incident response, and that can only be accomplished when inline inspection is coupled with anomaly detection.

But what if malicious behavior conforms with the API Specification?  That’s where anomaly detection comes in.  Anomaly detection can help identify when the API receives atypical request inputs, which may indicate reconnaissance or well-crafted malicious inputs. It can also help detect when API responses have unusually large responses or new response properties, which may be indicators of exfiltration or data leakage. Another scenario might be an API responding with unexpected 3XX HTTP response codes, which might indicate a compromise that redirects the API requests to a malicious endpoint.  Ultimately, behavioral analysis of normal looking requests and responses is a key to protecting against these types of attacks.

Start fortifying your API security

With the proliferation of internal and external API consumption in enterprise organizations, it’s critical to have proper controls in place like validation and API schema to discover and test APIs without slowing development teams down. Coupling that with inline inspection, anomaly detection, and real-time incident response will create the full end-to-end API security posture necessary to prevent financial losses from bad actor threats.

‍