API security is becoming a cyber insurance governance issue

At a glance

What this is: This is an independent analysis of how API security has become a cyber insurance underwriting concern, with visibility gaps, logic flaws, and runtime blind spots now affecting coverage decisions.

Why it matters: It matters because IAM, security, and risk teams must now show that API access, authentication, and monitoring are governed well enough to satisfy underwriters and reduce loss exposure.

👉 Read Salt's analysis of API security and cyber insurance readiness

Context

API security is no longer just an application protection issue. As insurers examine control maturity more closely, unknown APIs, weak authorisation, and insufficient runtime detection can turn a technical gap into a pricing and coverage problem. For identity teams, the intersection is clear: API endpoints are access boundaries, and if those boundaries are not governed, the broader identity programme inherits the risk.

The article’s core point is that security evidence now matters as much as security intent. Teams that can inventory APIs, test them for logic flaws, and monitor behaviour have a stronger story for underwriting, while teams that cannot will struggle to prove control effectiveness. That starting position is increasingly typical in cloud-heavy environments, especially where APIs connect customer data, internal services, and third-party integrations.

Key questions

Q: How should security teams prove API security maturity to cyber insurers?

A: They should show evidence, not just policy. That means an authoritative API inventory, documented testing for access-control flaws, runtime monitoring for abuse patterns, and a remediation process with owners and timelines. Insurers want to see that hidden APIs, weak authorisation, and runtime blind spots are being governed as a measurable risk rather than treated as an assumed control.

Q: Why do shadow APIs increase insurance and breach risk?

A: Shadow APIs expand the attack surface without corresponding ownership, testing, or monitoring. That creates unmanaged paths to sensitive data and business functions, which increases the chance of loss and makes claims harder to defend. If a team cannot identify an API, it usually cannot prove it is tested, monitored, or retired on schedule.

Q: What do teams get wrong about API gateway protection?

A: Teams often assume that a clean request and a documented schema mean the transaction is safe. In practice, schemas can hide over-disclosure, and gateways rarely understand the business meaning of every returned field. That is why response inspection and data minimisation must sit alongside inbound validation.

Q: What should organisations do if APIs are already part of their cyber insurance review?

A: They should treat API controls as renewal evidence. Prioritise inventory completeness, negative testing for logic flaws, behavioural monitoring, and remediation reporting. If these controls are fragmented across application, cloud, and identity teams, assign clear ownership so the underwriting story reflects a coherent control framework rather than isolated technical checks.

Technical breakdown

Why API discovery is an identity and exposure problem

APIs are not just technical interfaces. They are access paths that often carry authenticated requests, sensitive data, and delegated trust between systems. Shadow APIs are undocumented but live, while zombie APIs remain exposed after they should have been retired. In both cases, the issue is governance, because you cannot control what you have not inventoried. Where IAM intersects, the question is not only who logs in, but which service, token, or workload is allowed to call which API and under what conditions.

Practical implication: maintain a continuously refreshed API inventory linked to ownership, authentication method, and business criticality.

Broken object level authorisation and weak API controls

Broken object level authorisation, or BOLA, happens when a request is accepted but the caller is not properly checked for permission to access the specific object or record being requested. This is one of the most damaging API logic flaws because the front door may look secure while object-level checks fail underneath. Weak authentication, missing rate limits, and poor sequence validation add to the problem. In identity terms, the failure is often a mismatch between authentication and authorisation, especially in distributed systems where machine identities and session tokens carry broad reach.

Practical implication: test authorisation at the object and action level, not just at login and gateway layers.

Runtime protection for API behaviour and abuse patterns

Perimeter controls can stop obvious attacks, but many API incidents involve apparently valid calls that only become malicious when viewed as a sequence. Runtime protection watches for behavioural anomalies such as credential stuffing, unusual call volume, scraping, and data exfiltration patterns. This is analogous to endpoint detection in concept, but the signal set is API-specific: request rate, object traversal, sequence integrity, and abnormal access paths. For insurers, that runtime evidence can demonstrate that an organisation is not relying solely on development-time controls.

Practical implication: add behavioural detection and blocking for API abuse patterns that bypass static testing and gateway rules.

Threat narrative

Attacker objective: The attacker seeks to abuse legitimate-looking API requests to reach sensitive data or privileged application functions without triggering standard perimeter controls.

1. Entry occurs through exposed or shadow APIs that were not in the official inventory, giving attackers a path into live services without drawing immediate attention.
2. Escalation follows when weak authorisation or BOLA lets a caller access objects, records, or functions beyond its intended scope.
3. Impact comes through data theft, business disruption, or compliance loss, which is exactly the class of outcome cyber insurers are assessing when pricing API risk.

