Linter rule to avoid calling RegExp constructor

[anonrig]

new RegExp should be avoided unless you know what you are doing, since it might cause really serious security vulnerabilities.

Example Eslint implementation: getsentry/sentry-javascript#10009

[ematipico]

I read the PR, and still, I can't understand the security implications. Especially in new RegEx VS /something/ when we both have "user's inputs".

I am not discouraging the proposal, but we should understand the implications and provide good documentation to explain to the users why this rule exists.

[Conaclos]

Same here. This could be nice to have some pointer.

Using dynamic regex construction has certainly some performance cost. Thus, this could be a performance rule. Otherwise we could introduce a new group named retsriction (Similarly to the Clippy restriction group: code that is not "bad", but may be useful to prevent)

[anonrig]

Let me try to explain it:

With new RegEx() you can create a dynamic regexp from a variable, such as new RegExp('/${name}/'), but with /hello/ you can't. This simple fact is important since, we warn the developer and discourage them from using the constructor unless they know what they are doing.

[Conaclos]

So, no security risk?

[anonrig]

So, no security risk?

The risk is the possibility of adding unsanitized user input into the arguments of RegExp