Quick answer

How to use this Coraza Caddy Docker Setup and CRS Validation Guide

Start by proving that the chosen Coraza and Caddy integration path loads the intended CRS rules, preserves upstream behavior, and emits enough rule context for tuning.

Difficulty
Advanced
Time
1-2 hours for an engineering proof of concept
Updated
2026-07-26

Guide data

Difficulty
Advanced
Time
1-2 hours for an engineering proof of concept
Updated
2026-07-26
Use case
Useful when engineers need to evaluate Coraza as an embeddable WAF engine or reverse proxy integration.

Prerequisites

  • Comfort reading Go or proxy configuration.
  • A representative upstream application.
  • A clear decision between embeddable engine and proxy integration.
  • A CRS test and tuning plan.

Deployment workflow

Validate the exact Caddy build, not Coraza in isolation.

1

Decide the integration shape

Coraza is often evaluated as an engine rather than a packaged WAF product. Decide whether the test should use Caddy, a gateway, or custom Go integration.

  • Integration target is documented.
  • Ownership for ongoing tuning is assigned.
  • Rule source and update process are clear.
2

Load a small rule set first

Start with minimal rules or a controlled CRS profile before enabling broader inspection. This keeps early debugging manageable.

  • Rule loading is visible in logs.
  • Clean traffic passes.
  • Rule hits map to specific request fields.
3

Compare with packaged WAF alternatives

Coraza may be a strong engine choice, but teams should compare integration effort against packaged products like SafeLine or managed WAFs.

  • Engineering effort is estimated.
  • Deployment ownership is clear.
  • Observability and rollback are designed.

Validation checklist

  • Confirm the gateway sees request bodies and headers needed by rules.
  • Replay clean and malicious lab requests through the same route.
  • Check rule performance under expected request sizes.
  • Document how rules are updated and reviewed.

Rollback planning

  • Keep a bypass route around the gateway change.
  • Pin rule versions during tests.
  • Separate WAF policy changes from unrelated gateway releases.

Common mistakes

  • Treating an engine evaluation like a turnkey product deployment.
  • Skipping rule update and ownership planning.
  • Testing only standalone payloads instead of real application requests.

Related WAF profiles

Lab verification

Commands to capture during the proof of concept

These checks are intentionally conservative. Replace hostnames and ports with your lab values, then save the outputs with the test notes.

1

Build the tested Coraza Caddy image

docker build --provenance=false -t wafwiki/coraza-caddy:2.5.0 docs/lab-fixtures/coraza-caddy

The build resolves Caddy 2.11.2, coraza-caddy 2.5.0, Coraza 3.7.0, and coraza-coreruleset 4.25.0.

2

Run the reproducible request matrix

scripts/run-waf-evidence-lab.sh

The Coraza path records six clean HTTP 200 decisions and four controlled SQLi/XSS HTTP 403 decisions.

3

Inspect JSON request-body rules

rg 'ARGS:json|942100|941100|949110' docs/lab-evidence/waf-engine-comparison-2026-07-26-coraza.log

The log identifies parsed JSON fields and the SQLi, XSS, and blocking-evaluation rules used in the recorded decisions.

FAQ

What does the Coraza Caddy Docker Setup and CRS Validation Guide workflow validate?

It validates plugin or module compatibility, configuration loading, clean proxy traffic, CRS event visibility, and repeatable startup for the selected Caddy build.

What must pass before Coraza Caddy Docker Setup and CRS Validation Guide is used in production?

Do not promote the build until module provenance, update method, request-body limits, exclusions, logs, and rollback to a non-WAF Caddy configuration are documented.

Sources