Firewall and WAF Fundamentals for Web Applications

1. Network Firewall vs. Web Application Firewall: Comparing the Scope of Protection

A classic network firewall operates at OSI layer 3 and 4 and makes its decisions purely based on IP address, port, and protocol. An iptables or ufw rule set typically allows inbound traffic on port 443 and 80, blocks everything else, and rate-limits SSH access. This filtering is stateful, meaning it tracks connection state (NEW, ESTABLISHED, RELATED) and only lets response packets through for existing connections. For defending against port scans, unauthorized services, and network floods, this is the correct and necessary first line of defense.

A network firewall, however, has no visibility into what actually travels inside an allowed HTTPS connection. A POST request carrying a SQL injection in a request parameter sails through port 443 just as easily as a legitimate login. This is exactly where a Web Application Firewall (WAF) comes in: it operates at OSI layer 7, terminates or inspects the HTTP request, and evaluates the method, headers, query string, and body based on content. A WAF runs either as a web server module (ModSecurity), as a reverse proxy in front of the application, or as an edge service at the CDN provider. Network firewall and WAF complement each other, they don't replace each other.

#!/bin/bash
# Basic network firewall rules: allow HTTP/HTTPS, deny everything else,
# rate-limit SSH to slow down brute-force attempts

# Using ufw (Uncomplicated Firewall)
ufw default deny incoming
ufw default allow outgoing

# Allow web traffic
ufw allow 80/tcp
ufw allow 443/tcp

# Rate-limit SSH: max 6 connection attempts within 30 seconds per IP
ufw limit 22/tcp

ufw enable

# Equivalent raw iptables rules for the same policy
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# SSH rate limiting: allow max 4 new connections per minute per source IP
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

2. Signature-Based vs. Anomaly-Based Detection in WAF Rules

WAF rules broadly fall into two detection strategies. Signature-based rules compare incoming requests against known attack patterns, such as typical SQL injection syntax like UNION SELECT or cross-site scripting payloads like <script> tags in form fields. The OWASP Core Rule Set (CRS) is the best-known signature-based rule set and covers the OWASP Top 10 with several hundred predefined rules. Signature-based detection is precise against known patterns but fails against novel or cleverly obfuscated attacks that don't match any known signature.

Anomaly-based, or behavior-based, detection takes a different approach: it learns a baseline profile of normal traffic, such as typical parameter lengths, character sets, or request frequencies, and raises an alert on deviations. This also catches unknown attack variants, but tends to produce more false positives, since legitimate but unusual user input can trigger the same anomaly flag. Modern WAFs like AWS WAF or Cloudflare combine both approaches: signature-based rules for known patterns plus an anomaly-scoring system that adds up several smaller suspicious signals into an overall score before a request is actually blocked.

3. False Positive Management and Rule Tuning in Production

Every newly enabled WAF rule, in practice, initially blocks legitimate traffic too, for example when a customer types a character like an apostrophe or a -- into a free-text field that happens to resemble a SQLi pattern. A professional rollout process therefore never goes straight to blocking: new rules first run in detection-only or log mode, and every hit gets collected and reviewed for days to weeks before switching to block mode. Skip that phase, and you risk blocking a Magento store's checkout for real customers because an address with special characters gets misclassified as an attack.

During actual tuning, the rule is to scope exceptions as narrowly as possible: instead of globally disabling an entire rule ID, the exception is limited to a specific URL, a specific parameter, or a specific combination of both. ModSecurity provides SecRuleRemoveTargetById for this, which lets you exempt individual parameters from a rule without disabling the rule entirely. Every exception should be documented and given an expiration date, since forms and application logic change over time, and a forgotten exception can quietly turn into a security hole years later.

4. WAF as Defense in Depth: No Substitute for Fixing the Code

A WAF is a compensating control, not a substitute for secure application development. If a SQL injection vulnerability in the code gets blocked by a WAF rule, the underlying vulnerability still exists: a bypass of the rule, a new attack vector through a different parameter, or a misconfiguration of the WAF itself reopens the hole immediately. The only durable fix remains prepared statements instead of string concatenation in SQL queries, and consistent output encoding against XSS, regardless of whether a WAF sits in front of the application or not.

In practice, a WAF mainly buys time: between a vulnerability becoming known and a patch getting rolled out, there are often days to weeks during which a targeted virtual-patch rule in the WAF closes the exploitation window. That rule should then be consistently removed once the actual code fix is live, otherwise stale, unmaintainable exceptions accumulate over the years. The PHP example below shows clean server-side validation and escaping that must hold regardless of whether a WAF is present.

<?php

declare(strict_types=1);

namespace Mironsoft\Security\ViewModel;

use Magento\Framework\Escaper;
use Magento\Framework\View\Element\Block\ArgumentInterface;
use InvalidArgumentException;

