An HTTPS request can pass every network-level check and still contain something your application should never process.

SQL injection, malicious JavaScript, malformed HTTP data or a dangerous file upload can all travel inside what appears to be a perfectly valid connection.

This is exactly where a Web Application Firewall comes into play.

The interesting part is not simply that it can block malicious traffic. What really matters is what happens between the moment a request reaches the infrastructure and the moment it is either rejected or forwarded to the application.

Let’s follow that request step by step.

The HTTP/S request journey through a Web Application Firewall

In our architecture, traffic follows a clear path:

Client → reputation and DoS/DDoS checks → TLS termination → WAF inspection → load balancer → backend

The Web Application Firewall operates before backend selection, so malicious requests can be stopped before the application has to process them. The response can also be inspected on its way back to the client.

That gives security teams a useful point of control inside the application delivery path, rather than leaving inspection to the application itself.

Step 1: Filter obvious threats before deep inspection

Not every connection needs the same level of analysis.

Before a request reaches deep application inspection, traffic can already be checked against reputation data, blocklists and abnormal connection behavior.

Our IPDS stack includes reputation-based filtering, real-time RBL checks and DoS/DDoS protection before the WAF stage.

This allows clearly suspicious traffic to be discarded earlier, while the WAF focuses on requests that require deeper analysis at application level.

Step 2: TLS termination makes HTTPS traffic inspectable

Most business applications today use HTTPS, which means the HTTP request is encrypted while it travels over the network.

A Web Application Firewall cannot inspect application content it cannot see.

That is why TLS termination happens before WAF inspection. In our architecture, HTTPS is decrypted inside the ADC and the HTTP request is then passed to the WAF engine for analysis.

This is what makes it possible to inspect the actual content of an encrypted request rather than just the connection around it.

Step 3: Inspecting the actual HTTP request

Once the request is visible, the Web Application Firewall can inspect much more than the URL.

The inspection can include:

  • URI and parameters
  • HTTP headers
  • request body
  • multipart forms
  • JSON
  • XML
  • file uploads

Each request also receives a unique transaction ID, which helps trace it across hostnames, services and backends.

This becomes especially useful in environments where the same infrastructure protects several applications, APIs or microservices.

Step 4: Rules decide what should be blocked

Inspection only becomes useful when the WAF has a clear way to evaluate what it sees.

Our WAF uses ModSecurity as the inspection engine and applies OWASP Core Rule Set v4.3.0, together with additional SKUDONET rules and threat intelligence.

These rules can detect patterns associated with attacks such as:

  • SQL injection
  • Cross-Site Scripting
  • Local and Remote File Inclusion
  • Remote Code Execution
  • command injection
  • malformed HTTP requests
  • protocol violations
  • scanners and bots
  • session manipulation
  • HTTP DoS patterns

The decision is made on the content and behavior of the request, not simply on where it came from.

Custom rules matter in production

Predefined rules are useful, but real applications rarely behave in exactly the same way.

A public API, an ERP and a customer portal may all need different security policies, even if they share the same infrastructure.

That is why administrators can inspect and modify existing WAF rules and also create their own. Custom rules can be applied at farm, service and VirtualHost level, while exclusions can be used when legitimate traffic requires a more specific policy.

The platform is also compatible with the ModSecurity rule language, giving technical teams a way to define more granular detection and blocking logic when needed.

Step 5: What happens when the WAF detects an attack?

Take a simple SQL injection attempt.

The connection itself may look completely normal. HTTPS works, the HTTP request is valid and the client is reaching an allowed endpoint.

The problem is inside the request.

Once the WAF inspects the relevant parameter or request body, a rule may identify a malicious pattern. If the request is considered unsafe, it is blocked before the backend processes it.

That is the key difference between network-level filtering and application-level inspection: the connection may be valid, while the content is not.

Our WAF is designed to detect attack categories including SQL injection, XSS, LFI/RFI, RCE, command injection and several HTTP anomalies.

Step 6: Legitimate traffic continues to the backend

If the request passes inspection, it continues to the load balancer, which selects the appropriate backend.

At that point, security and application delivery are part of the same request path.

The same infrastructure can handle:

  • TLS termination
  • WAF inspection
  • traffic distribution
  • backend selection
  • availability

Response inspection: protection does not end with the request

The client request is only half of the HTTP transaction.

