API Risk

In this help article, we will explain different kinds of risk detected against HTTP endpoints and how to mitigate them. We will also explain the methodology behind our risk scoring and security grading system, highlighting the key factors we consider.

Risk Classification

Zombie APIs

Zombie APIs refer to APIs that are outdated, unused, or deprecated but still deployed and accessible. These APIs can remain active without the knowledge of development or operations teams, posing a security risk because they are not maintained, updated, or monitored.

Risk: These APIs can expose vulnerabilities as they may use outdated software components or lack security patches, making them prime targets for cyberattacks.

Example Endpoint: GET https://api.example.com/v1/old-customer-orders

This endpoint is part of an older version of the API (v1) that’s no longer maintained, but still accessible.

Mitigation Steps

Audit API Inventory: Regularly scan your API environment for unused or outdated APIs.

Deprecation Notices: Provide users with an advance deprecation notice and migrate them to the updated version (e.g., v2).

Disable Access: Remove or disable access to deprecated APIs and return a 410 Gone status for any requests made to them.

Update Security Policies: Ensure that security patches are applied promptly even if the API is no longer in active use, until it’s fully decommissioned.


Shadow APIs

Shadow APIs are undocumented APIs that are deployed without the knowledge or approval of the central IT or security teams. They are often the result of decentralized development practices where different teams create APIs without following standard procedures.

Risk: Shadow APIs can bypass organizational security controls, making it difficult to manage and secure the organization's API ecosystem. This lack of visibility increases the risk of security breaches.

Example Endpoint: POST https://internal.example.com/data-sync-service

This API was deployed by a team without knowledge or approval from central IT/security teams. It’s undocumented in openAPI spec file and not part of the API management system.

Mitigation Steps

API Discovery Tools: Use automated tools to discover undocumented APIs across your environment (e.g., API gateways or security scanning solutions).

Enforce API Governance: Ensure that all teams follow centralized API governance policies and get approval before deploying APIs.

Integrate Security Controls: Bring shadow APIs under security monitoring and add them to API management tools for better visibility and control.

Documentation Compliance: Require all APIs to be documented and added to an official catalog.


Orphan APIs

Orphan APIs are APIs that are no longer associated with any active service or business logic. While the underlying service may have been deprecated or removed, the API endpoints themselves are still active.

Risk: Orphan APIs can lead to data exposure or security vulnerabilities as they may not be regularly audited or monitored. These APIs also create confusion for developers and increase the attack surface.

Example Endpoint: DELETE https://api.example.com/v2/remove-user-account

This endpoint was once part of an active service, but the underlying service was deprecated. However, the API is still live and accessible.

Mitigation Steps

Regular API Audits: Schedule audits to find APIs that are no longer tied to active services or business logic.

Decommission Safely: Safely decommission the orphan APIs by disabling them and ensuring they return appropriate responses (410 Gone or 404 Not Found).

Track API Ownership: Implement a system to track API ownership and ensure each API has a responsible team.

Monitor API Usage: Monitor the usage patterns of APIs and if no legitimate requests are made over a period, consider decommissioning.


PII (Personally Identifiable Information)

PII refers to any data that can be used to identify a specific individual, either on its own or when combined with other information. This includes but is not limited to:

Full name
Aadhar/Pan/Credit/Debit card number
Email address
IP address
Phone number, etc

Risk: Exposure of PII can lead to identity theft, financial fraud, and other forms of privacy invasion. Organizations handling PII must comply with privacy regulations like GDPR, HIPAA, or CCPA, and failure to protect PII can result in significant legal and financial penalties.

Example Endpoint:

GET https://api.example.com/v1/user-profile?userId=123

This API returns sensitive Personally Identifiable Information (PII) such as full name, email, and phone number in the response body.

Mitigation Steps

PII Identification: Identify endpoints that handle or return PII. Use API security tools to track where sensitive data is exposed.

Mask or Redact PII: Mask or redact sensitive information (e.g., return partial information like name: John D.).

Use Encryption: Ensure all data (including PII) is encrypted at rest and in transit.

Apply Access Controls: Implement strict access control mechanisms like OAuth 2.0, API keys, or JWT to prevent unauthorized access to PII.

Comply with Regulations: Ensure that the handling of PII complies with legal requirements such as GDPR, HIPAA, or CCPA.

Audit and Monitor: Regularly audit the API responses for accidental PII exposure and implement logging to monitor requests for PII endpoints.

Rate Limiting

Rate limiting is a technique used to control the number of API requests a client can make in a specified time period. It helps prevent abuse, protects server resources, and ensures fair usage among different users. Rate limiting is often implemented using quotas or limits (e.g., 1000 requests per hour per user).

Risk: Without proper rate limiting, APIs can be vulnerable to abuse through excessive request traffic, which can result in server overload, increased latency, or even denial of service (DoS) attacks. This can negatively impact the user experience and potentially lead to higher infrastructure costs.

Example Endpoint:

GET https://api.example.com/v1/user-login

This endpoint is part of user login process. Without rate limiting, this could lead to fuzzing attacks, high server load and degraded performance for other users.

Mitigation Steps

Implement Rate Limits: Set limits for the number of requests a user or IP address can make in a given time frame (e.g., 100 requests per minute). This can be implemented using API gateways or load balancers that support rate limiting.

Return Appropriate HTTP Status Codes: When rate limits are exceeded, return status codes like 429 Too Many Requests to inform clients that they have hit the limit.

Provide Rate Limit Information in Responses: Include headers such as X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset to help clients understand their rate limits and adjust their request patterns.

Monitor API Usage Patterns: Use monitoring and logging tools to track API usage and identify patterns that may indicate abuse. This allows proactive adjustments to rate limits.

Implement Exponential Backoff for Retrying: Encourage clients to use exponential backoff strategies when they encounter 429 responses, to avoid retrying requests too quickly.

Risk Score Calculation Factors

The risk score is determined by a weighted average of several factors that collectively assess the severity and potential impact of a risk. These factors include:

HTTP scheme used in the API: We assign higher risk for unencrypted HTTP scheme http.

API accessibility and authentication: Unauthenticated APIs with external accessibility is assigned higher risk.

Zombie risk: The API endpoints and parameters which are marked as deprecated in openAPI spec file attracts Zombie risk.

Orphan risk: The API endpoints and parameters which are not accessed beyond a set duration are classified as Orphan which will increase the risk score.

Shadow risk: The API endpoints and parameters which are not part of openAPI spec file are classified as Shadow risk.

PII risk: The API endpoints and parameters which consists of PII (such as email) will be marked as PII risk.

Schema mismatch: The parameters of an endpoint are checked in the openAPI spec file to match the data type. Mismatched data type will be termed as schema mismatch.

APIs related to payment, authentication, password management, login attracts more risk score if they are found to be having aforementioned risk factors.

Methodology

Each factor is normalized to a common scale (e.g., 0-10) to ensure comparability. We assign weights to each factor based on its relative importance in determining the overall risk. The weights reflect the significance of each factor in influencing the potential impact and exploitability of a risk. To calculate the risk score for an endpoint, risk of every parameter of that endpoint is first calculated. Then the risk score of the endpoint is calculated based on the risk score of endpoint as well as risk score score of parameters.

Updated on: 07/11/2024