ModSecurity

What ModSecurity actually is

ModSecurity is the open-source web application firewall engine that invented most of what the category now takes for granted. Ivan Ristić released the first version in November 2002 as a module for the Apache HTTP Server — a way to make Apache understand and control HTTP traffic before it reached an application. It has been in continuous use ever since: through Ristić's company Thinking Stone, through Breach Security (which bought Thinking Stone in 2006 and shipped the 2.0 rewrite at the OWASP AppSec conference in Seattle), through Trustwave (which acquired Breach in June 2010 and relicensed the code under Apache 2.0), and since January 2024 under OWASP custodianship after Trustwave handed the project over. Twenty-three years old, free, and still the most widely deployed open-source WAF engine in existence.

What it does: inspects HTTP requests and responses against rules and blocks or logs what matches. Request bodies, headers, cookies, arguments, response codes — all visible to the SecRule language. The engine alone is deliberately a blank slate; ModSecurity ships with almost no protection out of the box. The protection comes from the OWASP Core Rule Set (CRS), a separate, actively maintained rule library that covers the generic attack classes of the OWASP Top 10 and adapts to your application without knowing it. The CRS project lives under the same OWASP roof, and the pairing of engine plus CRS is what people mean when they say "ModSecurity."

The architecture today has two lines. The mature one is ModSecurity 2.9.x, an Apache module (the current 2.9.14 shipped in July 2026 alongside CRS security fixes). The newer one is libmodsecurity 3.x, a standalone engine that talks to web servers through connectors — the nginx and IIS ports date from 2012 work, and the v3 rewrite began in December 2015 to untie the engine from any single server. In our view the honest summary is: v2 on Apache is battle-tested to the point of boring; the v3 connector path has had a rockier maturity curve, which is why a large share of production deployments remain Apache-based. OWASP has also begun coordinating with Coraza, a newer engine implementing the same rules language, which is worth watching for anyone starting fresh.

Pricing: what you really pay

There is nothing to buy. ModSecurity is free software under the Apache License 2.0, the CRS is free, and both run on commodity Linux servers. There is no enterprise edition, no licence key, no seat count, and no vendor upsell — Trustwave exited ModSecurity support sales entirely (end-of-sale in August 2021, end-of-life July 2024), and OWASP, a nonprofit, does not sell support.

So the cost is entirely in people and hardware. Tuning CRS on a real application is skilled work: the rule set runs in detection-only mode by design at first, logs must be read, false positives pruned per application, and paranoia levels chosen deliberately. A system administrator who can do this competently costs more per hour than most managed WAF subscriptions, which is the paradox of this product — the free engine sits at the bottom of a market where the expensive part is the expertise. If you have that expertise in-house (or a team willing to learn it), ModSecurity plus CRS is a fraction of the cost of a managed WAF and gives you full data control. If you do not, a managed service in our firewall and DDoS category will be cheaper than hiring.

Performance & infrastructure

As self-hosted software, ModSecurity has no datacenters, no SLA, and no bandwidth — it runs inside your web server, so its performance profile is the inspection cost on your traffic. Rule matching is per-request CPU work; CRS at higher paranoia levels inspects more and costs more. The practical guidance from the community is consistent: start with CRS in detection-only mode at paranoia level 1, measure, tune, then switch to blocking. Do this and the overhead is modest; skip it and you will either block legitimate users or drown in logs.

Deployment surface is broad: Apache (the original and strongest path), nginx and IIS via connectors, containers (the OWASP CRS project publishes Docker images for ModSecurity with Apache and nginx, including LTS tags), and Debian/Ubuntu packages maintained by community contributors. The CRS release discipline is genuinely good — coordinated releases with long-term-support branches (v4.25 LTS arrived in March 2026) and prompt security fixes; the July 2026 releases patched two high-severity XML body-parsing vulnerabilities across v3.3.10, v4.25.1 and v4.28.0 in one coordinated drop. That is what an actively maintained security project looks like, and it is the main reason we still recommend this stack in 2026.