/**
 * View model that validates and escapes free-text customer input server-side.
 *
 * A WAF may block obvious SQL injection or XSS payloads at the edge, but the
 * application must never rely on that as its only line of defense. This
 * class enforces strict input validation and output escaping regardless of
 * whether a WAF is present in front of the store.
 */
final class CommentInputViewModel implements ArgumentInterface
{
    private const int MAX_COMMENT_LENGTH = 500;

    /**
     * @param Escaper $escaper Magento's HTML escaper used for safe output rendering.
     */
    public function __construct(
        private readonly Escaper $escaper,
    ) {
    }

    /**
     * Validates a raw comment string and returns it escaped for safe HTML output.
     *
     * @param string $rawComment Unvalidated input, e.g. from a product review form.
     * @return string The validated and HTML-escaped comment.
     * @throws InvalidArgumentException If the input fails length or character validation.
     */
    public function sanitizeComment(string $rawComment): string
    {
        $trimmed = trim($rawComment);

        if ($trimmed === '' || mb_strlen($trimmed) > self::MAX_COMMENT_LENGTH) {
            throw new InvalidArgumentException('Comment length is invalid.');
        }

        // Reject control characters and null bytes regardless of WAF filtering upstream
        if (preg_match('/[\x00-\x08\x0B\x0C\x0E-\x1F]/', $trimmed) === 1) {
            throw new InvalidArgumentException('Comment contains invalid control characters.');
        }

        // Escape for HTML output; never trust that upstream WAF layers already did this
        return $this->escaper->escapeHtml($trimmed);
    }
}

5. ModSecurity and the OWASP Core Rule Set: Configuration Basics

ModSecurity is the most widely used open-source WAF engine for Apache, nginx, and IIS, and is usually run together with the OWASP Core Rule Set. After installation, the core configuration defines the detection mode (SecRuleEngine DetectionOnly for the testing phase, later On for active blocking), the maximum request body size, and the CRS's anomaly-scoring model. Every CRS rule adds points to an anomaly-scoring tally on a hit; only once a request's total score crosses a configured threshold does it actually get blocked, instead of reacting immediately to every single hit.

This threshold logic noticeably reduces false positives, because a single harmless anomaly rarely suffices to block the request, while a combination of several suspicious signals crosses the threshold. The CRS's paranoia levels (1 through 4) additionally control how aggressively the rules trigger: level 1 is production-ready with few false positives, level 4 maximizes detection at the cost of considerably more manual tuning. For most Magento stores, paranoia level 1 with targeted exceptions for known admin workflows is the practical starting point.

# ModSecurity + OWASP CRS: example rule blocking a SQL injection pattern
# via anomaly scoring instead of an immediate hard block

# Detection-only mode during the initial tuning phase (log but don't block)
SecRuleEngine DetectionOnly

# Custom rule: flag a classic UNION-based SQLi pattern in any request argument
SecRule ARGS "@rx (?i:union\s+select|sleep\(\d+\)|benchmark\()" \
    "id:100001,\
    phase:2,\
    deny,\
    log,\
    msg:'Possible SQL Injection pattern detected',\
    severity:'CRITICAL',\
    tag:'attack-sqli',\
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.anomaly_score=+%{tx.critical_anomaly_score}'"

# Block only once the cumulative anomaly score crosses the threshold,
# not on every single rule hit
SecAction "id:100002,phase:1,pass,nolog,setvar:tx.inbound_anomaly_score_threshold=5"

SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
    "id:100003,\
    phase:5,\
    deny,\
    status:403,\
    msg:'Inbound anomaly score exceeded threshold'"

6. Configuring Cloud and Edge WAFs: Cloudflare, AWS WAF, and Rate Limiting

Cloud and edge WAFs like Cloudflare or AWS WAF move filtering in front of the actual infrastructure, usually as part of a CDN, so malicious traffic never even reaches the origin server. Configuration today is done predominantly as infrastructure as code, for example via Terraform or CloudFormation, with managed rule groups for known attack classes (SQLi, XSS, known CVEs) plus custom rules for application-specific patterns. These rule groups can be tuned differently per route or path, for example stricter for checkout than for static assets.

Rate-based rules are a core building block of cloud WAFs and add a frequency dimension on top of classic signature detection: if an IP address exceeds a defined number of requests against a sensitive endpoint like login within a time window, a block or a CAPTCHA challenge kicks in automatically, regardless of whether the individual requests look content-wise unremarkable. This is the most effective defense against credential stuffing and brute-force attempts, which send large volumes of login requests that look entirely legitimate on their own and would therefore go undetected by pure signature detection.

