Custom URL schemes are not an identity boundary on Apple platforms

Custom URL schemes make it easy to send a user from a link into an app. Apple supports them, documents how to register them, and explains how the app receives the URL. The same documentation carries a warning that matters for security reviews: a URL scheme is a potential attack vector, and another app can register the same scheme.

A scheme names a route, not a trusted sender

An app registers a scheme in its URL Types configuration. When another app or a link tries to open that scheme, the system launches or foregrounds the handler and delivers the URL. The scheme tells the operating system which kind of route the sender wants. It does not establish that the sender is the service the user intended.

Apple's documentation says a reverse-DNS identifier is a best practice, but it does not prevent another app from registering the same scheme. If multiple apps support one scheme, the app the system targets is undefined. The documentation recommends universal links when the link must be uniquely associated with a website.

A universal link is not automatically safe, which is why Apple also tells developers to validate all URL parameters. It has a stronger identity relationship with a website, but the handler still receives untrusted input. The important point is not that one mechanism is perfect. The point is that scheme registration alone cannot prove sender identity or authorize a sensitive action.

Treat every parameter as hostile input

The app should parse the URL with structured APIs, reject malformed components, and validate every parameter against a small action model. A parameter that names a document, account, or device should be resolved against the app's own authorization data. It should not be used directly as a file path, database query, or network destination.

Do not expose destructive actions through a URL that another app can invoke without confirmation. Apple's guidance explicitly recommends limiting actions that risk user data. Opening a public view is different from deleting a collection, changing an account setting, or sending a message.

Use an allowlist of supported hosts, paths, and schemes where the URL format permits it. Reject unexpected query keys rather than ignoring them. If the URL contains a callback or return address, verify that the destination is allowed. A handler that forwards the entire URL to another component can turn a narrow deep link into a broad internal command.

Keep session authority out of the URL

Do not put a bearer token, password, or long-lived secret in a custom URL. URLs appear in logs, browser history, clipboard contents, and screenshots. They may also be passed between apps that the developer does not control.

If the workflow needs to resume an authenticated session, use a short-lived, single-use code and exchange it through a channel with a defined trust relationship. Bind the code to the user, the transaction, and the intended handler. Validate it on the server and consume it once.

Avoid using the scheme as proof of identity for an account-recovery flow. An attacker who can register or invoke the scheme can send input to the handler. The app must still authenticate the user and authorize the state change through its normal session model.

Test against a competing handler

Build a test app that registers the same scheme and sends representative links. Observe what the system does on each supported platform. Test a cold launch, a running app, a suspended app, a malformed link, an oversized parameter, and a link from an untrusted app.

Check the behavior of universal links separately. Verify the associated domain file, entitlement, path matching, and fallback behavior. Do not assume that an installed app will handle a universal link when the association is stale or the link is opened from a context the system treats differently.

Log the receiving entry point, the parsed action, and the authorization decision. Do not log the full URL if it may contain a sensitive value. A simple event such as "rejected unknown action" is more useful than a record that copies a secret into the support system.

Use the scheme as a convenience layer

Custom URL schemes are suitable for launching a known view or passing a small, validated intent. They are not a secure channel for credentials, a proof of sender identity, or a way to bypass an in-app confirmation.

Use universal links when the association with a website matters. Validate the URL structure and every parameter. Resolve resources through the app's authorization layer. Keep sensitive actions behind a user decision that cannot be triggered by a link alone.

The handler is an input boundary. Treating it that way produces simpler code and a clearer security story than debating which app "owns" a globally registered scheme.

References

• Apple Developer Documentation, Defining a custom URL scheme for your app
• Apple Developer Documentation, Allowing apps and websites to link to your content
• Apple Developer Documentation, Supporting universal links in your app