Great post on URL scheme security by Guillaume Ross:

URL schemes will become more popular as developers try to get applications to communicate and enable great workflows. Some were expecting new official methods of app communication in iOS 7, which this has not materialized. Because of that, URL schemes are currently the only practical way for inter-app communications on iOS. As these schemes become more popular, it is important for developers to remember that input from URL schemes could be malicious. Developers should ensure that any action with the potential to damage data, threaten privacy or reveal confidential information should be confirmed by the user before being performed.

As a creator and advocate of x-callback-URL, security implications have been something I’ve thought about and tried to draw attention to in talks I’ve done on the topic. In the zeal to encourage adoption I may not have done a good job of reminding other developers to keep security in mind planning their URL schemes.

When I chose to expose Drafts actions to automation via URL schemes, I was concerned about the implications. It seems a good time to shine a light on how I addressed security in Drafts URL schemes. Details are also available on our developer page.

Drafts exposes one x-callback-URL action, “create”, which as the name implies can create a new draft with text sent to the app. This action itself I do not consider a security risk, and it is available to call by default when the app is installed. It is possible an errant URL could create a draft you did not intend to have in the app, but it can not delete or replace any text you created – and thus does not require user confirmation.

Additional parameters to the “create” URL allow you to specify an action to be performed on the draft after it is created. Since Drafts actions can post to social media, write to your Dropbox/Evernote, etc., it is dangerous to expose them and this functionality is disabled by default. You have to opt-in by enabling the “Allow URLs to trigger actions?” setting to use it, and I expect many users never do and should not be considered at risk.

In addition to this setting, Drafts also can require a “URL key” to perform actions. Drafts generates one for you, or you can edit the value, and if you set the “Require key parameter” setting to ON, Drafts will also check for the presence of a “key” parameter in an incoming URL and only allow it to fire actions if it matches the key in settings. Think of this as a password for URLs.

If you use Drafts automation features and are concerned about the security implications, I highly recommend you enable the URL key setting. As with most security measures, the downside of this setting is convenience. You will have edit custom actions you download to include this “key=[your key]” parameter for them to work. Note that since the value is editable, if you use Drafts on multiple devices you can set the value to match on all your devices to more easily share actions.

If anyone sees holes in Drafts security, please draw them to my attention and I’ll consider adding additional levels of protection.