The web tier is where most attacks land first
Most compromises of a public-facing application begin at the same place: the web and API layer that anyone on the internet can reach. The scale of the pressure on that layer is no longer abstract. In its 2025 Q4 threat report, Cloudflare said it mitigated 47.1 million DDoS attacks over the year, a 121% jump on 2024, and blocked a single assault that peaked at 31.4 terabits per second. That is the loud, volumetric end of the problem. The quieter end, a crafted request that slips past input validation or an API call that returns another customer's records, rarely makes the news, and in our engagements it is where the real damage tends to happen.
For years the answer to this was a web application firewall bolted in front of the app, tuned once, and left alone. That model is breaking down. Attacks now arrive across four fronts at once: volumetric floods, automated bots, classic web exploits, and business-logic abuse of APIs. Defending against one while ignoring the others buys very little. This article walks through what a modern web application and API protection setup actually needs to do, where the pieces sit, and the tuning work that decides whether any of it helps.
What a web application firewall is for
A web application firewall inspects HTTP and HTTPS traffic between clients and an application, and blocks requests that match known attack patterns or deviate from expected behaviour. The reference point most teams use is the OWASP Top 10: injection, cross-site scripting, broken access control, and the rest of the categories that account for the bulk of exploited web vulnerabilities.
WAFs work in two broad modes, and the distinction matters more than vendors admit. A negative security model blocks traffic that matches signatures of known attacks. It is quick to deploy and catches commodity exploit attempts, but it is always one step behind a novel payload. A positive security model allows only traffic that matches a defined, expected shape, and rejects everything else. It is far stronger, and far more work, because you have to describe what "normal" looks like for every endpoint. In practice, a good deployment runs both: signatures for the obvious, and a learned or declared model of legitimate behaviour for the endpoints that matter.
The most underrated thing a WAF gives you is virtual patching. When a critical vulnerability lands in a framework or library and the code fix has to go through testing and a release window, a WAF rule can block the exploit path within the hour. We have used that window repeatedly to keep regulated systems protected while a patch worked its way through change control. It is not a substitute for fixing the code, but it turns a fire drill into a scheduled task.
Why the standalone WAF is becoming WAAP
IDC's 2024 review of the WAF market makes the direction plain: web application and API protection, or WAAP, is the common evolution of the product category. Instead of a WAF alone, the market is consolidating anti-DDoS, bot management, and API protection into a single layer, either as one product or as a coordinated set of controls. IDC put China's WAF hardware market at 1.38 billion RMB in 2024 and its cloud WAF market at 2.55 billion RMB, with compliance demand named as the driver of the rebound. The regional figures are less important than the shape of the trend, which we see globally: buyers want the four functions to work together, not as four consoles that never talk to each other.
The reason is operational, not marketing. An attacker rarely uses one technique. A credential-stuffing run against a login API is a bot problem, an API problem, and a rate-limiting problem at the same time. If your bot defence and your WAF and your API gateway each see a slice of it and none of them see the whole, the attack succeeds in the gaps between them. Bringing the controls into one enforcement point, with shared telemetry, is what closes those gaps.
The diagram below shows how the four layers sit in front of an origin application, each removing a class of traffic before it reaches the next.
Each layer removes traffic the next one should never have to see, and each is best placed in a different spot: DDoS scrubbing upstream in the cloud, the WAF and API controls close to the application, with every layer reporting into the same monitoring.
APIs are now the larger attack surface
Most applications today are mostly API. A single-page front end or a mobile app is a thin shell over dozens of backend endpoints, and those endpoints are where the sensitive logic and data live. A WAF tuned for HTML form abuse will happily pass an API request that is perfectly well-formed but asks for a record the caller has no right to see.
That gap is exactly what the OWASP API Security Top 10 documents. Its top entry, API1:2023 Broken Object Level Authorization, is the case where an endpoint returns object number 1002 to a user who should only see 1001, because the code checks that you are logged in but never checks that the object is yours. API3:2023, Broken Object Property Level Authorization, is the same failure one level down, at the field. Neither is a payload a signature can catch. They are logic flaws, and defending them takes controls a classic WAF was never built for: schema validation against a published API contract, per-endpoint and per-token rate limiting, and authorization enforced at the gateway rather than left entirely to the application.
The first practical step, before buying anything, is discovery. In almost every API security assessment we run, the client's live estate includes endpoints nobody remembered: a deprecated version still routing traffic, a staging path exposed to the internet, an internal service reachable from outside. You cannot protect an API you do not know is there, so an accurate inventory comes first, then protection.
Planning for terabit-scale DDoS
Denial-of-service attacks have moved into a range that on-premises hardware simply cannot absorb. The record Cloudflare cited, 31.4 Tbps, would saturate the uplink of most enterprises many times over before a single on-box appliance had a chance to filter anything. IDC's Global Cybersecurity Services Survey found 35% of CIOs consider DDoS mitigation crucial to their defence, with 20% planning to keep increasing investment, and its 2024 anti-DDoS market analysis flagged the rise of terabit-class and intelligent attacks, along with a nastier trend: DDoS used as cover for data theft, and DDoS bundled with ransom demands.
Getting the response right means separating the layers. Volumetric floods, at layers 3 and 4, have to be absorbed upstream, in a scrubbing network or a cloud provider's edge, well before they reach your circuit. Protocol attacks that exhaust connection tables sit at a similar point. Application-layer attacks, at layer 7, are the subtle ones: a modest volume of requests that each look legitimate but together exhaust a database or an expensive endpoint. Those are caught close to the application, by the same rate-limiting and behavioural analysis that the WAAP layer already runs. A DDoS plan that only addresses one of these layers leaves the others open, and attackers test all three.
This is also why the market is moving toward managed DDoS protection delivered as a service rather than a box you own. Telecom operators, which we have worked with directly, were the single most-targeted sector in Cloudflare's 2025 data, and no operator mitigates a 31 Tbps flood on equipment sitting in its own data centre. The scale of the threat has outgrown the appliance model.
The newest layer: protecting the model, not just the app
IDC's WAF report calls out one genuinely new category worth planning for. As organisations put large-language-model features into production, a class of attack specific to those models has appeared: prompt injection, jailbreak attempts, training or context data leakage, and content-compliance failures. The industry term forming around the defence is the LLM firewall, or LLM-WAF, and it inspects the prompts going into a model and the completions coming out, much as a WAF inspects requests and responses.
If your organisation is shipping a chatbot, an internal copilot, or any agent that acts on user input, this belongs on the roadmap now rather than after the first incident. The controls are early and imperfect, but the exposure is real, and treating a model endpoint as just another API misses the ways it can be manipulated through language rather than through a malformed request.
Compliance has made this mandatory
The strategic case for web application protection is now also a regulatory one. Under PCI DSS v4.0, requirement 6.4.2 makes an automated technical solution, in practice a web application firewall, mandatory for public-facing web applications. It became a full requirement on 31 March 2025, replacing the older option in requirement 6.6 that let organisations choose between a WAF and manual code review. For anyone handling cardholder data, the WAF is no longer optional and the review-instead-of-WAF path is closed.
PCI DSS is the sharpest example, but the same expectation runs through ISO/IEC 27001 control over secure development and network protection, and through the protective controls of the NIST Cybersecurity Framework. In our banking work, a WAF has long been a baseline control, sitting alongside encryption of data in transit and at rest, network segmentation, and continuous monitoring, all of it evidenced for auditors under Qatar Central Bank oversight and against PCI DSS, ISO 27001, CIS Benchmarks, and STIG. The regulators moved because the attack data moved. The organisations that treated a WAF as a baseline years ago are the ones now spending their compliance effort on evidence rather than on scrambling to deploy.
Where should the firewall sit?
Deployment model is the decision that most affects latency, resilience, and how much of the work your team carries. There is no single right answer; the fit depends on the application, the traffic profile, and where TLS is terminated. The table below compares the four common models.
ModelHow it worksStrengthsTrade-offsBest fit
Cloud / CDN-based
Traffic routed through the provider's edge before reaching the origin
Absorbs volumetric DDoS upstream; elastic; fast to deploy
Provider terminates TLS; less control over inspection logic
Public web apps and APIs needing DDoS scale
Reverse-proxy appliance
Dedicated appliance or virtual appliance in front of the app
Full control; deep inspection; keeps traffic in your estate
You own capacity planning and cannot absorb terabit floods alone
Regulated on-premises or private-cloud workloads
Host / embedded
WAF module running on the web server itself
Sees decrypted traffic; no extra network hop; per-app rules
Consumes app-server resources; scales with each host
Hardened single-purpose servers, such as internet banking front ends
Container sidecar
WAF deployed as a sidecar alongside each service
Fine-grained, per-service policy; fits DevOps pipelines
Operational overhead across many services
Cloud-native and microservice architectures
The embedded model is worth a specific note, because IDC's own data shows cloud-native WAF, built to fit containers and DevOps pipelines, as the fastest-growing segment. But embedded still has its place. For one bank's internet banking platform we built a hardened web-server component with a custom WAF layer embedded directly in the server, so inspection happened on decrypted traffic at the application host, under the same change control and audit regime as the rest of the estate. When the traffic is sensitive and the server is single-purpose, putting the firewall on the host removes a hop and a trust boundary. The right model is the one that matches the workload, not the one a single vendor happens to sell.
Tuning is the work that decides everything
A WAF that is deployed but not tuned is worse than useless, because it creates the belief that the application is protected while it blocks nothing meaningful, or blocks so much legitimate traffic that someone quietly switches it to log-only and forgets. The gap between a WAF on the network diagram and a WAF that actually stops attacks is entirely in the tuning.
The pattern that works is staged. Start in monitoring mode and watch what the rules would have blocked, against real production traffic, for long enough to see the weekly and monthly patterns. Build allowlists for the legitimate traffic that trips generic signatures, which there always is in any real application. Move to blocking a rule set at a time, most confident rules first, rather than flipping everything to enforce at once. Write custom rules for the endpoints and abuse cases specific to your application, because the generic signatures never cover your business logic. Keep signatures and threat feeds current, since a negative model is only as good as its last update. And send every WAF event into your SIEM, so the firewall becomes a detection source feeding your SOC and SOAR playbooks, not an island that logs to itself.
That last point is where a WAF earns its keep beyond blocking. The same events that stop an attack are early signal for everything else. A spike in blocked requests against one endpoint is often the first visible sign of a campaign that will escalate, and a WAF wired into monitoring gives your team hours of warning it would not otherwise have.
A rollout checklist
- Inventory every public-facing web application and API endpoint, including deprecated versions and staging paths, before choosing any control.
- Map each asset to its compliance obligations, so PCI DSS 6.4.2 and equivalent requirements drive scope rather than surprise you at audit.
- Choose a deployment model per workload, matching cloud, appliance, embedded, or sidecar to the traffic profile and where TLS terminates.
- Deploy in monitoring mode first and collect at least a full traffic cycle before blocking anything.
- Build allowlists and custom rules for your application's real behaviour and business logic.
- Enable blocking in stages, most confident rules first, and confirm no legitimate traffic is caught at each stage.
- Add API schema validation and per-token rate limiting for anything exposing an API.
- Arrange upstream DDoS scrubbing sized for volumetric and protocol attacks you cannot absorb on your own circuit.
- Forward all events to your SIEM and connect them to SOC monitoring and SOAR response.
- Review rules and false-positive rates on a fixed cadence, and keep signatures and threat feeds current.
How Aydahwa Enterprise Can Help
Aydahwa Enterprise has built and operated web application and API protection for environments where getting it wrong is not an option, including internet banking platforms running under Qatar Central Bank oversight and against PCI DSS, ISO 27001, CIS Benchmarks, and STIG, and telecom platforms serving traffic at national scale. That work spans the full stack described here: WAF architecture and tuning, API discovery and protection, upstream DDoS mitigation, and the SIEM and SOC integration that turns firewall events into usable detection.
If you are standing up a WAF for the first time, retuning one that blocks the wrong things, or closing the gap PCI DSS 6.4.2 now requires, our cybersecurity services and cloud security and migration teams can help you scope and deliver it, and our managed IT support can run it once it is live. To gauge where you stand today, start with our free cybersecurity self-assessment and the cybersecurity readiness checklist. When you are ready to talk through your own environment, get in touch.
