Cloud Web Application Firewall: L7 protection, OWASP Top 10, bot protection, and APIs

A cloud WAF (Web Application Firewall) is not a “shield that covers all application security,” but a managed control layer for HTTP/HTTPS traffic. It operates at Layer 7 and analyzes a request before it reaches the application or API.

This layer is useful where the risk is visible in the request itself: a suspicious URI, a malicious parameter, an unusual header, an SQL injection or XSS attempt, endpoint scanning, a high request rate, brute force, credential stuffing, and automated traffic.

However, it does not understand all business logic. If a user with a valid token accesses someone else’s object, invokes a forbidden function, or bypasses a process rule, the request may look technically normal. In these cases, application-level authorization, an API gateway, object ownership checks, tenant isolation, and secure coding are required.

The simplest way to divide the roles is as follows:

• At Layer 7, the method, URI, parameters, headers, cookies, request body, request rate, and client indicators are inspected;
  
• OWASP Top 10 helps identify categories of risk, but it does not mean that every item can be fully addressed at the perimeter;
  
• For APIs, the request schema, authorization, limits, endpoint inventory, and object-level access control are especially important;
  
• Rate limiting and bot protection reduce automation and abuse, but they must be tuned to the actual traffic profile;
  
• Implementation is best started in observation mode, with false-positive analysis and event forwarding to a SIEM or monitoring system.

Ultimately, this layer is needed alongside secure code and architecture, not instead of them. It reduces noise, blocks common malicious payloads, helps temporarily compensate for known vulnerabilities, and provides SecOps/DevOps with events for investigations. However, access rights, business logic, sessions, and vulnerability remediation remain the responsibility of the application and the development process. A WAF also provides virtually no protection against DDoS; other tools are used for that.

WAF Visibility at Layer 7

To understand where a WAF actually helps, you first need to define where it makes decisions. A cloud WAF is typically deployed in front of a website or API: at the CDN, load balancer, reverse proxy, or API gateway layer. A client request first passes through this layer, is evaluated against rules, and only then is forwarded to the application.

This means that a WAF makes decisions based on what is visible in the HTTP/HTTPS request: the method, path, parameters, headers, cookies, body, request rate, and client signals. It can block a suspicious payload, limit automated traffic, present the client with a challenge, or log an event for investigation.

However, this control has a boundary. A WAF can see the structure and indicators of a request, but it does not always understand the business meaning of the operation. It may detect that a parameter looks like a SQL injection attempt. But it is not expected to know whether a specific user is allowed to view order 124 if the request looks like a normal GET /api/orders/124.

It is therefore important to examine two questions next: which tasks a WAF addresses at Layer 7, and where responsibility remains with the application, API gateway, and authorization system.

What a Cloud WAF Does at Layer 7

Application Layer

A WAF is classified as L7 because it analyzes more than just the IP address, port, and protocol. A network firewall operates at a lower layer: it makes decisions based on addresses, connection direction, and ports. L3/L4 DDoS protection mitigates volumetric attacks: packet floods, large numbers of connections, or link saturation.

At the application layer, the contents of the HTTP request are inspected: which resource was requested, which parameters were passed, what is in the headers and body, and whether the request resembles vulnerability exploitation or automated abuse.

This kind of analysis is not the same as a full understanding of the application. It is application-layer inspection: a request can be allowed, blocked, recorded as an event, rate-limited, have a challenge sent to the client, or be evaluated against additional conditions.

What actions can a WAF perform

At this layer, several mechanisms are typically used: managed rules for common attacks, custom rules for specific routes, allow/block lists, rate limiting, bot protection, challenges or CAPTCHA, geo and ASN restrictions, temporary vulnerability mitigation until the code is fixed, and event export for analysis.

For example, a normal GET /catalog request passes through without intervention. A search request with a parameter that looks like an SQL injection may be blocked based on a signature, content, or an anomalous character set. By contrast, GET /users/124 may look entirely valid: the method is allowed, the path exists, and the headers are normal.

