https://8192de7b.documentation-km5.pages.dev/6-development/index.htmlHugoen-usWed, 18 Feb 2026 22:11:21 +0200https://8192de7b.documentation-km5.pages.dev/6-development/6-1-contribution-guidelines/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-1-contribution-guidelines/index.htmlThe CRS project values third party contributions. To make the contribution process as easy as possible, a helpful set of contribution guidelines are in place which all contributors and developers are asked to adhere to. Getting Started with a New Contribution Sign in to GitHub. Open a new issue for the contribution, assuming a similar issue doesn’t already exist. Clearly describe the issue, including steps to reproduce if reporting a bug. Specify the CRS version in question if reporting a bug. Bonus points for submitting tests along with the issue. Fork the repository on GitHub and begin making changes there. Signed commits are preferred. (For more information and help with this, refer to the GitHub documentation). Making Changes Base any changes on the latest dev branch (e.g., main). Create a topic branch for each new contribution. Fix only one problem at a time. This helps to quickly test and merge submitted changes. If intending to fix multiple unrelated problems then use a separate branch for each problem. Make commits of logical units. Make sure commits adhere to the contribution guidelines presented in this document. Make sure commit messages follow the standard Git format. Make sure changes are submitted as a pull request (PR) on GitHub. PR titles should follow the Conventional Commits format, for example: fix(rce): Fix a FP in rule 912345 with keyword 'time'. If a PR only affects a single rule then the rule ID should be included in the title. If a PR title does not follow the correct format then a CRS developer will fix it. General Formatting Guidelines for Rules Contributions American English should be used throughout. 4 spaces should be used for indentation (no tabs). Files must end with a single newline character. No trailing whitespace at EOL. No trailing blank lines at EOF (only the required single EOF newline character is allowed). Adhere to an 80 character line length limit where possible. Add comments where possible and clearly explain any new rules. Comments must not appear between chained rules and should instead be placed before the start of a rule chain. All chained rules should be indented like so, for readability: SecRule .. .. \ "..." SecRule .. .. \ "..." SecRule .. .. \ "..." Action lists in rules must always be enclosed in double quotes for readability, even if there is only one action (e.g., use "chain" instead of chain, and "ctl:requestBodyAccess=Off" instead of ctl:requestBodyAccess=Off). Always use numbers for phases instead of names. Format all use of SecMarker using double quotes, using UPPERCASE, and separating words with hyphens. For example: SecMarker "END-RESPONSE-959-BLOCKING-EVALUATION" SecMarker "END-REQUEST-910-IP-REPUTATION" Rule actions should appear in the following order, for consistency: id phase allow | block | deny | drop | pass | proxy | redirect status capture t:xxx log nolog auditlog noauditlog msg logdata tag sanitiseArg sanitiseRequestHeader sanitiseMatched sanitiseMatchedBytes ctl ver severity multiMatch initcol setenv setvar expirevar chain skip skipAfter Rule operators must always be explicitly specified. Although ModSecurity defaults to using the @rx operator, for clarity @rx should always be explicitly specified when used. For example, write: SecRule ARGS "@rx foo" "id:1,phase:1,pass,t:none" instead ofhttps://8192de7b.documentation-km5.pages.dev/6-development/6-2-crs-toolchain/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-2-crs-toolchain/index.htmlThe crs-toolchain is the CRS developer’s utility belt — the Swiss army knife for CRS development. It provides a single point of entry and a consistent interface for a range of different tools. Its core functionality (owed to the great rassemble-go, which is itself based on the brain-melting Regexp::Assemble Perl module) is to assemble individual parts of a regular expression into a single expression (with some optimizations). The current stable release is v2.7.0 (as of December 2025).https://8192de7b.documentation-km5.pages.dev/6-development/6-3-assembling-regular-expressions/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-3-assembling-regular-expressions/index.htmlThe CRS team uses a custom specification format to specify how a regular expression is to be generated from its components. This format enables reuse across different files, explanation of choices and techniques with comments, and specialized processing. Specification Format The files containing regular expression specifications (.ra suffix, under regex-assembly) contain one regular expression per line. These files are meant to be processed by the crs-toolchain.https://8192de7b.documentation-km5.pages.dev/6-development/6-4-using-the-crs-sandbox/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-4-using-the-crs-sandbox/index.htmlInfo The CRS Sandbox is a shared public resource. Please review the CRS Sandbox Security Policy before use. Introducing the CRS Sandbox We have set up a public CRS Sandbox which you can use to send attacks at the CRS. You can choose between various WAF engines and CRS versions. The sandbox parses audit logs and returns our detections in an easy and useful format.https://8192de7b.documentation-km5.pages.dev/6-development/6-5-testing-the-rule-set/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-5-testing-the-rule-set/index.htmlWell, you managed to write your rule, but now want to see if if can be added to the CRS? This document should help you to test it using the same tooling the project uses for its tests. CRS uses go-ftw to run test cases. go-ftw is the successor to the previously used test runner ftw. The CRS project no longer uses ftw but it us still useful for running tests of older CRS versions.https://8192de7b.documentation-km5.pages.dev/6-development/6-6-useful_tools/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-6-useful_tools/index.htmlThere are many first and third party tools that help with ModSecurity and CRS development. The most useful ones are listed here. Get in touch if you think something is missing. albedo https://github.com/coreruleset/albedo The backend server used by the CRS test suite. It is especially useful for testing response rules, as desired responses can be freely specified.https://8192de7b.documentation-km5.pages.dev/6-development/6-7-tools-for-rule-writers/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/6-development/6-7-tools-for-rule-writers/index.htmlThis page brings together essential tools that help rule writers create better, more effective CRS rules. From testing regular expressions to understanding database behavior, these resources will help you write rules using modern techniques and best practices. Writing effective WAF rules requires understanding how attacks work, how payloads behave in different contexts, and how to create patterns that detect malicious behavior without causing false positives. The tools listed here will help you throughout the entire rule development process.https://8192de7b.documentation-km5.pages.dev/crs-sandbox-policy/index.htmlWed, 18 Feb 2026 22:11:21 +0200https://8192de7b.documentation-km5.pages.dev/crs-sandbox-policy/index.htmlDocument Version: 1.0 Last Updated: 2026-02-19 Maintained by: OWASP CRS Team 1. Overview The OWASP CRS Sandbox (https://sandbox.coreruleset.org/) is a public, shared testing environment that allows users to evaluate CRS detection capabilities against real payloads — without requiring a local WAF installation. Because it is publicly accessible and shared across all users, responsible usage is essential to ensure availability, integrity, and fair access for everyone.