API security compliance gaps are turning routine exposure into fines

At a glance

What this is: This is an analysis of how API security, compliance, and runtime governance intersect when APIs become a primary attack surface.

Why it matters: It matters because API exposure often sits inside IAM, secret handling, and access governance decisions that affect both human and machine identity programmes.

By the numbers:

• In 2018, a vulnerability in Facebook's "View As" feature exposed its APIs, allowing attackers to access compromised tokens and personal data of around 29 million users.
• 2020, 020, hackers took advantage of vulnerabilities in Geico's online quoting tool API, gaining access to sensitive personal information, including driver's license numbers and birth dates of approximately 116,000 individuals.
• In January 2023, a data breach impacted 8.9 million AT&T wireless customers.

👉 Read Salt's analysis of API security compliance and breach exposure

Context

API security is no longer just an application-layer issue. APIs now sit between customer data, cloud services, and internal systems, which means weak authentication, overbroad access, and poor inventory hygiene can create a direct route to sensitive data.

The identity angle is real even in a broader API security story because APIs depend on tokens, service credentials, and delegated access. Where teams cannot see every API or control its entitlement model, human and non-human identity governance both break down.

Salt's examples reflect a common pattern in API security programmes: visibility appears partial, policy enforcement is uneven, and compliance is treated as a point-in-time exercise rather than a continuous control state.

Key questions

Q: How should security teams govern APIs that support third-party and partner integrations?

A: They should treat partner-facing APIs as governed access paths, not just technical interfaces. That means maintaining endpoint inventories, mapping exposed data, applying policy based on business context, and monitoring for behavioural deviation. Where APIs underpin regulated workflows, IAM, application security, and compliance teams should share the same policy model and response process.

Q: Why do APIs create identity risk even when the application code is secure?

A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

Q: What breaks when API discovery is incomplete?

A: When discovery is incomplete, security teams miss shadow APIs, forgotten integrations, and endpoints that no longer have an obvious owner. Those gaps prevent consistent authentication, logging, rate limiting, and offboarding, which creates an easy path for attackers to find overlooked access points. An API estate cannot be governed if it cannot be inventoried.

Q: Which frameworks require stronger API governance and access control?

A: PCI DSS, GDPR, NIST SP 800-53, and Zero Trust guidance all expect organisations to know what they expose, limit access, and monitor use. For identity and security teams, the practical test is whether each API has a named owner, bounded access, and evidence of continuous control operation. If not, the framework requirement is only partially met.

Technical breakdown

Why API discovery is the first control failure

API discovery is the process of finding all exposed, internal, partner, and shadow APIs before they become unmanaged attack paths. Without inventory, teams cannot validate authentication, rate limits, input handling, or data exposure. This is especially dangerous when APIs are created quickly by development teams and outlive their original business purpose, because hidden endpoints often bypass central governance and monitoring.

Practical implication: build continuous API inventory coverage so unknown endpoints cannot sit outside policy enforcement.

Posture governance and least privilege for API access

API posture governance means checking whether each API has the right authentication method, authorization scope, logging, and hardening controls. Least privilege matters because many breaches do not require sophisticated exploitation, only a token, session, or delegated permission that reaches further than it should. For identity teams, this is the same governance problem seen in NHI sprawl: too many credentials with too much access for too long.

Practical implication: review API scopes, token lifetimes, and access paths as part of entitlement governance, not only application security.

Zero Trust for APIs means continuous verification

Zero Trust for APIs does not mean distrust everything equally. It means every request is evaluated in context, including identity, device, service origin, and policy state. In practice, this requires strong authentication, logging, threat detection, and segmentation of sensitive data paths. When APIs connect cloud platforms, payment systems, or third-party integrations, one weak trust assumption can expose multiple downstream systems.

Practical implication: apply continuous verification and monitoring to high-value API traffic instead of relying on perimeter trust.

Threat narrative

Attacker objective: The attacker aims to use API trust relationships to obtain data or credentials that unlock broader access and create monetisable breach impact.

1. Entry begins when attackers target public or partner-facing APIs that expose weak authentication, stale tokens, or logic flaws.
2. Escalation follows when the attacker uses the API's own trust relationships to retrieve data or abuse permission scope beyond the intended caller.
3. Impact occurs when personal data, tokens, or regulated records are extracted, producing breach notification, regulatory action, and operational disruption.

NHI Mgmt Group analysis

API security has become an identity governance problem as much as an application security problem. The article's examples show that APIs often fail because tokens, delegated permissions, and service access are not governed with the same discipline as human identity. That creates a control gap between authentication and actual authorisation scope. Practitioners should treat API entitlement review as part of the identity programme, not a separate technical afterthought.

Shadow API exposure is the named concept that matters here. Discovery failures create a class of endpoints that exist outside policy, monitoring, and remediation workflows. Once an API is invisible to the security team, posture governance becomes incomplete by definition. The practitioner takeaway is simple: if you cannot enumerate it continuously, you cannot secure it continuously.

