AI-Generated Regex Safety Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits a regular expression. The goal is to stop a generated pattern from shipping a denial-of-service risk or a silently wrong match just because it looks correct and passes a couple of happy-path examples.

This is a review policy, not a regex tutorial. It tells reviewers what must be true about a generated pattern's input exposure, backtracking behavior, and correctness before the change is safe to merge.

Review Inputs

Collect enough context to know where the pattern runs and what it sees.

1. Execution point. Whether the regex runs on request input, file content, log lines, configuration, or trusted internal strings.
2. Input source and size. Whether the input is user-controlled or network facing and whether its length is bounded before matching.
3. Engine and flags. The language and regex engine, since backtracking behavior, supported features, and timeout support differ between them.
4. Intended match. The exact set the pattern should accept and reject, including boundary and malformed cases.
5. Failure handling. What happens on no match, partial match, or a slow match, and whether a timeout or length cap protects the caller.

If the change cannot say where the pattern runs and how large its input can be, require that context before judging the pattern body.

Catastrophic Backtracking Rules

• Reject nested quantifiers over the same or overlapping input, such as (a+)+, (a*)*, (.*)*, or (\d+)+, on anything untrusted.
• Reject overlapping alternations under a quantifier, such as (a|a)* or (\w|\d)*, where the engine can match the same text many ways.
• Watch for a quantified group followed by a required character that the input can fail to provide, which forces exhaustive backtracking on near-matches.
• Prefer specific character classes over broad . spans so the engine cannot explore large numbers of partitions of the input.
• When a pattern looks ambiguous, test it against a long string of the worst-case character in a sandbox before trusting it.

A pattern is dangerous when the engine can match the same input in exponentially many ways. Backtracking engines then explore those ways on a non-matching tail, and matching time explodes with input length.

Input Bound And Engine Rules

• Bound input length before matching untrusted data so a single request cannot feed an unbounded string to the engine.
• Prefer a linear-time engine, such as an RE2-style automaton, when the input is untrusted and the platform offers one.
• Use an execution timeout or a worker boundary where the engine or runtime supports it, so a slow match cannot pin the main thread indefinitely.
• For complex or structured input, prefer a real parser over an ever-growing regex; some grammars are not safely expressible as one pattern.
• Compile patterns once and reuse them, but never trade safety for the micro-optimization of a riskier pattern.

Correctness And Escaping Rules

• Verify anchoring; an unanchored validation regex can accept input that merely contains a valid substring rather than matching the whole value.
• Escape literal metacharacters, especially dots in hostnames, slashes in paths, and characters inside dynamically built patterns.
• Never build a pattern by concatenating untrusted input without escaping it, which is a regex-injection and correctness risk.
• Confirm character classes, ranges, Unicode handling, and flags such as case-insensitive, multiline, and dotall match the stated intent.
• Treat a regex used for security decisions, such as allowlists or redaction, as high risk and require explicit accept and reject test cases.

Merge Blockers

Block merge until resolved when:

• a generated pattern has nested or overlapping quantifiers and runs on untrusted input without a length bound or safe engine;
• untrusted input reaches the regex with no length cap, timeout, or worker isolation;
• a validation pattern is unanchored or under-escaped so it accepts more than the intended set;
• a pattern is built by concatenating unescaped untrusted input;
• a security-relevant allowlist, redaction, or routing regex ships without accept and reject test cases;
• test evidence contains real secrets, credentials, or personal data instead of synthetic samples.

Review Checklist

• {"task": "Exposure mapped", "description": "The review identifies where the regex runs and whether its input is untrusted"}
• {"task": "No catastrophic backtracking", "description": "Nested or overlapping quantifiers on untrusted input are removed or proven safe"}
• {"task": "Input bounded", "description": "Untrusted input has a length cap, timeout, or safe linear-time engine"}
• {"task": "Correct and anchored", "description": "Anchoring, escaping, character classes, and flags match the intended set"}
• {"task": "Tested adversarially", "description": "Valid, invalid, boundary, and worst-case inputs are exercised"}
• {"task": "Privacy safe", "description": "Test strings and captured groups avoid real secrets and personal data"}

AI Review Rules

AI assistants can write and review regex, but they should show their evidence.

• Ask the assistant to state where the pattern runs and whether input is untrusted before judging the pattern.
• Require the assistant to call out nested quantifiers and broad .* spans explicitly rather than only confirming the happy path.
• Have the assistant provide accept, reject, and worst-case test strings, not just one example that matches.
• Do not let the assistant claim a pattern is ReDoS-safe from inspection alone when a sandbox timing test is feasible.
• Re-run review after any edit to quantifiers, alternations, anchors, or flags.

Troubleshooting

• The pattern hangs on some inputs: look for nested or overlapping quantifiers, add a length bound, and consider a linear-time engine.
• Validation accepts bad values: add ^ and $ anchors and tighten character classes so the whole value must match.
• A hostname or path regex over-matches: escape literal dots and slashes and avoid broad . where a specific class is meant.
• The regex breaks on Unicode input: confirm the engine's Unicode mode and use explicit Unicode-aware classes or flags.
• Test data leaked a secret: replace it with synthetic samples and scrub the public artifact.

Duplicate And History Check

Checked existing rules, hooks, statuslines, guides, collections, skills, open PRs, and closed PRs for regular expression safety, ReDoS, catastrophic backtracking, input validation, and AI-generated code review.

Adjacent content includes general security-audit and code-review rules and input-validation guidance, but no entry is a portable pre-merge review policy specifically for AI-generated regular expressions. This entry is distinct because it decides what must be true about a generated pattern's input exposure, backtracking behavior, anchoring, and test evidence before it can merge.

No prior closed PR for this rule was found during the duplicate/history check.

Backtracking Reference

The patterns below are common catastrophic-backtracking shapes that AI assistants produce. Each can match the same prefix in many ways, so a backtracking engine explores those ways on a non-matching tail and matching time grows sharply with input length.

A linear-time engine evaluates these in time proportional to the input length because it does not backtrack. When the platform exposes one, prefer it for untrusted input, and otherwise bound the input and add a timeout.

Sources

• OWASP Regular expression Denial of Service (ReDoS): https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
• MDN regular expressions guide: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions
• Google RE2 — why RE2: https://github.com/google/re2/wiki/WhyRE2
• Python re module documentation: https://docs.python.org/3/library/re.html
• CWE-1333 inefficient regular expression complexity: https://cwe.mitre.org/data/definitions/1333.html
• Node.js timers (timeout/worker boundaries): https://nodejs.org/api/timers.html