Notifications
Clear all
Topic starter
02/08/2026 12:17 pm
TL;DR: As organisations shift more business and customer activity onto digital platforms, unknown APIs, exposed sensitive data, and signature-based controls are creating blind spots that attackers can exploit, according to Salt. The core issue is not just API volume but weak inventory, weak prioritisation, and controls that do not match custom logic.
NHIMG editorial — based on content published by Salt: API Security 101 and the security challenges of digital platforms
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when endpoint inventory is incomplete?
A: When endpoint inventory is incomplete, patching, configuration enforcement, and access restrictions all become partial controls.
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: How do security teams know if API abuse controls are working?
A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load.
Practitioner guidance
- Inventory every API surface Map production, development, partner, and internal APIs in one authoritative register, then tie each endpoint to the data it can reach and the identity that authenticates to it.
- Bind API access to governed non-human identities Treat tokens, service accounts, and certificates as managed identities with owners, expiry, rotation, and offboarding rules.
- Test object-level authorisation, not just authentication Validate whether authenticated callers can only reach the objects and functions they are meant to use.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- How to catalogue unknown APIs across development, partner, and production environments before they become shadow exposure.
- How to validate API authorisation paths and identify object-level access failures that signatures will not catch.
- How to connect API exposure findings to the service accounts, keys, and tokens that govern backend access.
- How to prioritise remediation when release velocity keeps changing the attack surface.
👉 Read Salt's analysis of API exposure and security controls for digital platforms →
API exposure and attack visibility: what are teams missing?
Explore further
02/08/2026 1:19 pm
API exposure is now an identity governance problem as much as an application security problem. The article describes a world where digital services depend on machine access, not just human sessions. That means service accounts, tokens, and certificates become part of the control surface, even when the security conversation starts with application logic. Practitioners should treat API inventory and NHI lifecycle management as a single governance problem, not two separate programmes.
A question worth separating out:
Q: How do organisations reduce API abuse without slowing delivery too much?
A: The best approach is to standardise policy at the gateway and delegate only narrow, pre-approved access patterns to development teams. Use rate limits, schema validation, and consistent authorization checks so every new API inherits controls by default. That reduces manual review overhead while keeping risky exceptions visible.
👉 Read our full editorial: API exposure is outpacing security controls in digital platforms
