ModSecurity v3 is only the library: connectors, submodules, and the operators that vanish when a dependency is missing

This tree is the library, and nothing here plugs into a web server

The v3/master branch contains the library portion only. The traditional module logic for Nginx, Apache and IIS, which used to be packaged together with everything else, is gone from this branch, so cloning this repository does not put a web application firewall in front of anything. What it gives you is libmodsecurity, an interface that loads and interprets rules written in the SecRules format and applies them to HTTP content supplied by your application. Something has to supply that content, and that something is a Connector: each one interfaces with its web server and hands the library a common format it understands, and each is maintained as its own GitHub project with its own release cycle, issue tracker and development tree. The Nginx connector is supplied by the ModSecurity-nginx project. The stated benefit of the split is that installing ModSecurity v3 gives you exactly what you need with no extras you will not use. The practical consequence is that the version of ModSecurity in production is a combination of two repositories, and a support question about Nginx behaviour has to be filed against the connector, not against this one.

Apache dependencies are gone at compile time and at run time

The project describes itself as a complete rewrite of the ModSecurity platform. It started as an Apache module, and was extended over time, with demand, to cover other platforms including Nginx and IIS. To support that demand it became necessary to remove the Apache dependencies underneath it, and the rearchitecture took the library to a state where it no longer depends on the Apache web server either at compilation or during runtime. Removing those dependencies is what makes the library platform independent, and the README states the intended side effect: increased performance across platforms. The same rewrite is where the rule language sits now. Rules still arrive in the SecRules format, so an existing rule set is still the input format rather than something new to learn, and the repository ships modsecurity.conf-recommended as a starting configuration. What changed underneath is the host environment. Behaviour that used to come from the Apache module rather than from your rules is no longer inherited from the server, so a v2 deployment that relied on that surrounding context has to be reviewed rule by rule rather than assumed equivalent.

An uninitialized submodule is a build failure, and mbedTLS moved

The repository carries submodules, and the README says to initialize them after cloning. If you are working from a git checkout, clone recursively or initialize everything before you build:

git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity

git submodule update --init --recursive

You can check the result, because correctly initialized submodules show a commit hash while a leading - means the submodule has not been initialized:

git submodule status

The libinjection library backs the @detectXSS and @detectSQL operators.

PCRE2 is the default, and legacy PCRE is an explicit choice

Regular expression processing inside SecRules goes through the Regex utility in src/utils/regex.*, and it is used by operators including @rx, @rxGlobal and @verifyCC. The default is not negotiable by accident: PCRE2 is detected at build time and used, and the current expectation is that builds use PCRE2 unless someone deliberately configures otherwise. The fallback exists but has to be asked for, because legacy PCRE is only used when --with-pcre is explicitly provided, which the build system exposes as WITH_PCRE. So two binaries built from the same source can run different regex engines, and the difference is invisible in the configuration files, since the rule text stays the same. A rule set validated against the default PCRE2 build has not necessarily been validated against the fallback build. If a distribution package or an internal build script passes --with-pcre, re-run your own rules against that binary rather than trusting the earlier result, particularly for @rxGlobal and @verifyCC, where a pattern that matches more or less than intended changes what gets blocked.

Operators and directives go missing at build time without an error

Some dependencies are mandatory and some are not, and the difference decides what your binary can do. The library is written in C++ using the C++17 standard, and Flex and Bison (Yacc) produce the parser for the Sec Rules Language. YAJL is mandatory because ModSecurity uses JSON for logging and for its testing framework. libXML2 is optional and used for parsing XML requests. The sharp edges are the operator-specific ones: libinjection is required for the @detectXSS and @detectSQL operators, and curl is required for the SecRemoteRules directive. The stated behaviour when those libraries are missing is that ModSecurity will be compiled without support for the respective operators or directives. That is a capability loss: the respective operators are simply not compiled in. Any dependency tied to an operator in your SecRules or to a configuration directive may also not be needed for compilation at all, so check the build log rather than assuming the absence of a link error means the feature is present.

Unix uses autotools, and the library has to land somewhere the loader searches

On Unix-like systems, which the project names as Linux, macOS and FreeBSD, compilation runs through autotools. Once the submodules are in place the build sequence is:

./build.sh
./configure
make
sudo make install

Distribution-specific instructions are not in this repository; they live in the wiki under Compilation Recipes. Windows is a separate path, with build information in build/win32/README.md and a vcbuild.bat script at the repository root. One requirement applies everywhere and is easy to miss: libmodsecurity is a dynamic library, so after installing it you must have placed it where the operating system can find dynamic libraries. Nothing in the install step guarantees that for you. A library installed under a prefix your loader does not search produces a web server or connector that starts and then fails to load the module, which reads like a web server misconfiguration rather than a library problem. The repository also ships modsecurity.pc.in, a pkg-config template, which is the practical way to confirm the install landed where other tools expect it.

The examples show the embedding modes, and v2 is still being released

The examples directory is a map of how the library is meant to be embedded, and the file names are more informative than the prose: simple_example_using_c, multiprocess_c, multithread, using_bodies_in_chunks, reading_logs_via_rule_message, and reading_logs_with_offset. Each one isolates a decision you have to make, from single process to multiple, from buffering a body in one piece to consuming it in chunks, to how you consume the audit log your own code reads. That matters because the answer to most integration questions is not in the library but in one of these shapes. On version support, the older line is not dead: the README points out that ModSecurity for Apache, the v2.x module, is still under maintenance and available on the v2/master branch. Both lines shipped on the same day, with v3.0.17 and v2.9.15 released 2026-09-29, following v2.9.14 on 2026-07-02. Choosing v2 keeps an Apache module with no separate connector; choosing v3 gives a platform independent library and makes the connector your responsibility.

Editorial conclusion

ModSecurity v3 fits a team that wants a web application firewall decoupled from any single web server, and that is prepared to run two repositories, one for the library and one for the connector in front of Apache, Nginx or IIS. It does not fit a team that wants one package to drop into a web server and forget, because this branch contains no module at all, and it does not fit an unattended build that lets optional dependencies go missing, since a build without libinjection still compiles and then loses @detectXSS and @detectSQL. Before deploying, confirm the connector project you intend to pair with this library, run git submodule status and treat any line starting with a dash as a build blocker, decide deliberately whether your rules were validated against the default PCRE2 engine or a --with-pcre build, and check the rule set for operators whose dependency your build did not include.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. owasp-modsecurity/ModSecurity on GitHub
3. Project website
4. README
5. Releases