In web application security, detecting attacks as early as possible is critical.
Every millisecond that a malicious request travels through an infrastructure increases backend exposure and consumes unnecessary resources.
Web Application Firewalls (WAFs) based on the OWASP Core Rule Set (CRS) have become one of the most widely used mechanisms to protect applications against attacks such as:
- SQL Injection
- Command Injection
- Path Traversal
- Remote Code Execution
- Cross-Site Scripting (XSS)
However, when these rules are integrated into modern high-performance reverse proxies, a limitation appears due to the historical processing model inherited from ModSecurity.
In this article we will analyze:
- how the OWASP CRS inspection pipeline works
- what issue appears in modern reverse proxies
- how applying the fail fast principle can improve security
We will also explain how SKUDONET has implemented this approach to stop attacks as early as possible in the WAF data path.
In perimeter security, stopping an attack one step earlier in the data flow can make a critical difference.
Why OWASP CRS Remains the Standard for WAF Protection
The OWASP Core Rule Set (CRS) is one of the most widely used rule sets for Web Application Firewalls.
It is built on ModSecurity and provides predefined rules designed to detect patterns associated with common vulnerabilities, particularly those included in the OWASP Top 10.
Among the threats it can detect are:
- SQL injection
- Cross-site scripting
- Remote command execution
- Path traversal
- protocol anomalies
- malicious bots
The goal of OWASP CRS is to analyze every HTTP request before it reaches the backend, blocking malicious patterns through an anomaly scoring system.
This model has proven effective for years, but it was designed at a time when most proxies did not operate in high-performance streaming mode.
How the OWASP CRS Inspection Pipeline Works
The ModSecurity Phase Model
OWASP CRS follows the ModSecurity inspection model, which divides the analysis of an HTTP request into several phases.
Simplified pipeline:
Each phase analyzes a different part of the traffic.
Phase 1
Analyzes information available immediately:
- HTTP headers
- URI
- query string
- request metadata
Phase 2
Analyzes the full content of the request:
- request body
- POST parameters
- JSON
- XML
- complex payloads
This approach works well for deep inspection, but it introduces an important consequence.
A Subtle Issue in OWASP CRS
Within OWASP CRS there are rules that analyze variables available from the very beginning of the request, such as:
- ARGS_GET
- REQUEST_URI
- QUERY_STRING
However, many of these rules are executed in Phase 2.
This means that a request such as:
GET /login.php?user=admin’ OR ‘1’=’1 HTTP/1.1
Host: example.com
contains a SQL injection clearly visible in the URL, yet it may not be evaluated until Phase 2.
From a security perspective, this raises an obvious question:
If the attack is already detectable in Phase 1, why wait until Phase 2 to block it?
The Security Principle: Fail Fast
In system architecture there is a fundamental principle:
Fail Fast
A system should detect invalid conditions as early as possible in the execution flow.
Applied to a WAF, this means:
An attack should be stopped as soon as it becomes detectable.
Not later.
How Modern High-Performance Reverse Proxies Work
Modern reverse proxies are designed to reduce:
- latency
- memory consumption
- buffering
To achieve this, many proxies operate in streaming mode.
An efficient proxy may process a request in the following way:
- Receive HTTP headers
- Analyze them
- Immediately forward them to the backend
- Later receive the request body
- Analyze and forward it
Simplified flow:
But when combined with OWASP CRS, a problem appears.
The Conflict Between High-Performance Proxies and OWASP CRS
If the proxy operates in streaming mode while OWASP CRS follows its traditional model:
- WAF Phase 1 executes (but the full evaluation is completed in Phase 2)
- Headers are forwarded to the backend
- The request body arrives later
- WAF Phase 2 executes, (completing the evaluation started in Phase 1).
- The body is forwarded to the backend
This means the backend may receive part of the request before the WAF has made the final decision.
From a security perspective, this is suboptimal.
Architecture Comparison: Traditional Pipeline vs Fail Fast
High-Performance Proxy with Traditional CRS
Result:
- the backend has already received traffic
- part of the attack has already progressed through the infrastructure
Fail Fast Pipeline
In this model, the attack is stopped at the earliest possible point in the data path.
Applying the SKUDONET Fail Fast Approach to the WAF
To address this problem, SKUDONET implemented an approach based on the fail fast principle.
The idea is simple:
If an attack can be detected in Phase 1, it should be evaluated in Phase 1.
This requires partially reorganizing the logic of OWASP CRS rules.
Technical Example: CRS Rules That Can Be Evaluated Earlier
A simplified CRS rule example might look like this:
SecRule ARGS_GET “@detectSQLi” \
“id:942100,\
phase:2,\
block,\
msg:’SQL Injection Attack Detected'”
Here we see the key issue:
phase:2
Even if the attack pattern appears in the URL, the rule may execute later.
Conceptually, an early detection could be evaluated like this:
SecRule REQUEST_URI “@detectSQLi” \
“id:942100,\
phase:1,\
block”
This allows attacks to be detected before the traffic progresses through the processing pipeline.
Want to see how this works in practice?
Early Evaluation (Phase 1)
At this stage the WAF analyzes elements available from the start of the request:
- headers
- URL
- query string
Examples of early detection include:
- SQL injection in the URL
- command injection
- path traversal
- header anomalies
Simplified flow:
If the attack is detected here, the request never reaches the backend.
Deep Evaluation (Phase 2)
When the body arrives, the second inspection phase runs:
This phase enables the detection of more complex attack patterns.
Conclusion
OWASP CRS remains one of the most important tools for protecting web applications.
However, when deployed in modern high-performance architectures, the traditional phase model may introduce certain limitations, particularly in environments where reverse proxies operate in streaming mode.
The fail fast principle offers a clear solution:
detect attacks as early as possible in the processing flow and block them before they progress through the infrastructure.
This approach allows organizations to:
- identify threats in early stages of the request
- reduce backend exposure
- improve the overall efficiency of the security system
In modern infrastructures, every millisecond matters.
And in perimeter security, stopping an attack one step earlier can make all the difference.
Platforms like SKUDONET apply this fail fast approach directly within the reverse proxy pipeline, allowing attacks to be stopped as early as possible in the WAF data path.
FAQ
What is fail fast in cybersecurity?
Fail fast is a design principle where systems detect invalid or malicious conditions as early as possible. In WAF architectures, this means identifying and blocking malicious requests at the earliest stage of the inspection pipeline.
What is OWASP CRS?
OWASP Core Rule Set (CRS) is a collection of security rules used by Web Application Firewalls to detect common web attacks such as SQL injection, cross-site scripting (XSS), and command injection.
Why can OWASP CRS delay attack detection?
Some OWASP CRS rules analyze request parameters during Phase 2 of the ModSecurity inspection model, even when malicious patterns may already be visible earlier in the request lifecycle.
Why is the fail fast principle important for reverse proxies?
High-performance reverse proxies often forward HTTP headers to the backend before the full request body is received. Detecting attacks early prevents malicious requests from reaching backend services and reduces unnecessary resource consumption.
What role does a WAF play in an ADC?
In modern Application Delivery Controllers (ADC), the Web Application Firewall is integrated directly into the Layer-7 proxy pipeline, allowing malicious traffic to be inspected and blocked before it reaches application servers.
See Fail Fast WAF Protection in Action
If you want to see how the fail fast approach works in a real reverse proxy environment, you can test the SKUDONET platform.
