WAFWikiIndependent WAF intelligence
中文

WAFWiki index

Search WAFWiki

Type at least 2 characters to search the full research library.

Original WAFWiki labs

WAF Docker tests, screenshots, and workflow diagrams

Reproduce version-pinned ModSecurity and Coraza tests, inspect HTTP 200/403 results, and separate observed evidence from methodology.

Coraza Caddy Docker test evidence showing pinned component versions, image digest, six clean HTTP 200 results, four HTTP 403 results, and CRS rule IDs.
The fixed Coraza stack matched all ten expected outcomes in this localhost run: six clean requests returned 200 and four controlled SQLi/XSS requests returned 403.

    Completed hands-on test

    Coraza Caddy Docker Test: CRS 4.25.0 Results

    Hands-on Coraza and Caddy Docker test with pinned versions, OWASP CRS 4.25.0, ten clean and attack-like requests, HTTP results, logs, and build constraints.

    Open lab note
    Twenty-request result matrix showing matching ModSecurity and Coraza HTTP 200 and 403 outcomes for clean, SQLi, XSS, query, and JSON cases.
    Both fixed stacks matched all 20 expected decisions. This is evidence of behavior on the selected matrix, not a universal accuracy ranking.

      Completed hands-on test

      ModSecurity vs Coraza Docker Test: 20 Request Results

      Original ModSecurity vs Coraza Docker comparison using the same OWASP CRS 4.25.0, upstream, and 20 HTTP decisions across clean, SQLi, XSS, query, and JSON cases.

      Open lab note
      JSON body test evidence showing a clean JSON HTTP 200 result, SQLi-like and XSS-like HTTP 403 results, and OWASP CRS rule IDs.
      Across both stacks, the clean JSON body was allowed twice while the SQLi-like and XSS-like JSON fields were blocked four times.

        Completed hands-on test

        WAF JSON Body Test: ModSecurity vs Coraza

        Hands-on JSON request-body test showing how ModSecurity and Coraza handled one clean body plus controlled SQLi-like and XSS-like fields under OWASP CRS 4.25.0.

        Open lab note
        OWASP CRS clean traffic regression showing six clean inputs allowed by both WAF stacks and a numeric Host header warning from rule 920350.
        All 12 clean decisions returned 200, but the localhost numeric Host header still generated a repeatable CRS 920350 warning in both logs.

          Completed hands-on test

          OWASP CRS False Positive Test: 12 Clean Requests

          Clean-traffic regression test for ModSecurity and Coraza with 12 HTTP 200 decisions, six input patterns, zero blocking mismatches, and one repeatable numeric Host warning.

          Open lab note
          Local Docker response-time chart showing direct upstream, ModSecurity NGINX, and Coraza Caddy median and p95 results plus memory snapshots.
          The final run used 40 sequential localhost requests per path. The values are a reproducible micro-baseline, not a throughput or production capacity benchmark.

            Completed hands-on test

            Docker WAF Latency Test: ModSecurity vs Coraza

            Local Docker response-time baseline with 40 sequential requests per path for a direct upstream, ModSecurity NGINX, and Coraza Caddy, plus memory snapshots and limits.

            Open lab note
            Self-hosted WAF lab workflow with developer workstation, test domain, WAF node, upstream application, logs, latency evidence, and rollback path.
            The lab routes a controlled request path through OWASP CRS and ModSecurity before it reaches a simple upstream application.
            • Developer workstation
            • Lab hostname
            • OWASP CRS + ModSecurity
            • NGINX reverse proxy
            • Upstream demo app
            • Evidence: HTTP status, rules, latency
            • Rollback route

            Completed smoke test

            ModSecurity CRS Docker Smoke Test

            A reproducible local smoke test for OWASP CRS with ModSecurity and NGINX, covering clean traffic, a SQLi-like lab request, evidence logs, and rollout caveats.

            Open lab note
            Generic reverse proxy WAF flow showing clients, WAF inspection, allow and block decisions, upstream application, logs, and response path.
            A reverse proxy WAF sits before the upstream application, evaluates requests, forwards allowed traffic, and records blocked or suspicious traffic for review.
            • Client traffic
            • Network entry point
            • WAF inspection layer
            • Policy decision
            • Allowed request to origin
            • Blocked request evidence

            Methodology

            Generic Reverse Proxy WAF Workflow

            A vendor-neutral WAF workflow diagram explaining client traffic, inspection, decision logic, allowed upstream traffic, blocked requests, and evidence capture.

            Open lab note
            Comparison diagram showing self-hosted WAF near the origin and managed edge WAF in a global edge network before cloud services.
            The two models differ less by the word WAF and more by who controls routing, policy, upgrades, logging, and emergency rollback.
            • Self-hosted WAF
            • Origin-side control
            • Managed edge WAF
            • Global edge network
            • Decision criteria
            • Cost, logs, latency, rollback

            Methodology

            Self-Hosted vs Managed WAF Workflow

            A visual comparison of self-hosted WAF ownership versus managed cloud or edge WAF ownership, focused on traffic path, operations, logging, and rollback.

            Open lab note