Should organisations rely on WAF rules alone for public APIs?

No. WAF rules are useful, but they should be one layer in a broader control set that includes behavioural analytics, request normalisation testing, and application-side validation. For APIs used by service accounts or automation, this layered approach is essential.

Why This Matters for Security Teams

Public APIs are now a primary attack surface, not a niche integration channel. Relying on WAF rules alone creates a false sense of control because many API attacks do not look like classic web abuse. Authentication abuse, schema probing, broken object access, and low-and-slow automation can pass through pattern-based filters unless the application itself validates intent and context. The NIST Cybersecurity Framework 2.0 reinforces that protection should be layered across governance, identity, detection, and resilience, not concentrated in a single control.

For API security, the practical risk is that a WAF may block obvious payloads while missing legitimate-looking requests that are still malicious. That matters even more when APIs are consumed by service accounts, partners, or automation, because those identities can generate high volumes of trusted traffic that blends into normal operations. Security teams often tune rules for noise reduction and later discover that the same tuning has reduced visibility into abuse patterns.

In practice, many security teams encounter API abuse only after account misuse or data leakage has already occurred, rather than through intentional prevention.

How It Works in Practice

A stronger API control stack starts with the WAF, but does not stop there. WAF rules are best at filtering known bad patterns, enforcing coarse request limits, and reducing exposure to generic injection attempts. They are much less reliable for business-logic abuse, credential stuffing against API tokens, parameter manipulation, or attacks that use valid syntax and authenticated access.

Practical API defence usually combines multiple layers:

• Request normalisation and schema validation before the application processes input.
• Authentication and authorisation checks inside the API, not only at the edge.
• Behavioural analytics for unusual call rates, access paths, and error patterns.
• Token and secret hygiene for service accounts, including rotation and scoped privilege.
• Logging that preserves request context so anomalies can be investigated quickly.

The key design idea is that each control should compensate for the blind spots of the others. A WAF can reject obvious abuse, while the application can verify whether a request is valid for the caller’s role, object scope, and workflow state. That aligns well with broader guidance in the OWASP API Security Top 10, where broken authorisation and excessive data exposure are treated as application problems, not perimeter problems.

For automation-heavy environments, the identity layer matters as much as the transport layer. Service accounts, workload identities, and API keys should be treated as privileged identities with explicit ownership, limited scope, and monitored use. If these identities are shared across pipelines or environments, a WAF cannot distinguish legitimate automation from misuse.

These controls tend to break down in high-throughput, multi-tenant API gateways because inconsistent schemas, legacy endpoints, and shared service credentials make normalisation and anomaly detection unreliable.

Common Variations and Edge Cases

Tighter API controls often increase integration overhead, requiring organisations to balance false positives against the risk of undetected abuse. That tradeoff becomes sharper when APIs support third parties, mobile clients, or rapid development cycles. In those settings, teams may be tempted to widen WAF exceptions to preserve availability, but best practice is evolving toward more application-aware enforcement rather than broader perimeter trust.

There is no universal standard for how much inspection should occur at the WAF versus the application layer. For simple public endpoints, WAF rules may provide useful first-line filtering. For authenticated APIs, especially those handling payments, personal data, or machine-to-machine actions, the more important control is contextual authorisation and validation after authentication.

This is also where identity governance intersects with API security. If an API is used by service accounts, agents, or scheduled jobs, those identities need traceability and lifecycle control. Without that, incident response becomes difficult because security teams cannot easily determine whether a request was a legitimate automation event or an abuse attempt. Guidance from the CISA Known Exploited Vulnerabilities Catalog is useful here as a reminder that exposure is usually cumulative: perimeter controls help, but the exploit path often emerges from a chain of weak points rather than a single missed rule.

Related resources from NHI Mgmt Group

• What breaks when credential stuffing controls rely on WAF rules alone?
• Should organisations rely on detection alone for secrets management?
• What breaks when organisations rely on MFA alone for digital interactions?
• What breaks when impossible travel rules rely on IP location alone?