Introducing CRSLang: The Next Generation Rule Language for OWASP CRS

January 22, 2026 By Felipe Zipitria

We’re excited to introduce CRSLang, a new YAML-based rule language that will replace Seclang in the next major release of OWASP CRS. This represents a significant evolution in how we write, maintain, and deploy WAF rules.

Why CRSLang?

For nearly two decades, the OWASP CRS has relied on ModSecurity’s Seclang syntax. While Seclang has served us well, it comes with significant limitations that have become increasingly apparent as the project has grown:

The Problems with Seclang

Consider this typical Seclang rule:

SecRule REQUEST_LINE "!@rx (?i)^(?:get /[^#\?]..." \
    "id:920100,\
    phase:1,\
    block,\
    t:none,\
    msg:'Method is not allowed by policy',\
    logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
    tag:'application-multi',\
    tag:'attack-protocol',\
    ver:'OWASP_CRS/4.0.0',\
    severity:'WARNING'"

Can you quickly understand what this rule does? The metadata, transformations, operators, and actions are all jumbled together in a single string, making it difficult to parse both for humans and machines.

Enter CRSLang

CRSLang is a YAML-based, technology-agnostic rule language designed to address these limitations while maintaining full backward compatibility with existing Seclang rules. Here’s the same rule in CRSLang format:

rule:
  metadata:
    comment: "Validate request line against the format specified in the HTTP RFC"
    phase: 1
    id: 920100
    message: Invalid HTTP Request Line
    severity: WARNING
    tags:
      - application-multi
      - attack-protocol
  conditions:
    - variables:
        - name: REQUEST_LINE
      operator:
        rx: (?i)^(?:get /[^#\?]*...$
      transformations:
        - none
  actions:
    disruptive: block
    non-disruptive:
      - logdata: "%{request_line}"
      - setvar: tx.inbound_anomaly_score_pl1=+%{tx.warning_anomaly_score}

The difference is immediately apparent. The rule structure is clear, with distinct sections for metadata, conditions, and actions.

Key Features

1. Clear Structure and Separation of Concerns

CRSLang separates metadata, conditions, and actions into distinct, easy-to-understand sections. This makes rules easier to read, validate, and maintain.

2. Improved Logical Expressions

Seclang’s support for complex logical conditions is limited and often requires workarounds. CRSLang provides clean AND/OR syntax:

rule:
  metadata:
    id: 1
    phase: 1
  conditions:
    - and:
        - or:
            - variables:
                - name: ARGS:user
              operator:
                streq: "admin"
            - variables:
                - name: ARGS:username
              operator:
                streq: "admin"
        - variables:
            - name: REQUEST_LINE
          operator:
            contains: "admin"
  actions:
    disruptive: block

3. Template Functions

CRSLang introduces reusable rule components, making it easier to maintain consistent patterns across your rule set:

templates:
  admin_check:
    conditions:
      - or:
          - variables:
              - name: ARGS:user
            operator:
              streq: "admin"
          - variables:
              - name: ARGS:username
            operator:
              streq: "admin"

rules:
  - metadata:
      id: 1
      phase: 1
    conditions:
      - and:
          - template: admin_check
          - variables:
              - name: REQUEST_LINE
            operator:
              contains: "admin"
    actions:
      disruptive: block

4. Bidirectional Translation

One of CRSLang’s most powerful features is its bidirectional translation capability. We’ve built a robust parser that can:

This means you can gradually migrate to CRSLang while maintaining compatibility with existing tools and deployments. The translation engine ensures that no information is lost in the conversion process, and round-trip testing validates correctness.

Building on Previous Work

CRSLang builds upon the foundation laid by earlier parser projects. If you’re familiar with our msc_pyparser tool, you’ll recognize the concept of converting ModSecurity rules into structured formats. CRSLang takes this concept further by providing a complete, production-ready language specification with full tooling support.

While msc_pyparser focused on rule manipulation through Python, CRSLang provides a comprehensive language specification with:

The Technology

CRSLang is powered by a sophisticated parser built with ANTLR, providing:

The project is fully open source and available at github.com/coreruleset/crslang.

Looking Forward

CRSLang represents more than just a syntax change—it’s a foundation for the future of OWASP CRS. With this new language, we’re opening doors to:

Timeline and Migration

CRSLang will replace Seclang as the primary rule language in the next major release of OWASP CRS. We’re committed to making this transition as smooth as possible:

  1. Current state: CRSLang parser and tooling are available now
  2. Migration period: Full backward compatibility maintained through translation engine
  3. Next major release: CRSLang becomes the default format
  4. Long-term support: Seclang translation capabilities maintained for existing deployments

You can start exploring CRSLang today by:

Get Involved

We’re excited about this evolution and would love your feedback. Whether you’re a long-time CRS contributor or new to the project, your input is valuable as we shape the future of WAF rule development.

Join the conversation:

The future of OWASP CRS is clearer, more maintainable, and more accessible. We can’t wait to see what the community builds with CRSLang.

Felipe Zipitria