If object 124 belongs to another user, this is no longer just a matter of the HTTP request format. An authorization check is required here: who is making the request, which object they are accessing, and whether they are allowed to perform the action.

This is the practical boundary of L7 control. A WAF works well when the risk is reflected in the request’s structure, content, frequency, or source. However, the semantics of the operation must be validated by the application, an API gateway, or a separate authorization layer.

These capabilities can then be mapped to the OWASP Top 10: which risks can actually be mitigated at the perimeter, and which remain inside the application and API.

OWASP Top 10 and the limits of a WAF: which attacks it mitigates and which remain within the application

The OWASP Top 10 is useful as a risk map. Some threats are clearly visible at the HTTP request level, while others do not look suspicious without knowledge of the user, role, object owner, and operation state.

For example, SQL injection often appears in a characteristic payload: quotes, operators, and attempts to change the query logic. By contrast, GET /api/orders/124 from a user with a valid token may be syntactically correct, but still violate access controls if the order belongs to another customer.

Where a WAF Helps Most

A WAF is strongest against risks that are reflected in the request structure, content, frequency, or a known exploitation pattern.

In these scenarios, a WAF reduces noise and filters out some malicious traffic before it reaches the application. But even here, it does not replace fixing the root cause: the vulnerable component must be updated, unsafe output handling must be fixed, and unnecessary endpoints must be closed.

When a WAF Helps Only Partially

There are risks for which a WAF is useful as an external control, but it cannot be the only protection mechanism.

Brute force and credential stuffing can be mitigated through rate limiting, bot protection, challenges, and route-level restrictions. However, login protection still requires MFA, session management, password policies, checks for leaked credentials, and monitoring of suspicious attempts.

Excessive API requests and resource consumption are also partially addressed at the perimeter through limits by route, IP address, token, or tenant. Within the architecture, however, quotas, queues, optimization of expensive requests, and protection of business resources are still required.

Bot scraping can be limited based on behavioral signals, request frequency, source reputation, and bot score. However, if the data is publicly available, additional measures are needed: data delivery rules, data volume controls, contractual restrictions, and separate conditions for search crawlers, monitoring systems, and partners.

What Remains Within the Application and API

The most important boundary is where the risk is tied not to the structure of the request, but to the business context.

BOLA/IDOR and BFLA often look like normal, valid API requests. The user is accessing an existing object or function, the token is valid, and the JSON is properly formed. The issue lies elsewhere: whether the user is allowed to read that object, modify that resource, or invoke that administrative operation.

The same applies to insecure design, broken authentication, weak sessions, and abuse of business logic. A WAF can detect certain traffic anomalies, but it does not replace designing secure logic, token management, tenant isolation, role checks, or session lifecycle management.

The conclusion is straightforward: a WAF is most useful when the attack is visible in the HTTP request or in repeated client behavior. If the risk depends on who is performing the action, which object is being acted on, and in what business context, the control must reside within the application, the API gateway, and the authorization system.

This provides a more realistic security model. A WAF reduces the load on the application, filters out clearly malicious and automated traffic, and helps buy time when known vulnerabilities are present. But secure coding, component updates, proper session handling, and access control checks remain mandatory parts of the architecture.

API Protection: Where a WAF Helps and Where Access Control and Request Schemas Are Needed

In APIs, risk is often hidden deeper than a typical malicious payload. A request may be syntactically valid: the token is valid, the JSON is well formed, the method is allowed, and the endpoint exists. However, the user may be accessing someone else’s object or invoking a function they are not authorized to use.

A typical BOLA/IDOR example is a user changing /api/users/123 to /api/users/124. To a WAF, this may look like a normal GET request to an existing API endpoint. The risk is not in the request format, but in the fact that object 124 belongs to another user. BFLA is similar: the /api/admin/reports path can be described in a policy, but the access decision must be based on the user’s role and context.

