Join our Newsletter — 33% off our NHI Course

API security beyond the edge: are your controls keeping up?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16623
Topic starter  

TL;DR: Edge controls can block obvious traffic, but they miss shadow APIs, third-party API flows, and slow-moving abuse patterns such as BOLA, according to Salt. API security needs discovery, posture governance, and runtime monitoring because perimeter enforcement alone cannot govern what it cannot see.

Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API Security is Not a Problem You Can Solve at the Edge”.

Key questions

Q: What breaks when API protection stops at the boundary?

A: Boundary-only protection fails when legitimate requests are accepted but the system still allows them to expose data, trigger unintended actions, or fan out into unsafe downstream workflows.

Q: Why do shadow APIs and third-party flows increase API risk?

A: They create access paths that traditional edge controls cannot inspect consistently.

Q: What are the signs that BOLA detection is failing?

A: Warning signs include repeated requests across similar object IDs, account-level access that changes slowly over time, and legitimate-looking sessions that accumulate access to records they should not reach.

Practitioner guidance

  • Inventory APIs from inside the environment Use internal telemetry, service maps, and application logs to identify undocumented endpoints, direct service calls, and shadow APIs that perimeter tools miss.
  • Track third-party API dependencies and token scope Record which internal workloads call external APIs, what data they send, which tokens they use, and whether those credentials can be revoked or narrowed.
  • Add behaviour-based detection for BOLA patterns Look for repeated object enumeration, unusual sequential identifier access, and session activity that gradually expands across accounts or tenants.

Bottom line: Edge-only controls leave blind spots where shadow APIs, direct service calls, and external integrations can move data without meaningful perimeter oversight.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 17054
 

API discovery has become an identity visibility problem, not just an application inventory problem. If teams do not know which APIs exist, they cannot know which credentials, tokens, or delegated trust relationships are in scope. That makes discovery the first governance control, not a side task. Practitioners should treat undocumented endpoints as unmanaged access paths.

A few things that frame the scale:

A question worth separating out:

Q: How should security teams secure public APIs without relying only on perimeter controls?

A: Security teams should treat API security as application-layer protection, not just network filtering. Public APIs need access control, authentication, input validation, privacy controls, and continuous detection for abuse patterns such as stolen tokens, credential stuffing, and reverse engineering. WAFs, gateways, and IAM help, but they do not fully protect each API’s logic or data exposure risks.

👉 Read our full editorial: API security beyond the edge: why discovery and runtime matter



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.