NHI Mgmt Group analysis

API security has become a governance evidence problem, not just a tooling problem. Insurers are asking organisations to prove that they can discover, test, and monitor APIs because blind spots map directly to loss potential. That shifts the conversation from deployment status to control assurance. Practitioners should treat API inventories and testing results as underwriting evidence, not just internal security artefacts.

Shadow API sprawl creates a control gap that identity teams cannot ignore. APIs often rely on tokens, service accounts, and delegated permissions that sit outside human access review processes. When those interfaces are unknown or stale, the organisation cannot confidently say who or what is calling what. The API attack surface becomes an identity governance issue once machine credentials are the mechanism of access, and that makes lifecycle control essential.

BOLA is really an authorisation failure at object scope. The problem is not that a request reached the application, but that the application accepted the request without validating the caller’s right to that specific resource. That is why gateway-only thinking fails. Organisations need object-level authorisation testing, not just perimeter controls, because insurer scrutiny is increasingly focused on whether access rules survive real-world abuse.

Runtime detection is now part of the insurance narrative. Static reviews can show intent, but behavioural monitoring demonstrates whether an organisation can catch malicious API sequences after release. This matters because many API attacks look normal in isolation. The teams that can show anomaly detection across call patterns, identities, and data access paths will be better positioned to defend coverage decisions and reduce exclusions.

Strong API governance now supports broader identity resilience. APIs frequently sit between human identity, workload identity, and third-party integrations, so failures cascade across the whole access model. As a result, API security is no longer a side programme. Practitioners should align API discovery, authorisation testing, and runtime telemetry with identity governance so the control story is coherent from login to machine-to-machine exchange.

What this signals

API governance is moving into the same evidence-led territory as identity assurance. For practitioners, that means inventories, authorisation tests, and runtime telemetry will increasingly be judged as control proof, not optional engineering detail.

Control evidence gap: when API discovery, testing, and monitoring are not tied together, insurers see uncertainty and attackers see opportunity. The practical response is to make API assurance part of the broader access governance model, with ownership, telemetry, and retirement tracked as a single system of record.

This also reinforces the need to connect machine access with identity governance frameworks such as the NHI breach analysis and the Ultimate Guide to NHIs , Key Challenges and Risks, because API callers are frequently service accounts, tokens, or other non-human identities operating outside human review cycles.

For practitioners

• Implement continuous API discovery Build and maintain an authoritative inventory of internal, external, third-party, shadow, and zombie APIs. Tie each API to an owner, data sensitivity, authentication method, and retirement status so underwriter questions can be answered with evidence, not estimates.
• Test object-level authorisation Add negative testing for BOLA and related access-control failures in pre-production and regression pipelines. Validate that the caller can only reach the object, record, or function explicitly allowed by policy, even when requests are syntactically valid.
• Extend identity controls to API endpoints Review whether service accounts, API keys, and tokens have the minimum permissions needed for each endpoint. Revoke over-broad permissions, shorten token lifetime where practical, and document the control path from identity issuance to API access.
• Deploy behavioural runtime protection Monitor for abnormal request sequences, scraping, credential abuse, and data exfiltration patterns that bypass static controls. Use alerting and blocking thresholds that are specific to API call volume, object traversal, and high-risk access paths.
• Package API evidence for underwriting Create a control pack that shows discovery coverage, test results, monitoring coverage, and remediation cadence. Use that pack in renewal discussions to demonstrate that API risk is managed as a governed part of the security programme.

Key takeaways

• API security is now part of the cyber insurance conversation because invisible interfaces can create unmanaged loss exposure.
• The most material failure is not just weak perimeter protection, but missing object-level authorisation and runtime visibility.
• Practitioners need inventory, testing, and evidence packs that show insurers the API attack surface is governed, not assumed.

Key terms

• 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.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• API Edge Protection: A security approach that inspects and controls API traffic at the point where it enters the enterprise. It combines authentication, rate control, risk scoring, and behavioural analysis to stop malicious requests before they reach backend services or data stores.

What's in the full article

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

• How the vendor maps API discovery, posture checks, and runtime monitoring into insurance readiness.
• The specific control categories underwriters are likely to ask about when evaluating API exposure.
• Practical examples of API security evidence that can support renewal discussions.
• The vendor's checklist-style guidance for teams trying to close API governance gaps.

👉 Salt's full article covers API discovery, posture governance, and runtime protection in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the governance foundations that support broader identity and access programmes.