A customer portal can have a well-configured WAF and still expose every account through a single flawed API authorisation check. That is the practical issue behind WAF versus API security. Both controls reduce application risk, but they inspect different problems, operate with different context and produce very different outcomes when an attacker targets modern, API-led services.
For Australian technology leaders balancing security exposure, compliance obligations and limited specialist capacity, the question is not which product category wins. It is whether your current controls match the way your applications actually exchange data.
WAF versus API security: different jobs
A web application firewall sits in front of an internet-facing application and evaluates HTTP and HTTPS traffic against rules, signatures and behavioural thresholds. Its primary job is to stop common web-layer attacks before they reach the application. This includes SQL injection, cross-site scripting, malicious file requests, known exploit patterns, basic bot activity and volumetric request abuse.
A WAF is a sensible perimeter control. It can be deployed relatively quickly, centralise protection across multiple web applications and reduce exposure to commodity attacks. For organisations with public websites, customer portals or legacy applications, it is often a baseline requirement rather than an optional extra.
API security addresses a different layer of the problem. It focuses on the APIs that expose application functions and data to mobile apps, customer portals, partners, internal systems and automated workflows. A capable API security programme identifies what APIs exist, how they are used, whether their behaviour matches the intended schema, and whether access decisions make sense in context.
That context matters. A WAF may see a valid request to retrieve `/accounts/5821`. API security can assess whether the authenticated user should be allowed to retrieve account 5821 at all, whether that endpoint is suddenly returning more data than usual, or whether an unmanaged API version has appeared outside the approved delivery process.
The distinction is simple: a WAF is designed to block hostile web traffic. API security is designed to reduce the risk created by legitimate-looking requests that misuse application logic, identity or data access.
Why a WAF alone leaves API exposure behind
Most damaging API attacks do not look like classic injection attacks. They use valid HTTP methods, valid parameters and valid credentials. The attacker may have obtained those credentials through phishing, credential stuffing or a compromised partner integration. From the network edge, the request can appear entirely normal.
Consider broken object level authorisation, sometimes called an insecure direct object reference. A user changes an identifier in a request from their own invoice to another customer's invoice. The request is syntactically correct. There is no malicious payload for a signature-based rule to detect. The application must verify ownership, and security teams need visibility when that control is missing or being probed at scale.
The same applies to excessive data exposure, weak token handling, overly permissive API keys and business-logic abuse. A fraudster can repeatedly call a legitimate discount, loyalty or payment endpoint in an unintended sequence. A WAF may rate-limit the traffic. It cannot reliably determine whether the workflow itself is being exploited unless it has deep, application-specific context.
API estates also change faster than traditional web applications. Development teams release new endpoints for mobile features, partner integrations, analytics and automation. Old versions remain live because another system still depends on them. Documentation drifts. Shadow APIs appear through cloud services, acquisitions or teams working to delivery deadlines.
This is where API discovery becomes commercially relevant. You cannot secure, test or demonstrate control over APIs that nobody has catalogued.
When a WAF leads, and when API security leads
A WAF should lead when the immediate concern is broad protection for public-facing websites and web applications. It is particularly useful for reducing common attack traffic, shielding older applications while remediation is scheduled, and applying consistent edge controls across a portfolio.
API security should lead when applications process sensitive customer, employee, financial or operational data through APIs. It is also the priority where the business relies on mobile apps, B2B integrations, microservices, developer-facing platforms or automated workflows. In these environments, the attack surface is not just a website. It is an expanding set of machine-to-machine interfaces.
For many enterprise teams, the right answer is both, with clear responsibilities. The WAF handles web-layer filtering and traffic controls. API security provides API inventory, schema and behaviour analysis, sensitive-data visibility, runtime detection and testing support. Identity controls, an API gateway, secure development practices and centralised logging complete the operating model.
An API gateway is useful but should not be confused with a full API security programme. Gateways can enforce authentication, routing, quotas and policy. They do not automatically find unmanaged APIs, identify flawed business logic or prove that every endpoint is returning only the data a user is entitled to see.
Build controls around the data path
The practical architecture begins with a current inventory. Map public, partner, internal and mobile-facing APIs. Record owners, environments, authentication methods, data types, dependencies and version status. If an endpoint has no accountable owner, it is already a risk decision by default.
Next, enforce identity and authorisation at the application layer. Use short-lived tokens where appropriate, validate scopes and claims, and apply least privilege to service accounts. Most importantly, test authorisation at object level. A user being authenticated does not mean they are authorised to access every record the API can technically retrieve.
Then apply traffic controls at the edge and gateway. Rate limits, bot management, request-size controls and geo or reputation-based policies can reduce automated abuse. These controls are valuable, but they should support application security rather than substitute for it.
Finally, monitor for behavioural changes. High request volumes matter, but so do quieter indicators: a partner token accessing unfamiliar endpoints, an API returning unusual field sets, repeated authorisation failures across sequential object IDs, or a legacy version receiving traffic after its expected retirement date. Alerting without ownership is noise, so route these findings to the team that can validate and fix them.
The operational trade-offs security leaders need to manage
A WAF can create false positives if rules are tuned too aggressively, particularly during application releases. API security tooling can produce an overwhelming volume of findings if discovery is enabled without an ownership model or a prioritisation process. Neither issue is a reason to avoid the control. Both are reasons to plan the operating model before procurement.
Start with the APIs that create material business impact: customer identity, payments, regulated data, administrative actions and partner integrations. Apply risk-based priorities rather than attempting to treat every endpoint as equally critical. An internal health-check API and a public account-management API do not warrant the same level of scrutiny.
Compliance adds another consideration. ISO 27001, SOC 2, Essential Eight-aligned programmes and APRA-regulated environments all require evidence that security controls are understood, operated and reviewed. A dashboard screenshot is not sufficient evidence on its own. Teams need documented ownership, test results, remediation records, log retention and a clear view of how application risks are assessed.
For lean teams, specialist support can accelerate the initial inventory, configuration review and remediation backlog. The goal is not to outsource accountability. It is to recover time for internal leaders while ensuring the controls can be operated after the engagement ends.
Questions to ask before buying
Procurement decisions improve quickly when security teams move past feature checklists. Ask prospective providers to demonstrate how their approach handles the following:
- APIs that were never registered in a gateway or asset register.
- Valid authenticated requests that access another customer's records.
- Encrypted traffic inspection, performance impact and deployment options.
- Schema drift, deprecated versions and undocumented endpoints.
- Alert triage, workflow integration and evidence for audit reviews.
The answers should be specific to your architecture. If a provider cannot explain how it distinguishes a malicious request from a valid request with unauthorised business context, it is unlikely to close the gap that matters most.
A practical 90-day starting point
In the first 30 days, identify every externally reachable application and API, confirm ownership and classify the data each interface can access. Review WAF coverage and determine whether traffic bypasses it through alternate domains, direct cloud endpoints or third-party integrations.
Over the next month, test the highest-risk APIs for broken authorisation, excessive data return, weak authentication flows and rate-limit bypasses. Fix the issues that expose customer or regulated data first. At the same time, establish minimum requirements for API documentation, authentication, logging and security testing before release.
By day 90, move from a one-off assessment to a managed control cycle. Monitor API changes, review exceptions, test critical paths after major releases and report risk in business terms: records exposed, fraud opportunity reduced, remediation effort avoided and compliance evidence available.
The sensible next move is to assess your exposed applications against the controls you already own, then close the gaps with a defined operating model. Book a Discovery Call to turn that assessment into a prioritised security plan.