How to mitigate the risks for API endpoints?

Last updated: August 18, 2025

Overview

APIs are the backbone of modern applications, enabling services to communicate and share data. However, every API endpoint is a potential attack surface. If left unmonitored or poorly maintained, APIs can expose sensitive information, increase the attack surface, or weaken the overall security posture of an organization.

This document provides an overview of the common risks associated with HTTP endpoints, explains how our platform detects and scores these risks, and outlines mitigation strategies that teams can apply in their environments.

Risk Classification and Mitigation Strategies

Zombie APIs

Definition
Zombie APIs are endpoints that remain deployed and accessible even though they are deprecated or no longer in use. They often linger because teams forget to decommission them after releasing newer versions.

Risk
Since these APIs are not maintained, they may rely on outdated libraries or frameworks and are less likely to receive timely security patches. Attackers actively scan for such APIs because they are easy entry points into otherwise hardened environments.

Example

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

The endpoint is part of an older v1 version no longer supported, but it is still exposed to the internet.

Mitigation Steps

  • Audit API Inventory: Continuously scan for APIs that are not being used. Maintain an authoritative API catalog.

  • Deprecation Process: Communicate deprecation notices to clients in advance and provide a clear migration path (e.g., v1 → v2).

  • Disable Access: Block requests to deprecated APIs. Return 410 Gone to signal permanent removal.

  • Patch Before Decommission: Even during the transition period, ensure old APIs receive security updates until fully shut down.

Shadow APIs

Definition
Shadow APIs are undocumented or unapproved APIs that teams deploy outside the visibility of central IT/security. They usually arise from “shadow IT” practices, where business units or developers bypass governance to move faster.

Risk
Because they are unknown to security teams, Shadow APIs are not monitored, logged, or governed. This lack of visibility creates blind spots in security monitoring and compliance, increasing breach risks.

Example

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

The endpoint exists but is not present in the official OpenAPI specification or API management system.

Mitigation Steps

  • Automated Discovery: Use API discovery and scanning tools to detect undocumented endpoints.

  • Enforce Governance: Require approval workflows for new API deployments.

  • Integrate Security Controls: Bring shadow APIs into API gateways and monitoring systems.

  • Mandatory Documentation: Make OpenAPI/Swagger documentation a deployment prerequisite.

Orphan APIs

Definition
Orphan APIs are endpoints that exist without being tied to any active service or business function. They remain live even after the underlying service has been deprecated or removed.

Risk
These endpoints are often forgotten and unmonitored, which makes them easy targets for attackers. They may also create confusion for developers consuming APIs.

Example

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

The business service tied to this endpoint was deprecated, but the endpoint remains active.

Mitigation Steps

  • Schedule Audits: Regularly validate whether endpoints are linked to active services.

  • Decommission Safely: Retire endpoints gracefully, returning 410 Gone or 404 Not Found.

  • Track Ownership: Assign responsible owners to every API.

  • Monitor Usage: Identify inactive endpoints by analyzing access logs and retire them accordingly.

PII (Personally Identifiable Information)

Definition
PII (Personally Identifiable Information) includes any data that can uniquely identify an individual, such as names, email addresses, government IDs, or credit card numbers.

Risk
If PII is leaked, organizations face regulatory penalties (GDPR, HIPAA, CCPA) and reputational damage. Attackers can use PII for fraud, phishing, or identity theft.

Example

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

The response includes full name, email, and phone number.

Mitigation Steps

  • Identify PII: Detect endpoints that return or process sensitive fields.

  • Redact/Mask: Do not expose unnecessary fields. For example, John Doe → J*** D***.

  • Encryption: Apply TLS in transit and strong encryption at rest.

  • Access Control: Protect endpoints with OAuth 2.0, JWT, or API keys.

  • Compliance: Ensure adherence to GDPR, HIPAA, CCPA, or regional equivalents.

  • Continuous Auditing: Regularly scan responses for accidental PII leakage.

Lack of Rate Limiting

Definition
Rate limiting restricts how many requests a client can make within a set timeframe.

Risk
Without it, attackers can abuse endpoints with brute-force or denial-of-service (DoS) attacks. Excessive requests may also degrade performance for legitimate users and increase infrastructure costs.

Example

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

A login endpoint without rate limiting is vulnerable to password spraying or brute-force attempts.

Mitigation Steps

  • Enforce Limits: Example: 100 requests/minute per user.

  • HTTP Status Codes: Respond with 429 Too Many Requests when limits are exceeded.

  • Expose Rate Headers: Return headers like X-RateLimit-Remaining to guide clients.

  • Monitor Abuse: Track usage anomalies with monitoring and logging.

  • Encourage Backoff: Educate clients to retry with exponential backoff strategies.

Risk Scoring Methodology

To prioritize remediation, each endpoint receives a Risk Score based on weighted factors.

Factors Considered

  • Transport Security: HTTP (insecure) vs HTTPS (secure).

  • Authentication: Public/unauthenticated APIs receive higher risk.

  • Zombie APIs: Deprecated but still live.

  • Orphan APIs: Not linked to active services.

  • Shadow APIs: Not documented in API specs.

  • PII Exposure: Endpoints handling sensitive data.

  • Schema Mismatch: Data types not aligning with OpenAPI specifications.

Weighting

  • Each factor is normalized to a 0–10 scale.

  • Risk weights reflect severity (e.g., PII > Orphan > Schema mismatch).

  • Scores are calculated per parameter, then aggregated per endpoint.

  • Business-critical endpoints (payment, authentication, login) receive extra weight.

Key Takeaways

  1. Visibility is the first step: You cannot secure what you don’t know exists.

  2. Governance and ownership are critical: Every API must have an owner.

  3. Lifecycle management matters: APIs should be monitored from creation to decommissioning.

  4. Automation is essential: Manual tracking cannot keep up with dynamic environments.

  5. Risk scoring helps prioritize: Not all APIs pose equal risk—focus on the highest impact first.