My question is specifically about an option in Google Chrome under Settings > Site Settings > Handlers. I've read in the past that with desktop-based protocol handlers--such as Office Outlook or Thunderbird with mailto: links--an attacker could use a script to compromise Outlook, but can the same thing be said about web-based protocol handlers, such as Gmail? What about webcal: links and other protocols?

I'm trying to figure out if I should completely disable the option in Chrome for sites to ask me if they want to become protocol handlers, or if I should leave the setting alone.

1 Answer 1


Maybe. It's not any more dangerous than any Cross Site Scripting vulnerability that could already exist in the web-based software that the browser launches.

One distinction should be understood between command injection and argument injection.

Command Injection

In the desktop protocol handler context, command injection happens when the protocol handler is launched in a way that allows additional (and unexpected) applications to be launched in some piggybacked fashion.

Pseudo example: path/to/executable --argument1"; also-run-this-unexpected-application"

It is the duty of the browser (and perhaps to some degree the OS) to safeguard against this type of attack. The registered protocol handler at path/to/executable isn't even able to prevent this from happening. A smart browser would typically use some underlying OS call that is bound to a single executable so that no type of malfeasance can ever call more than one underlying application. This means that anything in the command that comes after the protocol handler is always passed as argument(s). For this reason, most modern browsers are immune to this type of vulnerability in the context of desktop protocol handlers. Historically though, there have been browsers that were easily exploitable and would run a series of commands piggybacked onto a protocol handler.

This is just speculation, but I find it highly unlikely that any type of command injection is possible via web protocol handlers. This is especially so because the browser isn't even launching a third-party process - it only ever launches it's own process (a new tab).

Argument Injection

Argument injection happens when unexpected arguments are passed to the protocol handler. In the context of desktop protocol handlers, this can still be dangerous, as it could cause the protocol handler to behave in ways that are unintended by the application developers. For instance, one protocol handler application that was created using the QTWebEngine was exploitable because one of its command line arguments allowed you to specify the path to load its DLLs from, and that path could include a remote location (https://zero.lol/2019-05-22-fun-with-uri-handlers/).

Concerning web-based protocol handlers - this type of argument injection is not going to lead to any unexpected software being run on your machine. At worst, it could allow Cross Site Scripting, but that could already be present in those applications via plain old URLs.

In summary: Protocol handlers that lead to launching a web-based application are highly unlikely to be exploitable in such a way as to compromise the machine that they are used on. They could still be used to make the underlying web application (e.g. Gmail) behave in a way that is against your expectations (e.g. Sending SPAM to everyone in your contacts list), but only if the web application is written to allow these types of destructive behaviors to be done via URL arguments - and this is also highly unlikely.

Ultimately, this is up to each web-based application to safeguard against. If your bank's website registers a protocol handler that allows funds to be transferred via a single URL, expect it to be exploited. In a real-world scenario though, I would only be as concerned with allowing these types of protocol handlers to operate as I would allowing a given service provider access to my data that their service operates on (Do you trust that Gmail is safe to access all of your mail and to operate with the ability to control correspondence to and from your identity/email address? Do you trust your calendar app to host all of your scheduling information?)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .