Deep Link Security and Safe Redirects

What can go wrong

Android's security guidance describes the risk without hedging: poor validation lets attackers "gain access to privileged functions or data, potentially resulting in data breaches, privacy violations, and unauthorized actions." It names "host validation bypass, cross-app scripting, and remote code execution within the permissions context of the vulnerable application" as attacks that weak deep link handling can enable.

Gambling apps hold exactly what attackers want: accounts with balances, payment methods, identity documents and withdrawal settings. A deep link into any of those screens needs the same care as a form that changes them.

Stop other apps claiming your links

"By design, Android allows multiple apps to register intent filters for the same deep link URI." A custom scheme such as examplecasino:// can be registered by any app, so it proves nothing about who receives the link. Verified https links fix this on both platforms: Android routes App Links only to the app the domain trusts, and Apple says only the domain owner can store the association file that universal links rely on. Set them up with the Android App Links guide and the iOS guide, and keep custom schemes for internal use, if at all.

Validate every parameter

"All incoming data from deep links should be meticulously validated and sanitized by developers to prevent malicious code or values from being injected within the legitimate application." Android suggests "checking the value of any deep link parameter against a predefined allowlist of expected values." In practice:

• Accept only the parameters a screen needs, with fixed formats: an event ID is digits, a market code is one of a known list.
• Reject links with unexpected hosts, paths or parameters instead of guessing what they meant.
• Never load a URL from a link parameter into an in-app web view.
• Never let a link place a bet, make a deposit, change limits or start a withdrawal on its own. A link can open the screen; the person confirms the action.

Check state before you show data

"Apps should check other relevant internal states, such as authentication state, or authorization, before exposing sensitive information." Android's example checks that a level was completed before granting a reward, "and redirecting to the main screen if not." For a casino app, that means a link to the cashier or withdrawal screen checks for a current, authenticated session, and sends the person to sign in first if there is none. Safer gambling screens deserve the same rule: a link should never change a limit or end a self-exclusion without the person's explicit action.

Open redirects

The Open Worldwide Application Security Project (OWASP) cheat sheet explains that unvalidated redirects and forwards are possible "when a web application accepts untrusted input" that decides where a visitor is sent. Its advice, in order: "Simply avoid using redirects and forwards." If you must, "do not allow the URL as user input for the destination." Better still, "have the user provide short name, ID or token which is mapped server-side to a full target URL," and if external destinations are needed, "allow-list explicitly approved destinations using the parsed URL components."

Campaign links are where this goes wrong: a parameter such as ?next= or ?url= that takes any address turns your trusted domain into a launch pad for phishing. The route inspector flags parameters that carry a full address, and the note on routing and attribution explains how to keep tracking out of the link itself.

A short review list

1. All public links use verified https hosts.
2. Each deep link handler lists the parameters it accepts and rejects the rest.
3. Account, cashier and limit screens re-check sign-in state.
4. No handler or server route forwards to an address taken from the link.
5. Web views load only your own pages.