Deep links let a tap open your app at the right screen, but how they are implemented makes a real security difference. The old way, custom URL schemes like myapp://, has a flaw: any app can register the same scheme, so a malicious app can claim your links and intercept them. Universal Links fix this by using ordinary HTTPS URLs tied to a domain you have proven you own, so only your app can handle them. That ownership is the security advantage. But a Universal Link is still just a URL anyone can craft, so the link's contents remain untrusted input. Here is how Universal Links work and how to use them securely.
Short answer
Universal Links are iOS's secure deep-linking mechanism: a standard HTTPS URL that opens your app if it is installed, or your website if not, with the association proven by an apple-app-site-association (AASA) file you host on your domain and an Associated Domains entitlement in your app. Per Apple, because the link is bound to a domain you control, another app cannot claim your HTTPS links, which is the key advantage over custom URL schemes that any app can register and hijack. The security caveats are that a Universal Link is still a URL anyone can craft, so treat its contents as untrusted input, and never perform a sensitive action from a deep link alone without proper authentication. Prefer Universal Links over custom schemes, and validate what arrives.
What you should know
- Universal Links use HTTPS URLs: opening the app or falling back to the website.
- They are tied to a domain you own: proven by the AASA file and entitlement.
- Other apps cannot claim them: unlike custom URL schemes, which any app can register.
- The link is still untrusted input: anyone can craft the URL.
- Do not authenticate by deep link alone: a link is not proof of identity.
What are Universal Links?
They are a deep-linking mechanism that uses your real web URLs to open your app. When you set up Universal Links, you host an apple-app-site-association file on your domain that lists which paths map to your app, and you declare the domain in your app's Associated Domains entitlement with the applinks service. iOS checks this association, so when a user opens one of your HTTPS URLs, the system launches your app to handle it if installed, and otherwise the URL just opens in the browser as a normal web page. The crucial property is that the association is verified against a domain you control: because you host the AASA file and declare the entitlement, iOS trusts that your app is authorized to handle that domain's links, and no other app can register to handle them. This is what distinguishes Universal Links from custom URL schemes, which are not tied to any verified ownership, and it is why Universal Links are the recommended way to deep link on iOS.
How do Universal Links compare to custom URL schemes?
On ownership and hijack resistance, decisively. The table contrasts them.
| Aspect | Custom URL scheme | Universal Link |
|---|---|---|
| Link form | myapp:// custom scheme | Standard HTTPS URL |
| Ownership | None; any app can register the scheme | Bound to a domain you control |
| Hijack risk | Another app can claim the scheme | Other apps cannot claim your links |
| Fallback | None if app not installed | Opens the website |
| Recommendation | Legacy; avoid for sensitive flows | Preferred mechanism |
The defining difference is that custom URL schemes have no concept of ownership: any app on the device can declare it handles myapp://, so a malicious app can register your scheme and intercept links meant for you, which is a real risk for anything sensitive passed through a scheme link. Universal Links remove that ambiguity by binding the link to a domain you have proven you own through the AASA file and entitlement, so the system will not let another app claim your HTTPS links, and as a bonus the same URL gracefully opens your website when the app is not installed. For these reasons Universal Links are the preferred mechanism, and custom schemes are best treated as legacy, avoided for anything that carries sensitive data or triggers sensitive actions.
How do you use Universal Links securely?
Adopt them over custom schemes, and treat the incoming link as untrusted. Use Universal Links for your deep links, especially any that matter for security, so that your links cannot be hijacked by another app the way a custom scheme can. Host your AASA file correctly over HTTPS and keep the path mappings accurate, since the association depends on it. Then handle the security of the link's contents in your app: a Universal Link is still just a URL, and anyone can construct one with any path and parameters, so parse and validate everything it carries as untrusted input rather than trusting it, guarding against injection or unexpected values the way you would any external data. Most importantly, do not treat the act of opening a link as authentication or authorization: a deep link arriving does not prove who sent it, so a link should never directly perform a sensitive action or grant access without the user being properly authenticated and the action authorized server-side. The principle is that Universal Links give you a trustworthy delivery channel that resists hijacking, while the data they deliver still has to be validated and never mistaken for proof of identity.
What to watch out for
The first trap is using custom URL schemes for sensitive deep links, where another app can register the same scheme and intercept them; prefer Universal Links. The second is trusting the contents of a deep link, when the URL is attacker-craftable input that needs validation. The third is performing a sensitive action straight from a link, treating the link as authentication; require real auth and server-side authorization. Deep-link handling is code you write, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled IPA against OWASP MASVS, surfaces your URL handling and associated-domains configuration as part of the platform-interaction surface, while validating link contents is yours to implement.
What to take away
- Universal Links are iOS's secure deep-linking mechanism: HTTPS URLs bound to a domain you own via the AASA file and Associated Domains entitlement, so other apps cannot claim them.
- That ownership is the advantage over custom URL schemes, which any app can register and hijack, making schemes a poor choice for sensitive deep links.
- Use Universal Links over custom schemes, host the AASA file correctly, treat the link's contents as untrusted input, and never authenticate or authorize a sensitive action from a deep link alone.
- Use a pre-submission scan such as PTKD.com to surface your URL handling and associated-domains configuration, then validate link contents in your code.