Our WAF uses a four-phase inspection model:

  • Phase 1: request headers
  • Phase 2: request body
  • Phase 3: response headers
  • Phase 4: response body

This means the response from the backend can also be inspected before it is returned to the client.

For troubleshooting and security analysis, that provides a more complete picture of the transaction instead of looking only at inbound traffic.

False positives: when legitimate traffic triggers a rule

A Web Application Firewall has to block malicious traffic without constantly breaking legitimate requests.

That sounds obvious, but it is one of the main operational challenges of running a WAF in production.

A legitimate request can occasionally match a security rule because of an unusual parameter, payload or application behavior.

When that happens, the useful question is not simply “which rule blocked it?”, but also “why did it match?”

Our WAF logs include details such as:

  • triggered rule
  • matched variable
  • payload
  • severity
  • client IP
  • hostname
  • backend
  • anomaly score
  • transaction ID

Administrators can then adapt a rule or create an exclusion without weakening the entire policy.

Different applications need different WAF policies

Applying the same security policy to every service is rarely ideal.

Production, staging and QA may have different needs. An internal service may behave very differently from a public API. A legacy application may require exceptions that would make no sense elsewhere.

Our platform allows different farms, services and domains to use their own rule sets, blocklists and security policies within the same ADC instance.

That gives teams more flexibility to adapt protection to the application rather than forcing every application into the same security model.

Can WAF policies be automated?

In larger environments, manual security changes quickly become difficult to maintain.

Our REST API can be used to automate deployments, update rules from CI/CD pipelines, integrate security with external systems and react to backend events by creating dynamic rules.

For DevOps and platform teams, this makes WAF policy management easier to integrate into the same workflows already used for application delivery and infrastructure changes.

Does Web Application Firewall inspection affect performance?

Deep inspection is not free.

A Web Application Firewall may need to terminate TLS, parse HTTP, inspect headers and bodies, evaluate rules and, in some cases, inspect the response as well.

The impact depends on factors such as:

  • traffic volume
  • TLS workload
  • request and response size
  • number and complexity of rules
  • JSON/XML processing
  • file uploads
  • available CPU and memory

This is why WAF performance should be evaluated in the context of the actual application rather than only through generic throughput numbers.

How we integrate Web Application Firewall protection into application delivery

Our Web Application Firewall is built directly into the ADC rather than deployed as a separate security layer.

It works together with:

  • TLS termination
  • Layer 7 reverse proxying
  • reputation filtering
  • DoS/DDoS protection
  • load balancing
  • high availability
  • logging and profiling
  • REST API automation

The WAF uses ModSecurity and OWASP CRS v4.3.0, while administrators retain control over custom rules, exclusions and application-specific policies.

It can be deployed as an edge ADC, an on-premise reverse proxy or as part of a hybrid architecture protecting public applications, internal services, APIs, microservices and cloud workloads.

For teams managing critical applications, the advantage is not simply having another security feature.

It is being able to manage security, availability and traffic delivery within the same application path, with visibility into what is being blocked, why it is being blocked and where legitimate traffic is being sent.

FAQ

What is a Web Application Firewall?

A Web Application Firewall is a security layer that inspects HTTP and HTTPS traffic to detect and block malicious application-layer requests before they reach a web application. Unlike a traditional network firewall, it analyzes the content of web traffic rather than relying mainly on IP addresses, ports and network protocols.

How does a Web Application Firewall work?

A Web Application Firewall sits in the application traffic path and evaluates HTTP/S requests against security rules. It can inspect headers, parameters and request bodies, detect malicious patterns and either block the request or allow it to continue towards the backend.

Does a Web Application Firewall inspect HTTPS traffic?

Yes, provided the encrypted traffic is decrypted before application-layer inspection. In our architecture, TLS is terminated inside the ADC before the request reaches the WAF.

Can a Web Application Firewall inspect responses?

Yes. Our WAF inspects both request and response traffic through four phases covering request headers, request bodies, response headers and response bodies.

Can Web Application Firewall rules be customized?

The level of customization depends on the platform. In our case, administrators can inspect and modify existing rules, create custom rules and define exclusions at farm, service and VirtualHost level.

What attacks can a Web Application Firewall block?

Depending on its rules and configuration, a Web Application Firewall can detect attacks such as SQL injection, Cross-Site Scripting, Local and Remote File Inclusion, Remote Code Execution, command injection and malformed HTTP requests. Our WAF also includes detection for scanners, bots and several HTTP DoS patterns.