What the infrastructure story does not include: volumetric protection. ModSecurity operates at layer 7 and does no bandwidth absorption or rate-based DDoS mitigation — it can rate-limit with rules, but a real DDoS needs upstream scrubbing or a CDN. Plan it as one layer, not the perimeter.

Where it falls short

The engineering limitations are real. ModSecurity needs server-level integration: recompiling or packaging modules, wiring the connector, owning the config across web server upgrades. It is not a drop-in service you point DNS at. The v3 branch's connector story has been the recurring complaint for years — for a long time the nginx connector lagged the Apache module in production readiness, and some teams that wanted nginx ended up on alternatives.

Then there is tuning. CRS out of the box is intentionally paranoid about not breaking your app and noisy about what it sees; false positives are guaranteed on any real application with file uploads, JSON endpoints, or non-ASCII input. Teams that deploy it in blocking mode on day one and walk away end up disabling it within a week. The 2017 ModSecurity Handbook (Folini and Ristić) and the CRS project documentation are good, but this is still a tool for people who read logs.

Governance is a watch item rather than a complaint. The move to OWASP in 2024 was the right outcome — open governance, roadmap task, close CRS integration — but the project is carried by a small group of long-term contributors (the OWASP project pages name a handful of active maintainers). It is community-supported software with no support contract to buy; when something breaks at 3am, the answer is the mailing list, GitHub, and your own team.

Who should pick this

A concrete setup we like, for the record: ModSecurity 2.9.x on Apache inside a container, the OWASP CRS at paranoia level 1 in detection-only mode, logs shipped to something you actually read, and a two-week tuning window before blocking goes live. During that window, whitelist per application (the CRS per-rule exclusions and the sampling tools in the CRS ecosystem both help), then raise paranoia only where the false-positive budget allows. Run the LTS rule branch if you value stability over the newest checks — that is exactly what the LTS line introduced in March 2026 is for.

We pick ModSecurity when you run your own web servers and need application-layer filtering with full control over the rules: sysadmins protecting self-hosted WordPress, PHP, or custom apps; teams with compliance requirements that demand an on-premises WAF; organisations that cannot send traffic through a third-party proxy; and anyone building a layered defense where a WAF sits in front of the app alongside sane coding practices. The Apache/CRS combination is our default recommendation in that situation, ideally in a container for reproducibility.

We would not pick it for teams without security operations capacity, for anyone expecting a managed WAF experience, or as DDoS protection — those needs point to managed offerings in our firewall and DDoS category. And if you are starting a new nginx-based stack today, evaluate Coraza alongside libmodsecurity before committing; the rules language is shared, and the ecosystem is moving toward both engines implementing it in lockstep.

Key takeaways

• Free Apache-2.0 WAF engine, first released November 2002, now stewarded by OWASP (custodianship transferred from Trustwave in January 2024).
• The engine alone blocks almost nothing — protection comes from the OWASP Core Rule Set, which is actively maintained with LTS branches and coordinated security releases (as recently as July 2026).
• Apache 2.9.x is the battle-tested path; the libmodsecurity 3.x connector line (nginx, IIS) has had a slower maturity curve — factor that into platform choice.
• Zero licence cost; the real cost is tuning expertise — start in detection-only mode at low paranoia, then tighten.
• Layer 7 only: no volumetric DDoS absorption, no managed option, no SLA, community support via OWASP channels.
• Our pick for self-hosted stacks that need on-premises, auditable application-layer filtering; a managed WAF is the better answer without in-house expertise.

Sources

• https://modsecurity.org/history
• https://en.wikipedia.org/wiki/ModSecurity
• https://owasp.org/projects/modsecurity?tab=main
• https://owasp.org/blog/2024/01/09/ModSecurity
• https://devguide.owasp.org/en/09-operations/03-modsecurity
• https://coreruleset.org/20260702/crs-versions-4.28.0-4.25.1-lts-and-3.3.10-released
• https://coreruleset.org/20260321/announcing-crs-v4-25-lts
• https://www.trustwave.com/hubfs/Web/Library/Documents_pdf/15320_modsecurity-rules-and-support_letter-prt.pdf