If I understand processSrcMember correctly, it's trying to resolve URLs with the given string and the baseURL to identify incorrect images.
Despite URL parsing, I suggest also ensuring that the URL protocol matches a set of known meaningful protocols (https, data:, etc.).

This would also help devtools appsec, so it won't end up using URLs that end up pointing into chrome:, resource:, view-source:, file: and what not.

That seems reasonable. Do we have a concrete list of protocols to whitelist?

Frederik mentioned in our meeting before whitelisting following protocols would make sense:

• http
• https
• data
• file

Ok, will start with those. file:// is a bit scary. DevTools has ways of preventing it from poking around the user’s hard drive, right? Or does it work if the page’s protocol is also file://?

I would only allow file if the document is also on file. (Alternatively, you could only allow file if the manifest is on file but then you also need to make sure that you only allow the manifest on file if the document is on file :-))

I should probably note that we just aligned our behavior such that all file: resources are considered cross-origin with each other (regardless of the directory) in bug 1558299. This also resolves this long-standing spec issue https://github.com/whatwg/html/issues/3099 and aligns us with other browsers. So maybe we can stop supporting the file use case and encourage developers to run a local server instead?

(In reply to Frederik Braun [:freddyb] (PTO until July 29th) from comment #5)

I should probably note that we just aligned our behavior such that all file: resources are considered cross-origin with each other (regardless of the directory) in bug 1558299.

Sorry this should be bug 1500453 instead.