Scoped backtracking control

[dadrus]

Preflight checklist

• [x] I agree to follow this project's Code of Conduct.
• [x] I have read and am following this repository's Contribution Guidelines."
• [ ] I have discussed this feature request with the community.

Describe the background of your feature request

Heimdall’s current backtracking mechanism, controlled by the backtracking_enabled flag (disabled by default), allows a rule to fall back to less specific matches when its conditions (e.g., method, path pattern, etc) fail. While this feature adds flexibility, it poses a security risk: backtracking can span loaded rules across multiple rule sets. This means a specific rule in one rule set could unintentionally fall back to a less specific rule in another rule set, potentially one crafted maliciously to bypass security controls. For example, a legitimate rule set might define a strict rule for /api/*, but backtracking, if not specified carefully, could trigger a permissive catch-all rule (e.g., /**) in a separate, untrusted rule set if conditions aren’t met.

This lack of scope control in backtracking could allow an attacker with access to rule set definitions to undermine intended policies, especially in environments where multiple teams or sources contribute rule sets.

Describe your idea

Heimdall’s backtracking control could be enhanced by limiting its scope to rules within the same rule set and adding explicit configuration options to enforce this securely. There are two options to be considered:

• Rule Set-Scoped Backtracking: Restrict backtracking to only consider less specific rules within the same rule set as the initially matched rule. An example would be: If a rule in RuleSet A (e.g. for a.example.com/api/*) fails its conditions, backtracking will only try less specific rules in RuleSet A (e.g., a.example.com/**), not rules in RuleSet B. With that in place, we could introduce a backtracking_enabled property on a rule set level. That could even make the global backtracking_enabled (default is currently false) obsolete.
• Enhanced Backtracking Configuration: Extend the backtracking_enabled flag with a scope limiter. Actually, instead of the backtracking_enabled flag, there would be a more complex property:

  backtracking:
     enabled: true  # Same as the currently existing flag
     scope: "rule_set"  # or "global" - new option defaulting to "rule_set" if not set
  

  global would allow the current behavior and rule_set would limit the backtracking only to rules in the same rule set.

Are there any workarounds or alternatives?

Disable backtracking globally and set backtracking_enabled: true on each rule in a rule set relying on backtracking. The least specific rule should not configure backtracking. This prevents fallback beyond the rule set scope but makes rule configurations more verbose, requiring manual repetition of the backtracking_enabled flag.

Until #2386 is implemented, neither the workaround described above nor the functionality outlined in the idea section will be effective for rules that primarily rely on host-based matching criteria.

Version

0.16.0

Additional Context

No response