TL;DR: API discovery, posture governance, and runtime protection are now central to API security because weak controls have contributed to exposed tokens, personal-data leaks, and regulatory penalties affecting Meta, Geico, PayPal, and AT&T, according to Salt. The practical shift is toward continuous visibility, least-privilege access, and Zero Trust assumptions across API estates, not compliance minimums alone.
NHIMG editorial — based on content published by Salt: API security compliance, breach exposure, and governance priorities
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.
- In 2020, 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Enforce least privilege on tokens and service access Review API scopes, token lifetimes, and delegated permissions against actual use.
- 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.
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
👉 Read Salt's analysis of API security compliance and breach exposure →
API security compliance gaps and what IAM teams need to watch?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: API security compliance gaps are turning routine exposure into fines