feat: Introduce a separate parsing_method rule

[rpl]

This PR move shared bits of the method rule into a base_method.js module and then reuse the helper function exported by that method to create two separate method and parsing_method rules.

The purpose of splitting the method rule into two separate rules is to report violations detected by the parsing_method rule as warnings instead of errors by default, and allow developers to opt-in/opt-out on parsing methods violations separately from the method rule.

[mozfreddyb]

Right. This would help with #81, which is a long-standing issue for some users.

[Rob--W]

Is the purpose of this to add validation of Document.parseHTMLUnsafe?

Don't forget to also add support for setHTMLUnsafe: https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTMLUnsafe

[rpl]

Is the purpose of this to add validation of Document.parseHTMLUnsafe?

Don't forget to also add support for setHTMLUnsafe: https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTMLUnsafe

@Rob--W That is already covered by the 'method' rule, see

eslint-plugin-no-unsanitized/lib/rules/method.js

Line 43 in 7835bfd

setHTMLUnsafe: {

[rpl]

@mozfreddyb I opened up this PR for a review pass on your side (in the meantime I applied the fixes for the typos in the markdown file, fixed the recommended config, and the README.md file which had a syntax error, and added a base integration test executed by the github workflow, which would have caught the issue with the typo in the severity level of the new rule in the previous version of this PR).

[mozfreddyb]

Looks great. Just a few things missing :)

[mozfreddyb]

I wonder if it could be cool to call them "Potentially unsafe call" or even more concrete "Parsing can be unsafe when....? 🤔

[rpl]

That feels like a good point to be too, let me take a look to what additional change may be needed in this PR if we would like to use slightly different message for the separate parsing_method rule.

[rpl]

@mozfreddyb I have included in afe2df6 one possible approach to customize the message (for now I went for the simpler "Potentially unsafe call..." one, but if the approach looks reasonable we can tweak the message further).

I have also changed the objectMatches for the DOMParser parseFromString method to 'parser' for now.

I was actually tempted to go even for just 'parse' or 'pars' (so that it would also match other variations, like 'htmlParsing' or 'parseHTML' or 'parseUtils'), wdyt?

[mozfreddyb]

Almost ready to go :) Thank you, Luca!

[mozfreddyb]

What would a sanitized version of this look like?

parseHTMLUnsafe(sanitize(badness)) or would sanitizeDocument(parseHTMLUnsafe(badness)) be more likely? I am leaning to (1) and would like to suggest to add a simplified test case here

[mozfreddyb]

Suggested change

	The _parsing_method_ rule in _eslint-plugin-no-unsanitized_ performs basic security
	checks for function calls that parse strings into new Document or DocumentFragment
	instances. The idea of these checks is to allow developers to opt-in/opt-out of detecting
	use of these methods, separately from the `method` rule which is reporting violation
	as errors by default.
	The _parsing_method_ rule in _eslint-plugin-no-unsanitized_ performs basic security
	checks for function calls that parse strings into new Document or DocumentFragment
	instances. It is close to impossible to automatically check whether the resulting
	Document is actually used insecurely, so this offers a control at the parse step.
	Therefore, these checks allow developers to opt-in/opt-out of detecting
	use of these methods, separately from the `method` and `property` rule which is
	reporting violation as errors by default.