Compliance failures in API security usually reflect control failure, not regulatory ambiguity. PCI DSS, GDPR, and similar frameworks all assume that organisations can identify sensitive data paths, enforce least privilege, and log access reliably. When APIs leak regulated data, the issue is typically missing enforcement at the request layer. Teams should map API controls to the same governance expectations they use for privileged human access.

Runtime API defence needs to move beyond static policy checks. Discovery and configuration reviews catch only part of the problem, because attack conditions change as systems integrate, vendors rotate, and access tokens age. That means the stronger operating model is continuous verification of authentication, rate behaviour, and data access patterns. Practitioners should expect API security to merge with broader identity telemetry and detection workflows.

API security and NHI governance now overlap in the same operational blind spots. Many API incidents involve secrets, service accounts, or tokens that act like non-human identities even when teams do not label them that way. The governance challenge is lifecycle control. If a token is created, reused, and never retired with clear ownership, the attack surface persists long after the business need has changed. Practitioners should align API security and NHI governance where credentials are the shared control point.

What this signals

Shadow API governance is becoming a practical control issue for teams that already struggle to maintain an accurate identity inventory. Where APIs depend on service credentials or delegated tokens, the boundary between application security and NHI governance disappears. Teams should expect discovery, entitlement review, and runtime monitoring to be managed as one control chain, not three separate programmes.

The operational signal is clear: API risk is now measured by what remains invisible, not only by what is technically vulnerable. Organisations that can continuously map endpoints, owners, and credentials will be better placed to absorb regulatory scrutiny and reduce breach blast radius. For readers building identity programmes, the next step is to align API telemetry with lifecycle and access governance.

This also strengthens the case for using The 52 NHI breaches Report when briefing stakeholders on why unmanaged machine credentials create persistent exposure. The lesson is that access patterns, not just code defects, drive most real-world loss.

For practitioners

• Implement continuous API inventory Track every exposed, internal, partner, and shadow API in a single governed inventory, then tie each endpoint to an owner, authentication method, and data classification. Use the inventory to drive remediation of orphaned or duplicate endpoints before they become unmanaged access paths.
• Enforce least privilege on tokens and service access Review API scopes, token lifetimes, and delegated permissions against actual use. Remove broad default access, shorten standing credential validity, and require explicit approval for sensitive data paths so a stolen token cannot move far enough to cause broad compromise.
• Automate posture checks for sensitive APIs Continuously validate authentication strength, logging coverage, rate limits, and insecure configuration drift for APIs that handle personal, financial, or regulated data. Use this control to catch endpoints that silently fall out of compliance after code changes or vendor integrations.
• Tie API governance to identity controls Treat APIs, service accounts, and tokens as part of the identity lifecycle so creation, rotation, offboarding, and review happen together. This closes the gap where a valid credential survives after its original application purpose has ended.
• Correlate API telemetry with detection workflows Feed request logs, authentication failures, anomalous volume, and suspicious geography into SOC workflows so abuse patterns surface quickly. The goal is to detect token abuse and business-logic attacks before regulated data leaves the environment.

Key takeaways

• API security failures often begin as governance failures, because unknown endpoints and overbroad tokens are hard to protect consistently.
• The breach evidence in this article shows that API exposure can affect tens of millions of users and trigger direct regulatory penalties.
• Practitioners should connect API discovery, posture governance, and identity lifecycle controls so tokens and service access do not outlive their purpose.

Key terms

• API Coverage: API coverage describes how much of an application’s user, entitlement, and activity data is available through programmable interfaces. In SaaS management, limited API coverage constrains automation and forces teams to use manual or hybrid controls for parts of the application estate.
• API Posture Governance: API posture governance is the ongoing discipline of checking whether each API meets required security and compliance settings. It covers authentication, authorization scope, logging, configuration, and hardening, then tracks drift so weak or stale endpoints can be corrected before they are abused.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zero Trust For APIs: Zero Trust for APIs is the practice of verifying each request using identity, context, and policy rather than assuming trust based on network location. In API environments, it reduces reliance on implicit trust and forces continuous evaluation of the caller and the action requested.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• Detailed regulatory mapping across PCI DSS 4.0, GDPR, NIST SP 800-53, HIPAA, PSD2, and NYDFS requirements for API environments
• Examples of breach consequences tied to Meta, Geico, PayPal, and AT&T for practitioners who need incident context and board-level justification
• Operational guidance on API discovery, posture governance, runtime threat protection, and Zero Trust controls for implementation teams
• Discussion of API security tooling selection and how to prioritise discovery, monitoring, and remediation in live environments

👉 Salt's full article covers the compliance mapping, breach examples, and governance priorities in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the governance habits that underpin reliable access control across modern identity programmes.