change(phishing-controller): validate hostname is provided to phishing-controller test
and bypass
methods
#4223
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
This pull requests introduces validation to the phishing-controller
test
andbypass
methods to ensure that the value being provided is a hostname. The way the code is currently written suggests to the consumer that an origin should be provided.However, this is problematic given that our phishing list contains hostnames not domains (see here). This can also be validated checking our API endpoint.
While we currently do not pass in an origin to either of these functions, the impact of doing so would result in our phishing detection mechanisms failing. This is because
https://evil.com
would not match withevil.com
/In order to minimize the potential for an origin to be passed in, this PR adds validation to better catch implementation errors during development cycles. It does so by raising an error.
Reasons not to make this change
I had debated whether this change would have fit better in the
eth-phishing-detect
detector itself. However, I decided on implementing it here as its the place that developers will most likely be looking to for guidance on how to best implement their integrations with the phishing controller.This does have tradeoffs, as now the controller is opinionated about the type of input provided. This may or may not be desired and is open to discussion.
In addition, we may prefer to accept full URL's and have the phishing controller do the parsing itself to minimize the burden on external consumers.
References
Changelog
@metamask/phishing-controller
#test
and#bypass
raise an error if input other than a hostname is provided tonew URL("...").hostname
or other mechanisms to pass the hostname instead of the full origin to the phishing controller functions.PhishingController:testOrigin
toPhishingController:testPhishing
Checklist