Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A slow regular expression can become a server-side denial-of-service risk when a backtracking engine explores a huge number of possible matches before rejecting an input. In a DEV Community post, Serguey Asael describes an email-validation regex that, according to his account, kept one worker busy for about 40 seconds when a roughly 50-character address-like input failed on its final character. The post does not include the expression or runtime, so that timing is an attributed account—not an independently reproducible benchmark. The underlying failure mode, known as regular expression denial of service (ReDoS), is documented by OWASP.
Why can a short regex take so long?
Pattern length does not determine matching cost. In a backtracking engine, a regex can allow the same input characters to be divided among repeated parts in many different ways. When the engine later encounters a mismatch, it may return to earlier choices and try alternatives. Nested repetition and overlapping alternatives can multiply those possibilities.
A near-match that fails late can be especially costly: the engine may have to exhaust many candidate paths before it can conclude that the entire string does not match. OWASP describes ReDoS as a denial-of-service attack that exploits regex implementations taking extremely long—potentially exponentially longer as input grows—to evaluate certain patterns and inputs.
What does the forty-second example establish?
In his DEV Community post, Shinder says an email-address validation regex with nested groups and repetition left one worker thread busy for 40 seconds on an input of about 50 characters that almost matched but failed at the end. He says a similar later request consumed another thread. The post does not provide the regex, input, language or runtime, server configuration, or timing method. Those details are necessary to reproduce the event or assess the precise cause, so the duration and incident setup should be understood as the author’s account rather than a verified production report.
#1 Best Overall
The general risk is well established, but that account’s exact performance cannot be inferred from OWASP’s illustrative example. For the example regex it discusses, OWASP shows 16 possible paths for aaaaX and 65,536 for aaaaaaaaaaaaaaaaX. Those are illustrative path counts for OWASP’s pattern, not measurements of Shinder’s email regex.
Which regex shapes deserve scrutiny?
OWASP flags repeated groups that themselves contain repetition, as well as repeated alternatives that can match overlapping text. Its examples include:
Rank #2
(a+)+$(a|aa)+$(a|a?)+$
These shapes are warning signs, not proof that every use is exploitable. Risk depends on the complete expression, the regex engine, and the input an attacker can supply. Review the expression as executed by the application, not just its appearance in isolation.
Recommended Free Tools
Can a regex block a server?
Yes. If matching runs synchronously on a request-handling thread, expensive regex work can prevent that thread from doing other work until matching completes. In Node.js, synchronous CPU-heavy regex evaluation can block the event loop, delaying unrelated requests. Node.js explicitly discusses vulnerable regular expressions as a ReDoS risk and cautions that “No regexp engine can guarantee evaluating these in linear time.” The warning reflects the fact that regex engines and supported features differ; changing engines is not automatically safe unless the required pattern features and runtime behavior are understood.
How to reduce the risk in server-side validation
- Use a purpose-built validator for common formats. For email addresses, prefer a well-tested validation library or established validation approach over a hand-built expression where practical. Node.js documentation also recommends using established modules for common formats.
- Remove ambiguous or nested repetition. Inspect repeated groups and alternatives that can consume the same characters in different ways. Simplify the pattern or make alternatives disjoint where the validation requirement permits.
- Bound input before matching. Enforce a sensible maximum length for untrusted input before passing it to a regex. A length cap limits the work an attacker can induce, though it does not make an unsafe pattern safe at every allowed length.
- Test adversarial near-matches. Include long inputs that resemble valid values but fail near the end. Run tests with the same engine and relevant configuration used in production, and monitor execution time as input length increases.
- Consider engine and interruption options deliberately. A linear-time engine may help if its supported syntax fits the use case. Verify feature compatibility before switching. Apply a time limit where the runtime supports one; there is no universal timeout API established across runtimes.
What a useful regression test should check
A test should not only confirm that valid and invalid examples produce the right answer. For a pattern that processes untrusted input, include late-failing near-matches at increasing lengths and run them through the production engine. The key signal is whether processing time rises sharply as the string grows. Keep such tests bounded so a test suite cannot itself hang, and treat any unexpectedly large increase as a reason to review the pattern, input limit, and execution model.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
