Our use of cookies 
Web Application Firewalls (WAFs) for businesses
Web applications such as websites, cloud platforms, and APIs are central to modern business workflows, but they are vulnerable to HTTPS-based attacks that can disable applications, grant access to internal systems, trick users, or steal data.
Web Application Firewalls (WAFs) protect these by analysing and filtering incoming HTTPS requests based on perceived risk.
This guide explains what a WAF is, the main threats it protects against, how it works, and the various architectures, deployment models, and operational models in use today.
Contents
What is a Web Application Firewall (WAF)?
A Web Application Firewall (WAF) is the gatekeeper for any business web app, including websites, API services, and SaaS platforms.
WAFs analyse incoming HTTPS requests (e.g., logging in, using a service, or making a payment) before they reach the app and calculate their risk based on their apparent legitimacy and the sensitivity of the function they’re trying to access.
Based on this risk, the WAF can respond by allowing, challenging or blocking the requests. For example, if the request has a known threat signature, it’s outright blocked; if it’s only showing anomalous behaviour when accessing a low-risk function, it’s challenged.
Meanwhile, all traffic deemed legitimate passes through, with analysis and response occurring in milliseconds to avoid impacting app performance.
WAFs are different from traditional network firewalls in that they focus on securing HTTPS traffic (also known as “Layer 7”), which web browsers, mobile apps, and APIs use to communicate with each other day-to-day.
Most WAFs are delivered as cloud services or virtual appliances bundled with their hosting, CDN, or e-commerce platforms. For critical apps, global SaaS offerings or sensitive systems, further WAFs are layered to provide additional protection, including appliance-based WAFs in private environments.
While a WAF significantly reduces risk, it is not foolproof. It is one of multiple layers of protection, alongside secure coding practices, proper authentication and authorisation, and network monitoring, that are required to protect a business’s digital estate.
Typical threats a WAF mitigates
WAFs specialise in protecting against threats embedded in (or spamming) HTTPS/HTTP requests targeting websites, cloud apps and background APIs.
These typically involve attackers stress-testing the app by injecting code, making API requests, running scripts, or using bots until they find a misconfiguration they can exploit.
Many of these are documented by the OWASP Top 10, which highlights recurring web and API security risks observed across real-world incidents.
Here we explain the most common threats and how a WAF mitigates them:
Injection attacks
Examples: SQL injection, command injection
Attempts to sneak malicious HTTPS instructions into parts of an application that are not properly locked down, hoping the application will accidentally run them and expose data or perform unintended actions.
WAFs maintain knowledge of known malicious input patterns and signatures, so they can check for their presence in HTTP requests and block them.
Cross-site scripting (XSS)
Examples: Reflected XSS, stored XSS
Attacks where malicious code is injected into a website so that it displays a phishing page instead of the legitimate one when loaded in a browser. Attackers can steal login information or take over user sessions.
WAFs detect and block suspicious script-like inputs before they reach the website, preventing users from ever encountering phishing pages.
Authentication and authorisation abuse
Examples: Insecure Direct Object References (IDOR), Broken Object Level Authorisation (BOLA)
Attacks in which an attacker sends specially crafted requests or data to make an application connect to internal systems it should not, or to process data in an unsafe way, potentially exposing internal services or sensitive information.
WAFs help block these attacks by allowing only known API paths, actions, and ID formats, thereby denying requests that are modified or unexpected.
Server-side request forgery (SSRF) and insecure deserialisation
Examples: Access to internal metadata services, hitting private APIs, unsafe object processing
Attacks where an attacker crafts requests or data to cause an application to connect to internal systems it should not, or to process objects in an unsafe way, potentially exposing internal services or sensitive information.
WAFs can help reduce risk by detecting and blocking some known SSRF patterns, suspicious request destinations, or unexpected data formats before they reach internal systems; however, reliable prevention typically requires application-level context and controls beyond the WAF layer.
Automated abuse and bots
Examples: Credential stuffing, carding attacks, scraping, inventory hoarding
Large-scale, automated attempts to misuse an application, such as trying stolen passwords, testing payment details, copying data, or reserving inventory with no intent to buy.
WAFs can detect automated behaviour and apply controls, such as rate limiting or CAPTCHA challenges, to block it.
Application-layer (Layer 7) denial-of-service attacks
Examples: HTTP floods, slow request attacks
Attacks that overwhelm an application with large numbers of seemingly legitimate requests, making the service slow or unavailable to real users.
WAFs help protect availability by identifying abusive traffic patterns and limiting or blocking excessive requests.
Zero-day attacks
Examples: New injection techniques, previously unknown logic flaws
Attacks that exploit weaknesses in an application that are not yet known or fixed, allowing attackers to abuse the system before developers have time to respond.
WAFs help reduce the risk of zero-day attacks by using virtual patching, blocking known attack techniques and suspicious behaviour while permanent fixes are developed and deployed.
How a WAF works
A WAF filters requests so that only legitimate traffic reaches the web app. In practice, this process involves seven key steps:
1. HTTPS decryption
Most inbound traffic uses HTTPS (Hypertext Transfer Protocol Secure), which encrypts data in transit. For a WAF to inspect requests, it must first decrypt this traffic.
This is done through TLS termination, where the WAF is provided with the certificates required to decrypt incoming requests, inspect their contents, and then re-encrypt the traffic before forwarding it to the backend application.
Because traffic is temporarily decrypted for inspection, this process introduces additional security considerations such as mutual TLS (mTLS) between the WAF and backend services to ensure traffic remains encrypted and authenticated end-to-end.
2. Pre-processing: Request parsing and normalisation
Once decrypted, the WAF standardises each request for analysis by parsing and normalisation.
Parsing
Breaks each request into its individual components to reveal the resources being accessed and the data being supplied. This includes clearly separating:
- The URL path and query parameters (e.g., www.spotlightmedia.com/login)
- The request body into categories (e.g., form fields, JSON, or XML payloads)
- HTTP headers such as cookies and user-agent strings
Normalisation
Standardises the contents by removing formatting tricks (nested or unusual formats) or encoding techniques that attackers may use to hide malicious input. In this way, all data can be analysed consistently.
3. Request and traffic analysis
The WAF analyses each request using multiple techniques in parallel to understand the request content while minimising latency. The choice and depth of these analyses depend on what the WAF is configured to protect.
Each analysis produces a risk signal (e.g., low, medium, or high), which is then combined with others to inform balanced enforcement decisions for each request.
These are the main types of analysis and what they do:
Application context analysis
Goal: Determine whether a request is reasonable for the application and endpoint being accessed.
The WAF examines what the request is trying to do and whether it makes sense for the application. It looks at factors such as:
- Endpoint: What page, function, or API path is being accessed (/login, /checkout, /api)
- Operation: What action is being performed (logging in, making a payment, retrieving data)
The WAF then flags behaviour that is clearly anomalous. For example, submitting text into a search field is expected behaviour, whereas submitting executable instructions into the same field is suspicious or high-risk in this context.
Known threat detection
Goal: Identify requests that match known malicious patterns or sources.
The WAF compares requests against signals that indicate malicious behaviour, including:
- Known attack patterns and signatures: Maintained by the WAF vendor and aligned with common attack techniques
- Threat intelligence: Lists of known malicious sources or emerging attack methods provided through vendor feeds or other cloud platforms
For example, a request containing patterns commonly associated with SQL injection may be flagged as high risk even if it appears structurally valid, while a request with no indicators of known threats may be assessed as low risk.
Abuse and automation detection
Goal: Detect abnormal traffic patterns associated with automated abuse.
In addition to analysing individual requests, the WAF evaluates traffic frequency and timing to detect automated abuse such as credential stuffing or application-layer denial-of-service attacks.
Because traffic patterns vary by application, this analysis uses anomaly scoring and machine-learning techniques to learn normal behaviour for specific endpoints and identify deviations from that baseline.
Signals include:
- Sudden spike in login attempts over a short period, which may indicate credential stuffing.
- Repeated requests to account recovery or payment endpoints, which suggest probing or abuse.
- Requests arriving at perfectly regular intervals or lacking typical browser characteristics.
Response analysis (advanced)
Goal: Detect sensitive data exposure or application errors.
In some cases, WAFs also analyse application responses to identify leaked error messages or sensitive information, helping reduce the impact of successful attacks. However, these are only used in special cases, usually critical applications in finance or defence.
4. Security enforcement
The result of these analyses is a risk signal for each request, which determines the WAF’s response. Risk scoring is not perfect, and legitimate traffic may occasionally be flagged as suspicious, so the goal is to minimise false positives while still blocking real attacks.
Below are the main enforcement actions available to WAFs:
Allow request
The request is allowed through to the app. For example, a user submits a genuine login request from a known location, at a normal rate, with no suspicious input patterns. Since no risk signals are raised, the request is forwarded to the application without interruption.
Rate-limit requests
Requests are allowed, but a maximum rate is enforced. For example, a client sends a large number of requests to a login or search endpoint within a short period of time. While individual requests may appear valid, the overall rate suggests potential abuse. The WAF limits the number of requests allowed to reduce impact while still permitting legitimate use.
Challenge request (CAPTCHA)
A request is allowed only after passing an additional challenge. For example, if traffic to an account-creation or checkout endpoint exhibits behaviour consistent with automated tools but lacks clear exploit indicators, the WAF may issue a challenge (such as a CAPTCHA or other bot-verification step) to verify that the requester is human before granting further access.
Block request
The request is blocked and discarded, and the user or client receives an error response. For example, a request containing input patterns strongly associated with SQL injection that targets a sensitive function will be blocked and discarded (but logged).
Manual responses
Security teams can apply manual controls when needed. If a critical misconfiguration, vulnerability, or suspected exploitation is identified, teams may temporarily block or restrict requests to a specific function or endpoint while developers work on a permanent application-level fix. Once the fix is deployed, the temporary WAF rules can be relaxed or removed.
5. Data protection, logging, and compliance
Because the WAF inspects internet traffic, it inevitably processes sensitive data contained within HTTPS requests and responses. This may include personally identifiable information (PII), authentication tokens, or payment card information (PCI).
To be compliant with cybersecurity regulations and reduce risk, modern WAF platforms provide controls to limit how this sensitive data is handled and stored, including:
- Log masking and redaction: Obscures sensitive fields (such as passwords, session tokens, card numbers, or personal details) before logs are written or exported
- Selective logging: Exclude request bodies or specific headers from logs on sensitive endpoints
- Retention and access controls: Ensures logs are stored only as long as necessary and accessed on a least-privilege basis
Organisations remain responsible for ensuring that any personal data processed by a WAF is handled in line with data protection requirements such as GDPR, including lawful processing, proportionality, data residency, and appropriate retention policies.
6. SIEM/SOAR integration
Since a WAF generates a wealth of detailed security logs from application traffic and enforcement actions, integrating them into a Security Information and Event Management (SIEM) platform for correlation with data from other security controls such as network firewalls, identity systems, business antivirus, and Endpoint Detection & Response is key to identifying broader threats.
For example, a spike in blocked WAF events may be correlated with authentication or endpoint alerts to identify coordinated attack activity. In more mature environments, they may also feed Security Orchestration, Automation and Response (SOAR) workflows.
This integration supports:
- Incident investigation
- Detection of broader attack campaigns
- Compliance and audit requirements (e.g. ISO 27001)
- Coordinated response across multiple security systems
7. WAF maintenance
A WAF is not a “set-and-forget” control, and its configuration must evolve alongside the application it protects. As developers introduce new features, endpoints, or APIs, WAF rules must be updated to reflect the changing behaviour.
- Adjusting rules to reduce false positives
- Tightening controls around new functionality
- Balancing security with usability
- Coordinating changes between security and development teams
See our section on WAF deployment to learn how these are typically rolled out.
The different types of WAF security models
Generally speaking, there are two broad types of web applications:
- Websites, intranets, and SaaS applications, which offer many features and allow a wide range of user behaviours and request types
- APIs and microservices, which typically receive a fixed set of simple and predictable requests
Because the request patterns for these application types are very different, WAFs use two distinct security models to protect them.
Negative security model
Best for: Websites, mobile apps, intranets, SaaS, and most user-facing applications
A WAF configured with a negative security model focuses on identifying and blocking malicious traffic rather than defining all legitimate traffic. It operates on the assumption that requests fall along a risk spectrum, from very low risk to very high risk.
This model is best suited to applications that receive a broad and diverse range of requests (such as user-facing websites, games, or e-commerce platforms) where it is impractical to define every valid interaction in advance.
As a result, the negative security model is the most widely used approach and forms the foundation of the majority of WAFs.
Positive security model
Best for: APIs and microservices
A WAF configured with a positive security model takes the opposite approach: it is provided with a clear definition of expected behaviour and blocks anything that falls outside those boundaries.
This model is designed for APIs, microservices, machine-to-machine backends, internal services, and other applications with a limited, structured, and predictable set of requests, where valid behaviour can be clearly defined and tightly controlled.
Security teams supply the WAF with an API schema that defines expected paths, endpoints, HTTP methods, and data structures. Requests that do not conform to this definition are flagged or blocked automatically.
This approach is particularly effective at reducing API-specific risks such as IDOR and BOLA, and at preventing access to undocumented or unintended functionality.
Web Application and API Protection (WAAP)
As organisations increasingly rely on both user-facing applications and APIs, modern WAF platforms have evolved to support both negative and positive security models within a single solution.
While these platforms are still commonly referred to as WAFs, they are often described as Web Application and API Protection (WAAP) platforms, reflecting their broader scope and their ability to apply different security models to different types of workloads.
When does your business need a WAF?
All web applications require a WAF because automated probing, abuse, and opportunistic exploitation are always present, even within internal networks. As a result, most cloud platforms, Content Delivery Networks (CDNs), and application hosting environments include a WAF by default.
The practical consideration is how much WAF capability is required through its security model, placement and operation, not whether one should exist at all.
In any case, a WAF is required by all web applications because:
- HTTP(S) endpoints are continuously scanned and probed by automated tools as it’s cheap to do so
- Web applications expose business logic that cannot be protected by network firewalls alone, even Next-Generation Firewalls
- Vulnerabilities and misconfigurations are inevitable, even in well-engineered systems
- Patch and release timelines rarely align with vulnerability discovery or exploitation
Where WAFs are placed and why
WAFs can be placed at various points in the request path between the client (user or API call) and the application. Placement determines the level of traffic scale, context, and enforcement precision available to the WAF, and therefore its role within the overall protection architecture.
The primary WAF placements are outlined below.
CDN-based WAF (edge-of-the-internet defence)
Goal: Filter high-volume, low-confidence attacks before traffic reaches the origin infrastructure.
A CDN-based WAF is deployed within a Content Delivery Network (CDN), a globally distributed network of servers placed near population centres, to deliver web apps and services to end users with low latency.
At this placement, the WAF typically acts as the first line of defence, performing early traffic filtering with minimal application context. It operates broadly and is optimised to block generalised, automated attacks such as:
- Volumetric denial-of-service attempts
- Large-scale bot activity
- Credential stuffing
Edge-based defence reduces load and noise for downstream systems (including other WAFs), but provides limited application-specific policy control.
As a result, it is not well-suited to detecting low-volume attacks or abuse that depend on application or business logic, which are left to perimeter WAFs.
Content Delivery Network or platform providers such as Cloudflare and Akamai fully manage these WAFs and typically offer them as a service.
Cloud-hosted WAF (app perimeter defence)
Goal: Enforce application-aware and API-specific security controls at the application perimeter.
A cloud-hosted perimeter WAF is deployed as an inline reverse proxy or gateway in a cloud provider’s or security vendor’s environment (e.g., Microsoft Azure, Google Cloud, or dedicated WAF platforms). It sits closer to the application than a CDN- WAF and supports deeper inspection and more granular policy enforcement.
They provide the full spectrum of analysis capabilities and can enforce:
- URL and API-aware rules
- Parameter validation
- Session and authentication awareness
- Precise rate limiting and anomaly detection
These WAFs typically serve as the primary enforcement layer for cloud-hosted user-facing applications. They require routing integration with the protected application, typically using a VPN or private link such as MPLS or dark fibre.
Examples of cloud-hosted perimeter WAFs include Azure Web Application Firewall, Google Cloud Armor, Imperva Cloud WAF, and F5 Distributed Cloud WAF.
On-premises WAF (perimeter defence)
Goal: Enforce perimeter security controls for self-hosted, internal, or regulated applications.
An on-premises or private cloud WAF performs the same functional role as a cloud-hosted perimeter WAF, but is deployed within the organisation’s own infrastructure. It operates inside the private trust boundary and protects locally hosted applications and services.
Traffic is routed through the WAF using internal load balancers, routing rules, or service mesh controls. This placement allows inspection of both:
- North–south traffic (from users or the internet)
- East–west traffic (between internal services)
On-premises deployment supports strict data residency and cybersecurity compliance requirements, but places full responsibility for availability, scaling, and maintenance on the organisation, resulting in higher operational overhead.
These WAFs are sold as physical or virtual appliances by security vendors such as F5, Imperva, Fortinet, Barracuda or similar platforms.
Layered (“sandwich”) WAF architecture
Goal: Provide complete protection to a web application
A layered, or “WAF sandwich,” deployment uses multiple WAFs deployed inline at different locations (e.g., CDN, cloud perimeter, and on-premises), rather than relying on a single enforcement point.
This is a common deployment pattern for mature environments, with variation primarily in the number of layers required to protect a given application.
Rather than duplicating controls, the layered approach separates responsibilities by placement, allowing each WAF to operate within the context it is best suited for.
Deploying or modifying a WAF
Deploying or modifying a perimeter WAF is an iterative process. Rules and policies must be tested, tuned, and progressively enforced to improve security without degrading performance.
The goal is to reach acceptable benchmarks (false-positive rates, availability and error rates, latency impact, and attack coverage) without requiring frequent rollbacks or emergency overrides.
To reduce risk, teams typically follow a staged rollout sequence using established traffic-shifting strategies.
1. Parallel (out-of-band) deployment for testing
The first step in deploying a new WAF configuration, rule set, or vendor is to validate behaviour against real production traffic without enforcement.
In a parallel, or “out-of-band” deployment, traffic passing through the existing production path is mirrored to a secondary WAF. This WAF processes the exact same requests, but its decisions do not affect users or applications.
This creates a safe training environment where teams can:
- Observe what would have been blocked or allowed
- Tune rules using real traffic patterns
- Identify false positives on sensitive endpoints (e.g. authentication, APIs)
- Measure performance characteristics without user impact
Logs and metrics from the enforced and non-enforced paths are compared to assess rule accuracy and behavioural differences. Alerts are commonly used to surface unexpected blocking behaviour early.
This phase is primarily used for rule development, validation, and baseline performance analysis.
2. Limited rollout using canary deployment
Once a WAF configuration passes parallel testing, enforcement is introduced incrementally.
In a canary deployment, a limited subset of live traffic is routed through a WAF with enforcement enabled. Requests processed by the canary path are actively blocked, challenged, or rate-limited, while most traffic continues through the existing configuration.
The canary scope is typically defined by:
- A percentage of traffic (e.g., 1-5%)
- Specific endpoints or services (e.g., non-critical endpoints)
- Regions, tenants, or user segments
The enforcement scope is expanded gradually as confidence increases. Metrics such as false positives, latency impact, error rates, and user-facing failures are closely monitored. Rollout can be paused or reversed immediately if issues are detected.
This phase is specifically designed to surface partial or data-dependent failures that only appear once real users are affected.
3. Full rollout using blue-green deployment
Once enforcement has been validated through parallel testing and canary rollout, the final step is a full cutover.
In a blue-green deployment, all traffic is switched from the existing WAF configuration (the “blue” path) to the new, fully validated configuration (the “green” path). The switch is performed at the routing or load balancing layer rather than through gradual traffic weighting.
The previous configuration is retained temporarily to allow immediate rollback if required. Monitoring remains elevated during this phase to detect unexpected behaviour under full production load.
Blue–green deployments are typically short-lived, with the old path retained for days or weeks before decommissioning once stability is confirmed.
Operational elements of WAF
Due to the wide variety of web applications, regulatory environments, and team sizes, organisations adopt different models for operating and managing WAFs.
These models describe who is responsible for day-to-day WAF operation, including rule management, monitoring, tuning, and incident response, independent of where the WAF is deployed.
In practice, organisations typically fall into one of three operational models:
In-house operation
Best for: Organisations with mature security teams that require maximum control, deep application context, and strong compliance oversight.
In this model, the WAF is fully operated by internal security and platform teams. It is most commonly used where WAFs are deployed close to the application (cloud-perimeter or internal placements), enabling highly customised rules, protection of internal traffic, and tight integration with internal change and incident processes. Compliance, auditability, and data residency requirements are often key drivers.
Pros:
- Maximum control and flexibility
- Deep application and business logic awareness
- Strong compliance and audit alignment
Cons:
- High skills and staffing requirements
- Significant operational overhead
- Greater reliance on internal expertise
Third-party operated (fully-managed) WAF
Best for: SMEs and other organisations prioritising simplicity and reduced operational overhead over fine-grained control.
Here, WAF operations are outsourced to a cybersecurity provider, which manages configuration, tuning, and monitoring. This model is most commonly paired with edge (CDN) or cloud-hosted WAF placements, where standardised rule sets and managed services are effective. It suits organisations with limited in-house security capacity or relatively standard application profiles.
Pros:
- Minimal internal operational effort
- Access to specialist expertise and 24/7 monitoring
- Faster deployment and time to value
Cons:
- Reduced visibility and direct control
- Slower response to application-specific changes
- Less suitable for bespoke or rapidly changing systems
Hybrid operation
Best for: Organisations seeking a balance between control and operational efficiency.
In a hybrid model, baseline WAF operations are handled by a provider, while internal teams retain ownership of application-specific rules and risk decisions. This approach is commonly used in layered (“sandwich”) WAF deployments, where different teams or providers operate different layers. It allows organisations to scale security capabilities without fully internalising operational complexity.
Pros:
- Balanced control with reduced overhead
- Internal focus on high-value, application-specific decisions
- Flexible as security maturity evolves
Cons:
- Requires clear ownership and governance
- More coordination overhead than a single-owner model
- Risk of gaps if responsibilities are unclear
Common limitations of WAF
WAFs significantly reduce application risk, but they are not a foolproof defence against all application-layer attacks. Key limitations include:
A WAF cannot fix insecure application logic
WAFs operate outside the application and do not understand business intent. If an application allows users to abuse valid workflows, such as repeatedly transferring funds, enumerating resources they legitimately have access to, or exploiting logic flaws, a WAF may not be able to distinguish abuse from normal use.
This requires secure design practices, threat modelling, and code audits to ensure application logic is resilient to misuse.
A WAF cannot replace authentication and authorisation controls
If authentication, session management, or authorisation logic is poorly implemented, a WAF can only partially mitigate abuse using heuristics and anomaly detection. It cannot make authoritative identity or access-control decisions on behalf of the application.
This requires strong identity and access management, such as Single-Sign On and properly enforced authorisation checks.
A WAF cannot protect against compromised credentials
When attackers use valid usernames, passwords, API keys, or tokens, requests may appear legitimate at the application layer. While WAFs can reduce automated credential abuse (such as credential stuffing), they cannot prevent all misuse of stolen or leaked credentials.
This requires additional access controls such as Multi-Factor Authentication (MFA), credential hygiene, and account monitoring.
A WAF cannot fully protect APIs without application context
Modern attacks increasingly target APIs, which are often predictable, high-value, and tightly coupled to business logic.
While WAFs can validate request structure, schemas, and basic behaviour, they lack full application context (such as user entitlements, object ownership, business state, or how one API call relates to previous actions) and cannot always determine whether an API call is logically valid or abusive.
Effective API protection requires a combination of WAF controls, strong authentication, strict authorisation, and application-level validation.
A WAF cannot reliably detect low-and-slow or insider-style abuse
WAFs are less effective against attacks that deliberately stay within normal usage thresholds, such as slow enumeration, distributed scraping, or misuse by authenticated users over long periods. These patterns may not trigger rate limits or anomaly thresholds designed to avoid false positives.
Detecting this type of abuse typically requires longer-term behavioural analysis, application telemetry, and correlation with identity and business activity using a SIEM.
A WAF is not a complete denial-of-service mitigation solution
While WAFs can mitigate application-layer denial-of-service attacks (such as HTTP floods or expensive requests), they are not designed to absorb large-scale volumetric network attacks on their own.
Comprehensive DoS protection requires additional controls such as network-level DDoS mitigation, CDN capacity, traffic scrubbing services, and resilient application architecture.
A WAF must balance security with performance and usability
Because a WAF operates inline and must make decisions in milliseconds, it cannot perform exhaustive analysis on every request without degrading application performance or user experience.
As a result, WAF policies must balance depth of inspection with latency and availability, which can limit how aggressively traffic is filtered. This requires careful tuning, staged deployment, and ongoing monitoring to balance protection with performance.
How WAFs map to the MITRE ATT&CK framework
MITRE ATT&CK is a widely used framework that describes how attackers progress through real-world cyberattacks, from initial access through data exfiltration or credential theft. Security teams commonly use it to understand where defensive controls can interrupt an attack.
While a WAF does not stop every stage of an attack, it is particularly effective at disrupting the tactics that use HTTPS traffic to exploit web applications and APIs. At a high level, WAFs commonly contribute to the following ATT&CK tactics:
Reconnaissance
WAFs can limit attackers’ ability to probe and map applications by detecting and blocking automated scanning, endpoint enumeration, and abnormal request patterns used to discover exposed functionality or vulnerabilities.
Initial access
WAFs help prevent attackers from gaining an initial foothold by blocking attacks on public-facing applications, such as SQL injection, cross-site scripting, insecure deserialisation, and API abuse.
Execution
By filtering malicious payloads and exploit techniques, WAFs can prevent attackers from triggering unintended command or script execution through vulnerable application components.
Persistence
WAFs do not stop persistence mechanisms directly, but they can disrupt attempts to establish persistence through the application layer. Examples include, abusing administrative endpoints, injecting malicious payloads, or repeatedly exploiting vulnerable workflows to regain access.
Credential access
WAFs reduce large-scale credential abuse by detecting and limiting brute-force attempts, credential stuffing, and other automated login attacks at the application layer.
Command and control
WAFs can interfere with command-and-control activity that relies on web protocols by detecting suspicious request patterns, scripted callbacks, or abnormal client behaviour indicative of remote control via HTTP(S).
Exfiltration
WAFs can detect and disrupt anomalous request patterns associated with data extraction, such as scripted scraping, repeated resource enumeration, or unusually high-volume data retrieval.
Impact (application abuse)
WAFs help reduce the impact of attacks that aim to disrupt services or misuse application functionality, including application-layer denial-of-service attacks, large-scale automation abuse, and resource exhaustion.
Back to blog
