Bug 204558 – Expose public API for registering URL schemes as secure and as bypassing content security policy

• Status: NEW
• Component: WebKit2

[Ken Case]

While trying to implement password autofill in OmniWeb, I registered a WKUserScript which catches events on password fields. I first tried implementing a WKScriptMessageHandler to look up password entries and return them to the app, but that approach was blocked by CORS because the message handler could only return results in the context of the main frame (see bug 204557).

So my next approach was to try inserting a <script> tag into the DOM, with its `src` set to a custom URL scheme which would retrieve the appropriate keychain entries for the current site and return results to my password-filling function.

Unfortunately, this approach only works on insecure websites (which aren't great places to be entering passwords anyway). On secure websites, the <script> is blocked from loading content with the message:

> [blocked] The page at [website] was not allowed to run insecure content from omniweb:///get-password.

It would be great to have some public API which I could use to indicate that a custom URL scheme (or specific content provided by that scheme) is secure. It looks like a similar request was marked fixed back in 2010 (in bug 47557) with the introduction of the WKContextRegisterURLSchemeAsSecure() API. It would be great to have some equivalent public API in the WebKit framework.

But I'm not sure that will be enough by itself: even with the scheme marked secure, that content might get blocked by CORS. It would be great to enable custom URL schemes to bypass content security policies altogether. This was implemented (and justified by the spec) in bug 89373 (and later bug 140736) as WKContextRegisterURLSchemeAsBypassingContentSecurityPolicy(). It would be great to have some equivalent public API exposed in the Objective C WebKit framework API.

(As always, thanks for considering this! I don't have strong opinions about how this should be implemented, though I can certainly offer some suggestions if that would be helpful: I could imagine some optional methods on the WKURLSchemeHandler protocol, or some optional additional parameters on -setURLSchemeHandler:forURLScheme:, or some new methods which forward along to the existing SPI.)

[Radar WebKit Bug Importer]

<rdar://problem/57461912>

[[e-mail]]

This (accessing a custom URL scheme handler in HTML loaded into WKWebView via https) has become a significant hurdle for our application as well. We were dismayed to find that no existing API could influence WebKit's decision to block the load: CORS headers, Content-Security-Policy, "Allow Arbitrary Loads in Web Content" NSAppTransportSecurity setting, adding a content blocker rule to WKWebViewConfiguration's WKUserContentController upgrading the custom url scheme to https via "make-https". The custom URL scheme handler is installed in the app only and means nothing outside, cannot be accessed from, anything on the Internet, so we should be able to treat it as secure, at least in some limited fashion.

This was discussed with Apple Developer Technical Support in case #749750395, they reached the same conclusion as we did, that there is simply no workaround.

Like the original poster, we would be open to *any* method of permitting loads from HTTPS origins to custom URL scheme handlers in WKWebViews. Thank you for your attention!

[[e-mail]]

Created attachment 413339 [details]
Test case

This test case illustrates the inability of an application to access a custom URI scheme handler from within content hosted via https. See the three cases in ViewController.swift L56-L68, illustrating loading the HTML from file:, http:, and https:.

[Kurt Revis]

Seconding that this still appears to be a problem (as of 2022 and iOS 16) and would still be useful. 

A custom URL scheme would be a great way to quickly transfer data between an app and a WKWebView inside of it, without the overhead of serializing to a JS string. But since it's unusable in HTTPS pages, that's a dealbreaker.

(Using the private method `-[WKProcessPool _registerURLSchemeAsSecure:]` works fine, but of course we can't ship that.)