API Discovery
API discovery, in the context of cybersecurity, is the process of identifying and cataloging all Application Programming Interfaces (APIs)—including known, unknown, and undocumented ones—that an organization exposes or uses to facilitate data exchange and business logic. Its fundamental purpose is to establish a complete and accurate inventory of the API attack surface to ensure proper security controls can be applied.
The Need for Discovery
Modern applications rely heavily on APIs (e.g., REST, SOAP, GraphQL), often resulting in a sprawling and dynamic network of endpoints. This proliferation leads to several security blind spots that discovery seeks to address:
Shadow APIs: APIs created by development teams that are not officially documented, tracked, or included in security reviews. They pose a significant risk because security teams are unaware of their existence.
Zombie/Orphan APIs: Older, deprecated versions of APIs that were not properly decommissioned. While no longer in active use by clients, they may still be running on servers and contain unpatched vulnerabilities or outdated security mechanisms.
External/Third-Party APIs: APIs exposed to or used by partners, vendors, or the public. Security teams must ensure these APIs adhere to the organization's security policies, as they represent direct exposure points.
Key Discovery Methods
API discovery is typically performed through a combination of methods to build a comprehensive inventory:
Network and Traffic Analysis:
This involves monitoring network traffic (e.g., within the firewall or using a web application firewall/API gateway) to inspect HTTP/S requests and responses.
Security tools analyze the structure of the traffic, looking for common API path prefixes (e.g.,
/api/v1/), JSON/XML payloads, and HTTP methods—to identify active endpoints and understand their use patterns.
Code and Configuration Scanning (Static/Dynamic):
Static Analysis (SAST): Scanning application source code, configuration files, and deployment manifests (like Kubernetes files) for function definitions and routing rules that expose API endpoints.
Dynamic Analysis (DAST): Actively testing running applications to crawl for endpoints and understand their functionality.
API Gateway and Documentation Review:
Reviewing centralized management components, such as API Gateways, which often serve as the single entry point for APIs. The gateway configuration lists the managed APIs.
Parsing API specification files (e.g., OpenAPI/Swagger) maintained by development teams, although this method is limited to officially documented APIs.
Outcome and Security Implications
The direct outcome of API discovery is a detailed, real-time inventory that includes the following for each API:
Endpoint Path: The exact URL structure (e.g.,
/users/{id}).HTTP Methods: The allowed methods (GET, POST, PUT, DELETE).
Data Schema: The expected input and output data structures.
Authentication/Authorization: The security mechanisms in place (e.g., OAuth, API Key, no auth).
By centralizing this information, security teams can perform crucial follow-up actions:
Risk Assessment: Prioritizing APIs for penetration testing or security hardening based on the sensitivity of the data they process.
Policy Enforcement: Ensuring all APIs use strong authentication and authorization, rate limiting, and input validation.
Vulnerability Management: Scanning newly discovered APIs for common vulnerabilities like Broken Object-Level Authorization (BOLA) or excessive data exposure.
ThreatNG, an all-in-one external attack surface management (EASM), digital risk protection, and security ratings solution, provides detailed assistance with API Discovery by focusing on the external, unauthenticated attacker's view of an organization's digital footprint. This approach is critical for uncovering shadow and zombie APIs—endpoints that are unknown, undocumented, or forgotten —prime targets for exploitation.
The platform aids in API discovery through its external discovery and assessment capabilities, comprehensive investigation modules, continuous monitoring, and intelligence repositories.
External Discovery and Assessment
ThreatNG performs purely external unauthenticated discovery with no connectors, simulating a real-world attacker's reconnaissance phase. This is the foundational step for finding publicly exposed APIs.
Key Assessment Examples
ThreatNG's external assessments often reveal API-related risks by analyzing assets found during the discovery phase:
Subdomain Takeover Susceptibility: This process involves a meticulous check for a "dangling DNS" state that could allow an attacker to claim a subdomain and, potentially, an API endpoint. The process is:
Perform external discovery to identify all associated subdomains.
Use DNS enumeration to find CNAME records pointing to third-party services.
Cross-reference the external service hostname against a comprehensive Vendor List (including PaaS & Serverless vendors like Heroku, Vercel, ElasticBeanstalk_AWS_service, and API Management like Apigee, Mashery) to see if the CNAME is currently pointing to a resource that is inactive or unclaimed. Example: An organization may have an old development subdomain,
dev-api.company.com, which points via a CNAME to a decommissioned PaaS service. If ThreatNG identifies that this CNAME is unclaimed, an attacker could register the PaaS service, effectively taking over the API endpoint and potentially intercepting or serving malicious code.
Web Application Hijack Susceptibility: This rating is partially based on the analysis of missing security headers across subdomains. APIs are often hosted on subdomains, and missing headers like Content-Security-Policy, X-Content-Frame-Options, and HTTP Strict-Transport-Security (HSTS) increase the risk of hijacking or cross-site scripting, which could compromise the API.
Cyber Risk Exposure: This rating assesses Subdomain intelligence for issues such as exposed ports, private IPs, Subdomain Takeover Susceptibility, and missing security headers. These are direct indicators of misconfigured or shadow API hosts.
Mobile App Exposure: ThreatNG discovers mobile apps in marketplaces and analyzes their contents for Access Credentials and Security Credentials. This process explicitly looks for hardcoded APIs, AWS API Keys, Stripe API Keys, and GitHub Access Tokens that could be used to access an API directly, providing a clear map of exposed API secrets.
Investigation Modules
The Investigation Modules are the tools ThreatNG uses to find and validate API-related assets and risks actively.
Subdomain Intelligence: This module is crucial for discovering shadow APIs. It identifies:
HTTP Responses, Header Analysis, and Server Headers: By inspecting headers and responses, ThreatNG can fingerprint the underlying technology and identify APIs that may not be officially listed.
Subdomain Cloud Hosting: It identifies subdomains hosted on major cloud platforms (AWS, Azure, Google Cloud) and on specific third-party vendors (such as Apigee or Mashery for API Management), which often host unknown API endpoints.
Content Identification: It actively hunts for patterns such as APIs and Admin Pages across subdomains, directly targeting undocumented interfaces.
Ports: It discovers exposed ports (e.g., for Databases like PostgreSQL or MongoDB, or Remote Access Services like SSH or RDP). An exposed database port suggests a significant backend API vulnerability, while an exposed remote access port indicates a potential shadow management interface. * Sensitive Code Exposure: The Code Repository Exposure module discovers public code repositories and their contents, which may contain Access Credentials (e.g., Stripe API Key, Google OAuth Key), Database Exposures, and Configuration Files (e.g., Environment configuration file). Leaked keys and configuration files are direct pathways to exploiting the API they control.
Search Engine Exploitation: The Search Engine Attack Surface module helps uncover an organization’s susceptibility to exposing sensitive information, such as potentially sensitive information, privileged folders, and susceptible files via search engines. This may reveal API keys, service accounts, or administrative API endpoints that have been inadvertently indexed.
Intelligence Repositories and Continuous Monitoring
Intelligence Repositories (DarCache)
ThreatNG uses its comprehensive intelligence repositories to enrich and prioritize the discovered APIs:
Compromised Credentials (DarCache Rupture): This repository is crucial for identifying if any API Keys, service accounts, or other credentials found during the discovery process have already been compromised and are circulating on the dark web. This flags an immediate risk of an attacker accessing the API.
Vulnerabilities (DarCache Vulnerability): This links discovered API technologies to known vulnerabilities. It integrates NVD (severity), KEV (active exploitation), EPSS (likelihood of exploitation), and Verified Proof-of-Concept (PoC) Exploits for risk-based prioritization. Example: An API endpoint is found to be running on an old version of Apache Tomcat (discovered via Subdomain Intelligence headers). ThreatNG cross-references this with DarCache Vulnerability to identify if the specific Tomcat version has an actively exploited KEV vulnerability, immediately making the API a high-priority risk.
Continuous Monitoring and Reporting
ThreatNG performs Continuous Monitoring of the external attack surface, which is vital for an agile environment where new shadow APIs can be deployed at any time. This ensures that new APIs or changes to existing API configurations are detected in real time. The subsequent Reporting provides a Prioritized view (High, Medium, Low, Informational), which is essential for security teams to focus their remediation efforts on the most critical API exposures.
Complementary Solutions
Other security solutions can powerfully complement ThreatNG's external discovery:
API Gateways/Web Application Firewalls (WAFs): ThreatNG can identify their presence on subdomains. Cooperation would involve ThreatNG sharing its discovered, unmanaged API inventory with the WAF or Gateway. The WAF could then use this external list to check if internal traffic logging is missing for those external endpoints, helping to enforce policy and log traffic for previously unknown shadow APIs.
Security Orchestration, Automation, and Response (SOAR) Platforms: ThreatNG's Legal-Grade Attribution from the Context Engine™ provides high-certainty evidence on exposed APIs. This irrefutable evidence can be fed directly to a SOAR platform. *Example: ThreatNG discovers a hardcoded API key in a public GitHub repository (via Sensitive Code Exposure). A SOAR platform could automatically use this alert to trigger a remediation workflow, such as revoking the key in the target system (e.g., AWS), notifying the code owner via Slack, and creating a Jira ticket.
Configuration Management Databases (CMDBs): ThreatNG's external discovery uncovers assets the organization might not know it owns, particularly for shadow APIs. Cooperation would involve ThreatNG injecting its discovered API inventory into the CMDB. This forces a reconciliation, ensuring the formal internal asset register is updated with the real-world external attack surface, which aids in assigning ownership and accountability for remediation.
