Topic starter
25/06/2026 5:05 pm
TL;DR: API security risks increase as organisations rely on API keys, tokens, and exposed endpoints, with Entro Security highlighting gaps in authentication, authorization, encryption, and secret rotation. The governance problem is not just API protection but whether identity and access controls can keep pace with machine-to-machine access at scale.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “API security risks, testing, protection best practices”.
By the numbers:
- As per the State of Developer Experience report released in 2023, 98% of developers perceive APIs as crucial in aiding their and their team’s productivity.
- Secrets rotation should be automatically done at least every 90 days.
Key questions
Q: What breaks when customer-owned API keys are not lifecycle-managed?
A: When customer-owned API keys are not lifecycle-managed, access can persist after ownership changes, business relationships shift, or a workflow is retired.
Q: Why do exposed APIs create risk even when TLS is enabled?
A: TLS protects traffic in transit, but it does not fix broken authorization, insecure object references, or overly broad permissions.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Audit API credential lifecycle Inventory keys, tokens, and JWTs across code, CI pipelines, logs, and runtime services, then map each one to an owner, expiry, and revocation path.
- Enforce object-level authorization Review every sensitive endpoint for broken object references and ensure the caller can only reach the specific resource it is entitled to access.
- Automate rotation and revocation Set a hard maximum lifetime for API secrets, rotate them on a fixed schedule, and revoke any credential that appears in scanning results or audit anomalies.
Bottom line: API security fails when teams treat keys and tokens as sufficient proof of trust instead of governed machine identities.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 5:35 pm
API security risk is really identity governance risk at machine scale. The article shows that API keys, tokens, TLS, and rate limiting each solve only part of the problem. When the caller is a system rather than a person, the control set has to cover issuance, scope, rotation, revocation, and endpoint authorization as one lifecycle.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations prioritise secret rotation or access review first
A: They should do both, but access review should come first when unknown or over-privileged identities already exist. Rotation reduces exposure window, but review reduces entitlement sprawl and clarifies ownership. If a team rotates secrets without fixing who can use them, it preserves the same risk pattern with a fresher credential.
👉 Read our full editorial: API security risks expose the limits of key-based access controls
This post was modified 1 day ago by NHI Mgmt Group