For APIs, it is more useful to focus not on a single layer of protection, but on the separation of responsibilities:

A WAF can block DELETE where only GET is expected, validate the Content-Type, filter out a malicious request body, block endpoint enumeration, and apply basic limits. This is an important first layer that reduces noise and keeps some clearly harmful traffic from getting inside.

However, the decision of whether this user is allowed to perform this action on this object must be made closer to the access model. That is where the object owner, role, tenant, permissions for the operation, JSON or GraphQL request schema, API versions, and deprecated routes are checked.

GraphQL illustrates this boundary well. A WAF can limit body size and request frequency, but query depth, computational complexity, and access to specific objects need to be controlled separately.

As a result, a WAF is useful for APIs as an external filter, but not as a replacement for authorization. It helps stop malicious payloads, scanning, and some excessive request activity. BOLA, BFLA, tenant isolation, and business logic risks must be addressed in the API gateway and the application.

Many forms of API abuse appear not in a single request, but in a sequence of actions. This makes it important to examine rate limiting and bot protection next.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

Rate limiting and bot protection: controlling automation, load, and abuse

For APIs, it is important to look not only at the request content but also at the client’s behavior over time. A single POST /login request may be a normal login attempt. Ten thousand such requests with different username-password pairs is already credential stuffing. Viewing a single product page is normal; rapidly crawling the entire catalog in sequence is scraping.

Rate limiting does not limit request frequency “in general,” but by a specific attribute or a combination of attributes: IP, the real client IP behind a proxy, user, API token, session, tenant, route, method, or client category.

A single global limit for the entire application almost always works poorly. It is either too lenient and does not stop an attack, or too strict and blocks legitimate users. Limits are therefore best tied to specific scenarios:

Limits should reflect the actual traffic profile. It is useful to first measure how regular users, the mobile application, partner integrations, and internal services behave. Only then should thresholds be set for routes, tokens, tenants, and client categories.

Bot protection is broader than CAPTCHA. It can take into account client behavior, navigation speed, repeated actions, source reputation, browser or device fingerprinting, JavaScript checks, and bot score. At the same time, allow lists are needed for legitimate bots: search engine crawlers, monitoring systems, partner API clients, and webhooks.

Crude configuration has the opposite effect: it blocks real buyers, breaks integrations, and creates a false sense of security. Rate limiting and bot protection therefore cannot be enabled blindly. They need to be implemented through observation, analysis of triggers, and exception tuning.

WAF Rollout Process: From Monitoring Mode to Phased Blocking

After configuring limits and bot protection, it is important not to switch the WAF straight into strict blocking mode. Otherwise, you may end up with protection that works but does more harm than good: a rule may treat a comment field with HTML markup, a partner’s JSON request, or a payment system webhook as suspicious—and break checkout, search, or an integration.

Observe and tune first

It is more practical to deploy a WAF as a managed cycle:

1. Place the WAF in front of the application and API;
2. Verify routing, TLS, headers, and forwarding of the client’s real IP address;
3. Enable observation mode without blocking requests;
4. Collect events for critical flows: login, payments, search, file uploads, APIs, and webhooks;
5. Review false positives and identify where rules are firing on legitimate traffic;
6. Configure targeted exclusions;
7. Move to blocking mode first for high-confidence and critical detections.

False positives are not a sign of a poor WAF; they are a normal part of implementation. Rich text, complex search, GraphQL, JSON APIs, multipart uploads, and legacy applications often look “noisy” to universal rules. The goal is not to disable protection entirely, but to narrow the exclusion to the smallest safe scope: a specific field, path, method, rule, or client group.

Then tailor rules to actual routes

