ModSecurity, sometimes called Modsec, is an open-source web application firewall (WAF). A WAF filters Hypertext Transfer Protocol (HTTP) requests and responses. It sits between a visitor and a website. It runs inside the Apache HTTP Server web server. It also works with Microsoft Internet Information Services (IIS) and nginx.
History of ModSecurity
Creator: Ivan Ristić. Year: 2002.
Ivan Ristić first developed ModSecurity. He wrote a module to watch traffic on the Apache HTTP Server. The first version came out in November 2002. It worked with Apache HTTP Server 1.3.x. In 2004 Ristić created Thinking Stone. He did this to work on it full time. Breach Security bought Thinking Stone in September 2006. Version 2.0 came out in October 2006. It was released at the OWASP AppSec conference in Seattle.
Breach Security released version 2.5 in February 2008. It changed the rule syntax. Ristić left Breach in December 2008. He founded SSL Labs. Trustwave Holdings bought Breach in June 2010. Trustwave moved ModSecurity to the Apache License 2.0. This license lets other products use it. Microsoft added an IIS port in August 2012. An nginx port came out at Black Hat Briefings in 2012.
Porting the Apache module to other systems took time and work. In December 2015 a full rewrite started. The new library is libmodsecurity. It split the engine from the web server. It connects to the server through an application programming interface (API). Version 3.0 was announced for public use in January 2018. In 2021 Trustwave announced the end of sales for ModSecurity. Sales ended on 1 August 2021. Trustwave set the end of its support for 1 July 2024.
The OWASP Foundation took over the project from Trustwave in February 2024. OWASP stands for Open Web Application Security Project. The OWASP ModSecurity Core Rule Set (CRS) is a set of rules. The rules are written in the SecRule language. Most sites that use it load the CRS. The CRS blocks common attacks. Examples are SQL injection and cross-site scripting.
Changelog and latest update
The first release, version 2.x, was written in C. Version 3.x is written in C++. It runs as a separate engine. Version 3 added connectors for Apache HTTP Server and nginx. The 2.9 line lives on as a branch. The GitHub release list shows version 2.9.15. It is the newest 2.x release. Version 3.0.x releases fix rule transformations. They also fix request body parsing and response inspection.
Release 3.0.17 fixes the t:htmlEntityDecode transformation. That transformation did not decode all ASCII named HTML entities. The release also fixes the t:base64DecodeExt transformation. The fix covers the URL-safe base64 alphabet. It fixes the handling of duplicated filename parameters. They appear in multipart Content-Disposition headers. It also fixes a bypass of response body inspection. The bypass used a mixed case Content-Type value. Some entries have a GitHub Security Advisory (GHSA) ID.
Latest update: 3.0.17, 2026-09-29
GitHub lists version 3.0.17 as the latest release. It is dated 29 September 2026. The release notes list security fixes. One fixes a nullptr dereference. It occurs when an @rx pattern is invalid. Another fixes an uninitialized pointer. It sits in the XML request body processor. A third covers host verification. It applies when remote rules are downloaded. The release also fixes warnings from cppcheck 2.22.0. The OWASP project page still shows version 3.0.16. The GitHub release is the newest source.
Usage examples
It reads its settings from directives in the Apache setup. It can also read them from a modsecurity.conf file. The SecRuleEngine directive turns the engine on or off. It can also set a log-only mode named DetectionOnly. A SecRule line has three parts. The first part lists the variables to inspect. Then comes an operator. Then come the actions. The operator can be @rx for a regular expression. Actions include deny, log and status. The four examples show log-only mode. They show a custom rule. They show the Core Rule Set include. They show the audit log.
SecRuleEngine DetectionOnly
SecAuditEngine RelevantOnlyThe SecRuleEngine directive set to DetectionOnly makes it record rule matches. It does not stop any request. This mode suits a first test on a live site. SecAuditEngine set to RelevantOnly writes the full transaction to the audit log. It writes only when a rule matched.
SecRule ARGS "@rx (?i)<script" \
"id:100001,phase:2,deny,status:403,\
log,msg:'Script tag in request'"This custom rule checks each request argument for the text script tag. Case is ignored through the (?i) flag. The deny action stops the request. The status:403 setting returns a 403 Forbidden response. The id value 100001 is a local rule number. The log action records the match and its message text.
Include /etc/crs/crs-setup.conf
Include /etc/crs/rules/*.confThe first Include line loads the CRS setup file. The second line loads each rule file in the rules folder. The paths depend on where the files were installed. Change them to match the server before a restart.
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^5"The SecAuditLogRelevantStatus directive takes a regular expression. It matches HTTP status codes. This pattern logs each 5xx server error. The audit log keeps each request that caused a server error. The record holds the full transaction.
References
These sources are outside Websnoogie and were checked on 2026-10-12.
OWASP ModSecurity project
OWASP Foundation
The OWASP project page for ModSecurity. It describes the WAF engine. It covers the transfer from Trustwave to OWASP in February 2024. It names the project leaders. It links to the docs and GitHub source.
ModSecurity release v3.0.17
GitHub, OWASP ModSecurity repository
The release page for version 3.0.17. GitHub marks it as the latest release. It lists each fix. It gives the pull request number and the GitHub Security Advisory ID. It shows the release date used in this entry.
ModSecurity Reference Manual (v3.x)
OWASP ModSecurity wiki on GitHub
The reference manual for ModSecurity version 3. It documents each directive, such as SecRuleEngine, SecRule and SecAuditEngine. It gives the syntax and options. It gives examples of use. The examples on this wiki page follow that manual.
OWASP Core Rule Set
OWASP Core Rule Set project
The Core Rule Set project page. It is the rule set most often used with ModSecurity. It describes the attack types the rules detect. Examples are SQL injection and cross-site scripting. It links to the rule releases and the installation guide.
Apache HTTP Server 2.4 documentation
Apache Software Foundation
The Apache HTTP Server docs. Apache is the web server that ModSecurity was first built to protect. It covers the setup files, the modules and the Include directive. The Include directive loads the ModSecurity and Core Rule Set files.
ModSecurity
Wikipedia
The encyclopedia article on ModSecurity. It gives the history from the 2002 release. It covers the transfer to OWASP. It lists the supported platforms and the release dates of each version. It cites the primary sources.
One missed attack can take a site offline
Ignore web application security and one attack can take a site offline. ModSecurity is a firewall module that inspects each web request and blocks the ones that look like an attack. It guards forms, logins and search boxes, which are the usual targets. When the rules are too strict, real visitors get blocked. When they are too loose, bad traffic reaches your pages. Both problems cost a business time and customers.
We check the rule set on each hosting account we manage. We confirm that the forms, the login page and the checkout still work while the rules are active. When a rule blocks a real visitor, we find that rule, adjust it and retest the page. Each change gets one clear note, explained in plain words. The protection runs on a server rated at 99.999% uptime, so it stays online with your site.
Our 20+ years of web design work cover contact forms, logins and checkout pages. Phone 402-813-4034 to ask about the firewall settings on your current site, or ask us for a new site with the rules already in place.
