https://modsecurity.org/docs/6-migration/index.htmlMoving rules and configuration between ModSecurity generations.Hugoen-UShttps://modsecurity.org/docs/6-migration/6-1-migrating-from-2x-to-3x/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/6-migration/6-1-migrating-from-2x-to-3x/index.htmlThis page is for administrators moving a working ModSecurity v2 (Apache mod_security2 or IIS) deployment to libModSecurity v3, typically because the web server changes to NGINX. Both versions are maintained by OWASP and implement the same rule language, so rule sets such as the OWASP CRS run on both; the differences are in the architecture, in a few evaluation details and in the legacy features v3 does not implement. If you stay on Apache httpd or IIS there is no need to migrate: v2 remains the supported choice there (current release 2.9.15).https://modsecurity.org/docs/6-migration/6-2-migrating-from-1x-to-2x/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/6-migration/6-2-migrating-from-1x-to-2x/index.htmlIf you are already using an older version of ModSecurity and want to upgrade/migrate your existing custom rules, you will need to ensure that you properly translate all of your Directives to their corresponding 2.x counterparts. Some directives have simply changed names, however some directives actually behave differently so it is important that you also review the entire 2.0 Reference Manual. The migration matrix show below should help you to translate ModSecurity 1.X directives to the 2.0 values. There are also some notes that provide additional information is a directive significantly changed how it operates.https://modsecurity.org/docs/6-migration/6-3-rules-language-porting/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://modsecurity.org/docs/6-migration/6-3-rules-language-porting/index.htmlThe rules language that ModSecurity v2 and libModSecurity v3 implement, usually called SecLang, is also implemented by other engines, most notably OWASP Coraza. Rather than a porting checklist maintained here, the language is specified independently of any engine at https://seclang.org/: The specification describes every directive, variable, operator, action and transformation with its syntax and semantics. The compatibility matrix records, for each item, whether ModSecurity v2, libModSecurity v3 and Coraza implement it, and marks the items that are deprecated. It is the authoritative answer to “will this rule work on engine X” and the source of the lists in Migrating from v2 to v3. The Coraza playground runs a rule against a request in the browser and is a quick way to check syntax before deploying. If you are porting the language to a new engine, start from the matrix: the items every engine implements (SecRule, SecRuleEngine, the request and response variables, @rx and the numeric operators, the core actions and transformations) are the ones rule sets such as the OWASP CRS depend on everywhere, and the rest can follow the matrix’s deprecation marks.