Configuration should account not only for the attack type, but also for the specific route. For public search, a broad character set may be acceptable, but rate limiting is required. For /login, it is more important to track brute-force attempts, repeated failures, and automation. For /api/admin/*, stricter conditions for methods, sources, and roles may be appropriate.

Partner webhooks often require separate rules: the expected source, a signature, the correct Content-Type, a stable path, and a clear request format. These integrations should not be subject to the same aggressive restrictions as regular user traffic.

A rule can be considered ready for blocking when the logs show that it consistently catches malicious or clearly unwanted traffic without affecting normal user and integration scenarios.

Forwarding Logs to a SIEM and Monitoring System

WAF events should be sent to a SIEM or monitoring system rather than kept only in the cloud provider’s console. They are needed for investigations, correlation with application logs, SecOps/DevOps response, and further rule tuning.

A minimally useful data set looks like this:

This data should be correlated with logs from the application, API gateway, CDN, load balancer, and authentication system. For example, if the SIEM detects thousands of credential stuffing events on /login while the application also records an increase in login errors and MFA lockouts, this is no longer an isolated WAF trigger but a security incident in the form of a targeted attack.

Conversely, after a release, the WAF blocks requests to /api/payments/webhook, but all of them come from a known payment provider and have a valid signature. This looks like a false positive: the rule should be analyzed and the exception narrowed, rather than disabling protection for the entire API.

After implementation, a WAF becomes an operational process rather than a static setting in the cloud console. Rules, exceptions, limits, and events should be reviewed regularly, especially after releases, the introduction of new APIs, changes in the traffic profile, and the connection of partner integrations.

Conclusion

A cloud WAF is useful as a managed Layer 7 control layer: it reduces risk where an attack is visible in the HTTP request, request rate, automation, scanning, or a known exploit pattern. Once rules, exceptions, limits, and event forwarding to monitoring are configured, it becomes not just a checkbox at the perimeter, but a practical tool for protection and investigations.

However, a WAF does not replace secure coding, an API gateway, or architectural security. Authorization, object ownership checks, business logic, sessions, tenant isolation, and vulnerability remediation remain within the application and the development process. Therefore, a WAF should be treated as an external layer that is regularly tuned based on logs and adapted to the real-world scenarios of the website or API.

FAQ

Does a WAF cover the entire OWASP Top 10?

No. A WAF can mitigate some risks, such as SQL injection, XSS, path traversal, scanning, and certain exploit payloads. However, broken access control, authorization flaws, unsafe business logic, and insecure design require fixes in the application and architecture.

How is a cloud WAF different from a traditional firewall?

A network firewall primarily works with IP addresses, ports, and protocols. A WAF analyzes HTTP/HTTPS at Layer 7: methods, URIs, parameters, headers, cookies, and the request body. This makes it better suited for protecting web applications and APIs against application-layer attacks.

Can a WAF be enabled in blocking mode right away?

Usually not. Without a monitoring mode, there is a high risk of blocking legitimate forms, API requests, webhooks, or partner integrations. A more practical approach is to collect logs first, review false positives, and only then enable blocking in stages.

Can a WAF help protect an API?

Yes, but only to a limited extent. A WAF is useful for filtering malicious payloads, rate limiting, blocking scanning activity, and preventing some automated abuse. However, BOLA, BFLA, tenant isolation, and object-level authorization checks must be enforced in the API gateway and the application.

Is CAPTCHA sufficient to protect against bots?

No. CAPTCHA is only one verification mechanism. More reliable bot protection takes into account the frequency of actions, client behavior, source reputation, device fingerprints, bot categories, and allow lists for search crawlers, monitoring, and partner systems.

Which WAF events should be sent to a SIEM or monitoring system?

At a minimum, the following are useful: event time, source IP and forwarded IP, URI, method, rule action, rule ID, matched field, request ID, user/account ID if available, bot score, rate limit event, and upstream response code. This data helps investigate attacks, identify false positives, and tune rules.

Sources

1. OWASP Top 10:2021

2. OWASP API Security Top 10 2023

3. OWASP Core Rule Set / ModSecurity CRS 

4. AWS WAF Developer Guide