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

Why This Matters for Security Teams

Public APIs are not secured by hiding behind a network edge. Once an API is internet reachable, the real control point is the application layer: who can call it, what they are allowed to do, and how the service behaves when tokens, keys, or client logic are abused. The NIST Cybersecurity Framework 2.0 makes this clear by treating identity, protection, and detection as continuous functions rather than one-time perimeter checks.

This matters because attackers rarely need to defeat the entire network boundary. They target weak authentication, over-broad scopes, exposed secrets, broken object-level authorization, and replayable tokens. NHIMG research shows the scale of the problem: only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That makes API security an identity and authorization problem as much as a transport problem.

In practice, many security teams discover abuse only after data has been enumerated or tokens have already been reused from a legitimate endpoint.

How It Works in Practice

Effective API security combines authentication, authorization, data controls, and runtime monitoring. The goal is to make each request prove not only who is calling, but also what the caller is trying to do and whether that action is safe in the current context. For public APIs, that usually means moving from coarse perimeter filters to request-level policy enforcement.

Start with strong identity for the caller. Human users may authenticate through SSO, but machine clients should use workload identity, short-lived tokens, and scoped service principals. For non-human access, current guidance suggests avoiding long-lived static API keys wherever possible and using ephemeral credentials with narrow permissions and automated revocation. The Ultimate Guide to NHIs is useful here because it frames secrets rotation, visibility, and offboarding as core hygiene, not optional extras.

• Authenticate every request with a verifiable identity token or signed credential.
• Authorize at the resource and action level, not just at the gateway.
• Validate inputs against schema and business logic, not only syntax.
• Log request context, token subject, client app, and unusual access patterns.
• Detect abuse such as credential stuffing, token replay, scraping, and excessive enumeration.

Perimeter tools still matter. WAFs, API gateways, and rate limiting reduce noise and block known bad patterns, but they do not understand every business rule or data sensitivity boundary. That is why teams increasingly pair gateways with policy-as-code and continuous evaluation, using controls aligned to the NIST Cybersecurity Framework 2.0 and with lifecycle practices documented in the Ultimate Guide to NHIs — Standards.

These controls tend to break down when legacy APIs depend on shared secrets embedded in code or when multiple third parties reuse the same integration credentials.

Common Variations and Edge Cases

Tighter API controls often increase integration overhead, so organisations must balance developer friction against reduced abuse risk. That tradeoff becomes especially sharp for partner APIs, mobile backends, and high-volume machine-to-machine services where aggressive throttling or frequent token renewal can disrupt legitimate traffic.

There is no universal standard for this yet, but current guidance suggests a tiered approach. Public read-only APIs may tolerate stronger rate limits and cached responses, while write APIs and financial or personal-data endpoints need stricter authorization checks, replay protection, and anomaly detection. Where third parties consume the API, use separate credentials per partner, per environment, and per use case so a single leak does not expose the entire ecosystem.

One common edge case is reverse engineering of client apps. If a public mobile or browser client embeds API calls, assume the request path, parameters, and tokens can be observed and replicated. Another is over-trusting gateway decisions: once a token is valid, the backend still needs authorization logic that checks object ownership, tenant boundaries, and data minimization rules. NHIMG research on The State of Non-Human Identity Security shows how visibility gaps and weak rotation undermine even well-designed controls.

For that reason, the most resilient pattern is layered defense: identity-bound access, least privilege, runtime policy checks, and continuous detection, with perimeter controls as one layer rather than the whole strategy.

Related resources from NHI Mgmt Group

• How should security teams govern access for remote workers without relying on the office perimeter?
• How should security teams secure database access without relying on VPN trust?
• How should security teams implement password controls without relying on user memory?
• How should security teams secure connected OT devices without relying on the old air gap?