Skip to content
EdgeServers
Blog

ModSecurity and the OWASP CRS — the WAF rules we actually ship on Apache

May 14, 2026 · 1 min read · by Sudhanshu K.

This is a snippet. The full article lives on Medium.

ModSecurity is one of those tools almost everyone has installed and almost nobody has tuned. The pattern in audits is consistent: the module is loaded, the OWASP Core Rule Set is dropped in at default settings, the logs fill up with thousands of alerts nobody reads, and either (a) it's been quietly running in DetectionOnly for years, or (b) it's blocking legitimate traffic and the customer doesn't know.

Both modes mean the WAF is doing nothing useful.

Why bother in 2026 when Cloudflare exists?

Three reasons we still deploy origin-level ModSecurity behind a cloud WAF:

  1. Defence in depth. The cloud WAF is one layer. When it misclassifies, or the customer hasn't enabled a rule pack, or someone discovers the origin IP, the inner layer catches what edge missed.
  2. Application-specific rules. Cloudflare doesn't know that your /admin/export endpoint should never see a SELECT keyword. ModSecurity at the origin can.
  3. Forensics. ModSecurity's audit log gives you the full request that triggered the rule. Cloud WAFs give you sampled, lossy data.

The base configuration

ModSecurity 3 (libmodsecurity) with the Apache connector — not the legacy v2:

<IfModule security2_module>
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRequestBodyLimit 13107200
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABIJDEFHZ
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/rules/*.conf
</IfModule>

Then the actual tuning work — picking the right paranoia level, allowlisting the rules that fire on your application's normal traffic, and writing the per-route rules that Cloudflare can't. The full Medium write-up covers:

  • Paranoia Level 1 → 4 — what each adds, and the level we ship by default
  • The "false-positive triage" workflow we run for two weeks before flipping to block mode
  • Custom rules for common application paths (admin, API endpoints, file uploads)
  • Sending the audit log to the SIEM, and the dashboards we watch
  • The rules we always disable (and why)

Continues on Medium.