https://modsecurity.org/docs/7-development/index.htmlContributing to ModSecurity, the roadmap, and related tools.Hugoen-UShttps://modsecurity.org/docs/7-development/7-1-contributing/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/7-development/7-1-contributing/index.htmlModSecurity was transferred from Trustwave to OWASP in January 2024 and is developed by a small group of maintainers together with the community. Contributions of every kind are welcome: bug reports, fixes, features, tests, packaging, documentation and help for other users. This page explains how the project works and what a good contribution looks like. Where things happen Code: https://github.com/owasp-modsecurity/ModSecurity, with the v2 engine on the v2/master branch and the v3 library on v3/master (the default branch). The connectors are separate repositories: ModSecurity-nginx and ModSecurity-apache. This documentation: https://github.com/owasp-modsecurity/documentation (every page has an edit link). Discussion: the #project-modsecurity channel on the OWASP Slack and the GitHub issue tracker. Questions about configuration and rules are best asked on Slack or as a GitHub discussion before opening an issue. Project page: https://owasp.org/www-project-modsecurity/, which lists the project leaders. They review and merge every pull request. Reporting a bug Open an issue at https://github.com/owasp-modsecurity/ModSecurity/issues after checking that it has not been reported. Include the engine version (2.9.x or 3.0.x), the connector and its version for v3, the web server version, the operating system or package, the smallest rule that reproduces the problem, the request that triggers it, and the relevant debug log at level 9 (SecDebugLogLevel 9). A failing regression test case (see below) is the most useful report of all, since it becomes the test that keeps the bug fixed.https://modsecurity.org/docs/7-development/7-2-roadmap/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/7-development/7-2-roadmap/index.htmlModSecurity has no separate roadmap document. Planned work, release targets and open design questions are tracked in the open on GitHub, where you can comment and vote: Issues - bugs and feature requests for both code lines. Label 2.x or 3.x selects the engine, and the help wanted label marks items waiting for a contributor. Milestones - what is scheduled for the next v2.9.x and v3.0.x releases. Pull requests - work in progress. The connectors have their own trackers: ModSecurity-nginx issues and ModSecurity-apache issues. Both engines are maintained: v2 for Apache httpd and IIS, v3 as the library behind the NGINX connector. There is no plan to retire v2, and features are added to both when they make sense on both; the compatibility matrix of the SecLang specification shows where they differ. Larger discussions happen on the OWASP Slack in #project-modsecurity and at the project’s monthly community calls announced there; see Contributing.https://modsecurity.org/docs/7-development/7-3-tools/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/7-development/7-3-tools/index.htmlTools that are useful when writing, testing and operating ModSecurity rules. Projects are listed with the organization that maintains them; the OWASP CRS project and the digitalwave team (one of the ModSecurity maintainers) produce most of the current tooling. Rule sets OWASP CRS - the rule set almost every ModSecurity deployment runs. Repository, documentation, plugin registry for application-specific exclusions (WordPress, Nextcloud, Drupal, phpBB, phpMyAdmin, DokuWiki, cPanel, XenForo) and add-ons such as the DoS-protection, antivirus, body-decompress, fake-bot and auto-decoding plugins. Comodo free ModSecurity rules - a commercial vendor’s free rule set. Writing and checking rules SecLang specification - the engine-independent specification of the rules language, with a compatibility matrix for ModSecurity v2, libModSecurity v3 and Coraza. Coraza playground - run a rule against a request in the browser. crs-toolchain - the CRS developers’ command-line tool: assembles regular expressions from .ra files, renumbers and updates rules. Installable from the CRS Homebrew tap. crs-linter - checks rules files against the CRS formatting and naming conventions. msc_pyparser - a Python parser for SecLang that produces an abstract syntax tree and writes rules back, for bulk edits, linting and analysis. secrules_parsing and seclang_parser - the CRS project’s Python and ANTLR parsers for the language. msc_retest - measures how long a regular expression takes in the PCRE and PCRE2 engines, for spotting patterns that are slow or vulnerable to regular-expression denial of service. vscode-language-modsecurity - SecLang syntax highlighting for Visual Studio Code, and regexp-assemble-syntax for the .ra files. Testing rules and engines go-ftw - the Framework for Testing WAFs: sends the HTTP requests described in YAML test files to a web server running ModSecurity and checks the logs for the expected rule matches. It is how the CRS test suite runs; the YAML format is defined by ftw-tests-schema. The older Python ftw is no longer developed. ftwrunner - runs the same FTW test files directly against libModSecurity, without a web server. secrules-language-tests - the regression test cases shared by ModSecurity v2 and v3 (a git submodule of the engine) that any SecLang implementation can use to check itself. MRTS - the ModSecurity Regression Test Set. modsecurity-crs-docker - the official container images with ModSecurity v2 on Apache httpd or libModSecurity on NGINX and the OWASP CRS preinstalled, the quickest way to get a test instance. The engine’s own test tools: tests/msc_test and run-unit-tests.pl in the v2 tree, test/regression_tests, test/unit_tests and test/benchmark in the v3 tree (see Contributing). Working with logs libmsclogparser - a C library (with Python bindings) that parses ModSecurity audit and error log entries. modsecurity-parser - analyzes native and JSON audit logs and produces JSON, Excel and chart summaries. ModSecurity-log-utilities - command-line tools from the former maintainer that turn audit logs into summaries. logstash-modsecurity - Logstash filters for the native audit log format. With SecAuditLogFormat JSON most log pipelines need no special parser. modsec-sdbm-util - inspects and shrinks the SDBM files that ModSecurity v2 uses for persistent collections. WAF-FLE - a web console for audit logs; no longer maintained but still used. Integrating the engine Connectors: ModSecurity-nginx (NGINX) and ModSecurity-apache (Apache httpd, not production ready); see the installation chapter. Bindings for libModSecurity: pymodsecurity (Python), rust-modsecurity (Rust), vmod-modsecurity (Varnish). Proxies and gateways: modsecurity-spoa runs libModSecurity as an HAProxy stream-processing agent; traefik-modsecurity-plugin forwards Traefik requests to the CRS container image; modsecurity-wasm-filter packages the engine as a WebAssembly filter for Envoy and Istio. OWASP Coraza - a Go implementation of SecLang that runs the OWASP CRS and ships its own connectors (Caddy, proxy-wasm for Envoy, HTTP middleware), for environments where a C++ library does not fit.