# AWS WAFv2 Web ACL: managed rule groups plus a custom rate-based rule
Resources:
  ShopWebAcl:
    Type: AWS::WAFv2::WebACL
    Properties:
      Name: magento-shop-waf
      Scope: CLOUDFRONT
      DefaultAction:
        Allow: {}
      VisibilityConfig:
        SampledRequestsEnabled: true
        CloudWatchMetricsEnabled: true
        MetricName: magento-shop-waf
      Rules:
        - Name: AWS-AWSManagedRulesSQLiRuleSet
          Priority: 0
          OverrideAction:
            None: {}
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesSQLiRuleSet
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: sqli-managed-rules

        - Name: AWS-AWSManagedRulesCommonRuleSet
          Priority: 1
          OverrideAction:
            None: {}
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesCommonRuleSet
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: common-managed-rules

        - Name: login-rate-limit
          Priority: 2
          Action:
            Block: {}
          Statement:
            RateBasedStatement:
              Limit: 300
              AggregateKeyType: IP
              ScopeDownStatement:
                ByteMatchStatement:
                  SearchString: /customer/account/loginPost
                  FieldToMatch:
                    UriPath: {}
                  TextTransformations:
                    - Priority: 0
                      Type: LOWERCASE
                  PositionalConstraint: STARTS_WITH
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: login-rate-limit

7. WAF Bypass Techniques and the Limits of Protection

WAF bypass techniques typically exploit differences between how the WAF and the target application interpret a request, for example through alternative encodings (double URL encoding, Unicode normalization), case variation within SQL keywords, or splitting an attack string across multiple HTTP parameters that the application reassembles server-side. HTTP parameter pollution, sending the same parameter name multiple times with different values, is exploited too, since the WAF and the application sometimes evaluate these cases differently.

These techniques are not a reason to skip a WAF, they're the central proof of why a WAF must never be the only protective layer. An up-to-date, regularly patched CRS rule set, combined with strict anomaly scoring and a cleanly implemented application that holds up even after a successful bypass thanks to prepared statements and output encoding, keeps real risk to a minimum. Security teams should test WAF bypasses regularly as part of penetration testing, rather than relying solely on vendor claims about the WAF.

8. Logging and Alerting for WAF Events

Every blocked request, and every request flagged in detection mode, should be logged in a structured way, including the rule ID, anomaly score, affected parameter, and the pattern actually matched. Without this level of detail, neither false-positive triage nor forensic analysis of a real attack is practical. ModSecurity writes this information to the audit log by default, which can be exported as structured JSON and fed into a central SIEM or log management system such as the ELK stack or Grafana Loki.

For day-to-day operations, alerts on unusual patterns matter more than alerts on every single hit: a sudden spike in blocked requests from a single IP range, a new rule ID with an unusually high hit rate after a deployment, or a rising anomaly score on a previously quiet endpoint are the signals a security team actually needs. Raw request-by-request logging without aggregation and threshold-based alerts reliably leads to alert fatigue in practice, and real incidents get lost in the noise.

{
  "timestamp": "2026-07-11T14:32:07Z",
  "clientIp": "203.0.113.45",
  "action": "BLOCK",
  "ruleId": "941100",
  "ruleGroup": "OWASP-CRS-941-APPLICATION-ATTACK-XSS",
  "matchedPattern": "<script>alert(1)</script>",
  "matchedField": "ARGS:comment",
  "anomalyScore": 8,
  "anomalyThreshold": 5,
  "requestUri": "/catalog/product/reviewPost",
  "httpMethod": "POST",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
  "triageStatus": "pending_review",
  "triageNote": "Legitimate customer submitted a product review containing HTML-like text in a code snippet. Confirmed false positive, added scoped exception for ARGS:comment on this URI only."
}

9. Network Firewall, WAF, and Code Fix Compared

A network firewall, a WAF, and an actual code fix operate at different levels and close different gaps. The table below shows which threat each protective layer actually covers, and where each layer hits its limits.

In practice, all three layers overlap only partially: a firewall protects the infrastructure, a WAF protects the request layer, and only a code fix permanently closes the actual vulnerability. Combining all three layers instead of relying on a single one gets you the highest realistic level of protection.

10. Summary

Firewall and WAF fundamentals solve different problems: a network firewall protects against unauthorized network access at OSI layer 3/4, while a Web Application Firewall evaluates the content of HTTP requests at layer 7 and detects application-specific attacks such as SQL injection or cross-site scripting. Signature-based rules like the OWASP Core Rule Set reliably cover known attack patterns, while anomaly-based detection additionally catches unknown variants, at the cost of more tuning effort against false positives.

The most important principle remains: a WAF is defense in depth, not a repair of the underlying vulnerability. Prepared statements, output encoding, and clean server-side validation stay mandatory, no matter how well the WAF is configured. Combining a network firewall, a WAF rule set with clean false-positive tuning, structured logging, and secure application development achieves a level of security that no single layer could deliver on its own.

11. FAQ: Firewall and WAF Fundamentals