Topic starter
11/11/2026 5:59 pm
TL;DR: APIs stay exposed to authentication flaws, undocumented endpoints and business-logic abuse when security is bolted on late, according to Aptori. Continuous testing, discovery and governance shift risk management earlier, where broken access control and hidden interfaces can still be stopped.
Editorial analysis by NHI Mgmt Group, based on content published by Aptori: “Continuous API Security: Ensuring Robust Protection in the API Lifecycle”.
Key questions
Q: Why do undocumented APIs create security risk even if the WAF is deployed?
A: Undocumented APIs sit outside the policy boundary used to configure the WAF, so they can receive traffic without inspection or alerting.
Q: How do SAST and DAST complement each other in API testing?
A: SAST and DAST complement each other by testing APIs at different stages and from different angles.
Q: How should security teams prevent BOLA in modern API environments?
A: Security teams should enforce object-level authorisation inside the application, not at the edge.
Practitioner guidance
- Establish continuous API inventory reconciliation Compare discovered endpoints against service ownership, retirement status and policy coverage on a fixed cadence so shadow and stale APIs do not remain reachable.
- Gate releases on authentication and authorization checks Make deployment contingent on passing tests for authentication, authorization and workflow abuse, not just code compilation or unit tests.
- Test business logic with attack workflows Exercise multi-step request sequences that use valid syntax but abusive order, volume or state transitions to expose workflow flaws.
Bottom line: APIs become harder to defend when discovery, authentication and policy enforcement are treated as separate stages instead of one continuous control.
Glossary terms: Application security testing, SAST, DAST Coverage, Software Composition Analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
Continuous API security is an access-governance problem before it is a testing problem. The article is right to put discovery, policy and monitoring together, because API risk rarely comes from one flaw alone. In modern estates, the real issue is that access paths change faster than manual review cycles can track them, so controls have to operate continuously across build and runtime stages. Practitioners should treat API governance as part of identity enforcement, not a separate AppSec exercise.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: What is the difference between API security and token governance?
A: API security focuses on who can call a service and under what policy. Token governance goes deeper by controlling how credentials are issued, used, rotated, and revoked across machine identities. In practice, token governance is what lets teams see whether access is still valid, excessive, or being abused.
👉 Read our full editorial: Why continuous API security needs discovery, testing and governance