A regex can look harmless in code review and still lock up a page when someone pastes the wrong input.
Most of us learn regular expressions as a compact way to validate a field, find a log line, or clean up text. The trouble starts when a pattern gives the engine many ways to interpret the same characters. If the match finally fails near the end of a long string, a backtracking engine may retry a huge number of possibilities before it gives up.
OWASP calls this Regular Expression Denial of Service, or ReDoS. The risk is not limited to servers. A bad pattern can block a browser tab, slow a worker, or tie up an API process if untrusted input reaches it. OWASP's ReDoS overview includes examples of patterns that grow dramatically slower on carefully chosen non-matching input.
It accepts one or more a characters. The nested + quantifiers create the problem.
The final ! prevents a match. Before the engine can return false, it may try many ways to divide the preceding a characters across the inner and outer repetitions.
The issue is not that + is always dangerous. The issue is ambiguity. If two repeated parts can consume the same characters, the engine has multiple routes to explore when the match fails.
OWASP lists nested repetition and overlapping alternatives as common warning signs:
A warning is not a proof that a regex is exploitable. It is a signal to test the pattern with realistic and hostile inputs before it reaches production.
JavaScript regular expressions run synchronously when you call methods such as test, exec, match, or replace. If a costly match runs on the main thread, the UI cannot repaint or respond to input until that work finishes.
A test tool should isolate this work where possible. A Web Worker can run the regex outside the page's main UI thread. If the test does not finish within a bounded time, the page can terminate that worker and show a useful error instead of waiting forever.
That protects the testing page. It does not prove the regex is safe in your application.
A Node.js process, a Java service, a Python worker, and a browser tab may use different engines, time limits, input limits, and resource controls. Test the pattern where it will actually run.
This says: Match one word. Then match zero or more occurrences of one or more spaces followed by another word.
The second version also makes the intended rule easier to explain in a code review.
Other practical safeguards help: Put a maximum length on input before matching it. Prefer fixed, reviewed patterns over patterns assembled from user input. Test inputs that almost match but fail near the end. Avoid nested unbounded quantifiers when the repeated parts overlap. Apply server-side limits too. Client-side validation does not protect an API.
The JavaScript RegExp API is flexible, especially when patterns are built dynamically with the RegExp() constructor. That flexibility deserves care when either the pattern or the text comes from an untrusted source. MDN's RegExp reference documents the API and its constructor behavior.
For a log parser, test long lines with one bad suffix. For a URL validator, test long repeated fragments and malformed delimiters. The inputs that fail late are often more informative than the inputs that pass immediately.
I built the ToolExo Regex Tester to run JavaScript regex evaluations in a disposable Web Worker. The tool terminates work that exceeds 500 milliseconds and flags a few risky shapes, such as nested repetition and repeated alternatives with overlapping branches.