Contribution Guidelines :: CRS Documentation

The 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 of