Fix regex validator crash on invalid patterns in jquery.validate.unobtrusive.js

[ishaq2321]

Fixes #67028

Summary

The regex custom validator in jquery.validate.unobtrusive.js would throw a SyntaxError when new RegExp(params) encountered an invalid regex pattern (e.g., [, *, unbalanced parentheses). This caused all form validation on the page to crash.

Fix

Wrapped the new RegExp() call in a try-catch block. When an invalid pattern is encountered, validation is skipped (returns true) rather than crashing. Server-side validation at form submission time continues to serve as the fallback layer.

Changes

• src/Identity/UI/src/assets/V4/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.js: Added try-catch around new RegExp(params).exec(value)
• src/Identity/UI/src/assets/V4/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js: Equivalent minified fix

Finding Source

Found via bb_security static analysis tool during ASP.NET Core codebase review.

Co-authored-by: Muhammad Ishaq Khan muhammadishaqkhan.2321@gmail.com

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the unobtrusive jQuery Validation regex rule to avoid throwing runtime errors when an invalid regex pattern is provided, preventing client-side validation from crashing.

Changes:

• Wrapped new RegExp(params) usage in try/catch inside the regex validator method.
• Simplified the return condition to explicit null checks and boolean operators.
• Added comments explaining the fallback behavior when the regex pattern is invalid.

[dotnet-policy-service]

Thanks for your PR, @ishaq2321. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[ishaq2321]

@dotnet-policy-service agree

[ishaq2321]

Thank you for the review. We considered this carefully and believe returning true is the correct approach for this specific scenario:

1. The regex pattern originates from the server — it comes from the [RegularExpression] data annotation attribute, which is validated at compile/build time in ASP.NET Core. An invalid pattern would fail during app startup, not at runtime on the client.

2. In the edge case where a malformed pattern reaches the browser, returning false means all legitimate user input gets rejected — a worse UX than skipping client-side validation. The browser would show validation errors for every input, confusing users.

3. Server-side validation is the authoritative layer — The server re-validates at form submission time regardless of what the client does. Skipping client-side validation simply means the server becomes the single validation point for that specific field.

4. The original bug was catastrophic — Without this fix, a single malformed pattern crashed ALL validation for the entire form. This fix eliminates that crash while preserving the most important validation layer (server).