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:

# Validate request line against the format specified in the HTTP RFC
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. It’s important to understand that CRSLang is a language for rule writers, not for WAF engines to parse directly. The accompanying tooling handles the translation to engine-specific formats, taking into account each engine’s quirks and capabilities.

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
      - language-multi
    version: OWASP_CRS/4.0.0
  conditions:
    - variables:
        - REQUEST_LINE
      operator:
        negate: true
        rx: (?i)^(?:get /[^#\?]...
      transformations:
        - none
  actions:
    disruptive: block
    non-disruptive:
      - logdata: "%{request_line}"
      - setvar:
          collection: TX
          operation: =+
          assignments:
            - 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 a clean syntax for logical conjunctions (logical “and”), and we are working on extending its logical capabilities. In the following example, the rule has three logical conjunctions, which would be expressed as chained rules in Seclang:

rule:
  metadata:
    phase: 1
    id: 920310
    message: Request Has an Empty Accept Header
  conditions:
    - collections:
        - name: REQUEST_HEADERS
          arguments:
            - Accept
      operator:
        rx: ^$
      transformations:
        - none
    - variables:
        - REQUEST_METHOD
      operator:
        negate: true
        rx: ^OPTIONS$
    - collections:
        - name: REQUEST_HEADERS
          arguments:
            - User-Agent
      operator:
        negate: true
        pm: AppleWebKit Android Business Enterprise Entreprise
      transformations:
        - none
  actions:
    disruptive: block

3. Common Definitions

CRSLang supports reusable rule components through common definitions, making it easier to maintain consistent patterns across your rule set. You can define patterns at a global or scoped level and reference them from multiple rules, ensuring consistency without duplication.

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.

The Tooling Vision

CRSLang is designed as the single source of truth for rule writers. The real power lies in the tooling that surrounds it:

This approach means rule writers only need to learn one language, while the tooling handles the complexity of supporting multiple WAF platforms.

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