Add a rule to flag crypto.randomUUID() usage in typescript/javascript

Clean Code New rules / language support
, ,
1

Could I recommend a rule is added for typescript/javascript linting that flags the usage of crypto.randomUUID()? That function will work on https and localhost connections but will fail on http connections. This can make it easy to get through dev (usually using localhost) but then fail instantly in a higher environment.

3

Hi @RichardC243,

thank you for the suggestion.

Can you develop the idea further, please? As far as I know, that function can be called from any environment, even the backend, and does not relate to http/https or it’s specific to the frontend.

Cheers,
Victor

6

Hi Victor,

Yes, good point. The issue is specific to the frontend. window.crypto.randomUUID is only available in some contexts, based on this answer. This tripped us up recently on a frontend project. It took a while to find the source of the issue. I think this has happened to us before as well. So it would be good if we could just have a rule that will flag this to any developer trying to use it in future.

1 Like
7

Thanks for the clarification. I was not aware myself that it was not available on insecure contexts. I see in MDN that the same applies to other properties of the Crypto interface.

Not sure we are able to detect the context from a pure static analysis perspective, but I’ll discuss this internally with the team and let you know.

Thanks!
Victor

8

Thanks, Victor. Even a global on/off flag for this rule in our projects would allow us and others to catch this. It’s so easy to slip through code/qa reviews but we ideally never want someone using it in our frontend projects.

1 Like
9

Hi Richard,

Could you elaborate on which context you are using HTTP?

Most users running a public server would use HTTPS. Is your use case something else?

10

Hi Gabriel,

We have a few levels of environment internally. In our pipelines we can create a “topic” environment from any git branch. This can be used for testing, demos, troubleshooting: basically any time someone other than a dev wants to use software built form a git branch quickly. These use htttp connections. We developed an internal library for other teams and tested it on localhost and https contexts. But once we signed it off and gave it to other teams they found issues in their demos and testing.

11

Hi @RichardC243,

Sorry, but we decided not to go for such a rule. Reasons:

  • The use case is very limited.
  • Unable to easily detect HTTP context.
  • A rule that is just on/off does not fit the “Sonar way” quality profile (new rules should always be enabled).

Thank you anyway for the suggestion.

Victor

1 Like
13

Hi,

I wouldn’t agree the use case is limited. For users with on-premise customers they may hit this issue. Often they deploy software onto private networks that are tightly controlled and so don’t setup a https certificate.

I also don’t think the requirement to detect HTTP context needs to be a question for your team. I have seen rules like “make sure this static IP address is fine”. This feels like it could be another suggestion-type rule? Something like “only use the crypto global object for frontend code where it will only be used on localhost and https connections”. With it being a suggestion then the rule could be enabled for everyone?