Skip to content
OAShield

ModSecurity & Coraza

OAShield generates rules in SecLang, the rule configuration language shared by the two major open-source WAF engines. You pick the target with a single option (engineFlavor, see Configuration). This page introduces both engines.

ModSecurity v3

OWASP ModSecurity is the original open-source web application firewall engine. Version 3 (libmodsecurity) is a standalone library with connectors for nginx and Apache HTTP Server, licensed under Apache 2.0. It provides real-time monitoring, logging, and filtering of HTTP traffic based on SecLang rules.

Coraza

Coraza is a modern, actively developed WAF engine written in Go, compatible with ModSecurity’s SecLang and the OWASP Core Rule Set. It embeds into Go applications and cloud-native proxies, including Envoy (via proxy-wasm) and HAProxy (via coraza-spoa), which makes it a natural fit for Kubernetes sidecars and modern edge stacks.

For OAShield specifically, Coraza has one extra capability: its JSON @validateSchema operator lets the generated rules validate raw request bodies against a JSON Schema, covering constraints that per-field rules can’t express. See Engine flavors.

SecLang and the Core Rule Set

Both engines are configured with SecRules: directives that inspect requests and responses and act on matches. Hand-written rules are powerful but labor-intensive, which is why most deployments run the OWASP Core Rule Set (CRS), a broad, generic set of attack-detection rules covering the OWASP Top Ten and beyond.

CRS is a negative model: it recognizes known-bad patterns. OAShield generates the complementary positive layer, rules that permit only the operations your OpenAPI spec defines. Run together, unknown traffic is denied by the OAShield rules, and the traffic that remains is still screened by CRS.

Deploying OAShield rules

  1. Define the OpenAPI specification. Document all endpoints, methods, parameters, and request bodies. The spec’s precision determines the rules’ strictness.
  2. Generate rules with OAShield. One command produces standard .conf files; see the Quick Start.
  3. Deploy. Include the generated files in your ModSecurity or Coraza configuration, at the edge, in a sidecar, or on the web server itself.
  4. Test and monitor. Start in detection-only mode to verify legitimate traffic is unaffected, then enable blocking. The audit log shows every contract violation.