Android App Link Risks

Android App Links enable linking web content to mobile apps. The provided systems have been shown to have several issues, discovered by Tang et al. back in 2020, primarily link hijacking by three different means. Throughout the years there has been little information on the state of these issues, whether they were fixed and when. This post aims to provide information on exactly that.


On Android, the App Link system allows linking the content of websites to Android apps directly. Developers may define how a user can open certain websites within, say, an app that represents content on the web in a native mobile application.

Please note, there is a discrepancy between how the terms deep- and web link are defined in the context of Android compared to how they are used in the context of the world wide web.

=> Deep links

Example: exampleapp://content/12345

=> Web links

Example: http(s)://

=> Android App Links

Example: http(s):// Requirement: assetlinks.json must exists and be valid

Figure 1: Examples of links on Android

First, we’d like to introduce the concept of deep links. Unlike deep links pointing to specific content on the world wide web, deep links in the context of mobile apps are formed by creating a specific uniform resource identifier (URI) linking to content within an app.

Deep link example: exampleapp://content/12345

The scheme, following the definition of an URI, here “exampleapp”,  is used to denote the app to be opened on the mobile. Apps must be set up to handle given URIs of said scheme. On Android, developers must add an Intent filter [5] to their app’s manifest in order to handle deep links of a given scheme. It is important to note these may be defined using any scheme the developer chooses.

Web links consist of a typical uniform resource locator (URL). They feature either the HTTP or HTTPS scheme, followed by a host name, followed by a path. In the context of the world wide web these would usually be referred to as deep links but in the context of Android they are referred to as web links abiding by the Android documentation.

As URLs alone do not assert ownership of a host name, the Android App Link system has been established in order to allow the Android system to distinguish which apps may legitimately handle a given web link. A web link with appropriate proof of ownership is referred to as an Android App Link.

App Links are a specialized type of web links, which in turn are yet again a specialized form of deep links, as shown in Figure 1. Verification of an App Link is enabled by placing an assetlinks.json file on a publisher’s server to be available under the “.well-known” directory.

Example URL of an assetlinks.json file:

This file contains a package name and a SHA256 fingerprint of the app’s signing key, thereby allowing the Android system to verify if a given app is a valid target for opening a given App Link. Verification is performed by the Android system the first time a user attempts to open a link an app has registered. Without proof of ownership, the Android System will display a prompt, asking the user whether to open said link in a browser or in the given app. The autoVerify attribute allows skipping this prompt altogether if the Android system successfully verifies the mapping between the assetlinks.json and an installed app.


While the App Link system has been designed with security in mind, some issues have arisen over the years [1][2]. Most prominently, issues exist when redirecting from the browser to an associated app without said app being installed. The App Link system allows such links to be opened in a corresponding app without prior confirmation by the user, given a proper configuration. Under very specific circumstances, the invocation can be hijacked, redirecting the user to a malicious app (MA). In the following, three methods of invoking an App Link will be presented. These have been described in depth by Tang et al [1].

Setup and attacker model

The following issues were inspected on the five most recent versions of Android, as these cover most of the Android devices running today with a cumulative prevalence of 81,2% (Jan 6, 2023) [3]. Each release of a major Android version comes with a different number for its appropriate Android SDK API, referred to as the API Level.

Table 1 shows a mapping of Android releases and their corresponding API Level, as well as the codename of the respective release.

Table 1: Android Versions & Names
Android Version API Level Codename
Android 9 API 28 Pie
Android 10 API 29 Quince Tart
Android 11 API 30 Red Velvet Cake
Android 12 API 31 (and 32) Snow Cone (v2)
Android 13 API 33 Tiramisu

All issues were tested using the official Android Emulator provided by the Android SDK. The official system images, also provided by the Android SDK, were used, all of which included the Google Play store- and services.

It is assumed the attacker cannot modify the system, furthermore the attacker cannot install apps featuring a package ID present in the Play Store.

The attacker can, however, install a malicious app. The attacker can install updates to that app in order to add further Intent-filters for the purpose of hijacking App Links from host names outside the attacker’s control.

The malicious app features a valid configuration of App Links under a host name controlled by the attacker. Furthermore, the configuration of the malicious app has been validated by the Android system before an additional Intent-filter is added by an update for malicious purposes.

Link hijacking

All three attack vectors revolve around the hijacking of links. The only difference lies in how a given link is invoked.

Let’s assume the legitimate app for handling the given App Link is not installed, instead a malicious phishing app is installed instead. The malicious app (MA) has its own App Links registered under a host name the attacker controls. Android’s verification of the assetlinks.json file therefore correctly maps the attacker-controlled host name to the MA.

Link click hijacking

This attack vector is based on a user clicking on a link in either the browser or a messaging app or anywhere else a clickable link may be shown on Android in order to open the appropriate app. The user would assume either the browser to open said link or the legitimate app to be opened.

Given the malicious app has registered Intent-filters for the host name of said link, the user will be redirected to the malicious app instead. Also, since the malicious Intent-filters were delivered by an update and the malicious app features an App Link configuration of its own which has already been validated, no prompt will be shown. The user will be redirected to the malicious app without confirmation.

This has been observed on Android versions up to but not including 12, as shown in Table 2. Installing the legitimate app to handle a given App Link mitigates this issue entirely.

Table 2: Link click results
Android Version API Level Malicious redirection w/o legitimate target app installed Redirection w/ legitimate app installed
Android 9 API 28 Yes No
Android 10 API 29 Yes No
Android 11 API 30 Yes No
Android 12 API 31 (and 32) No No
Android 13 API 33 No No

Link hijacking with Smart Text Selection (STS)

The second attack vector involves Smart Text Selection (STS). It is a feature introduced in Android 10 (API 29). It allows a user to select text and have Android suggest actions on that selection. This could be websites, documents or anywhere selectable text is shown.

These suggestions, among others such as copy/paste, also present apps, should an App Link be selected.

With the same setup as before, should a malicious app register Intent-filters of the given host name, the user will be shown an option to open the selected link in the malicious app. Given the App Link configuration has been validated, once again no prompt will be shown to the user.

This behavior has been observed on both Android 10 and 11. Android 9 did not yet feature STS and is therefore unaffected, as shown in Table 3.

Table 3: STS Results
Android Version API Level Malicious redirection w/o valid target app installed Redirection w/ valid app installed
Android 9 API 28 No (no STS) No (no STS)
Android 10 API 29 Yes No
Android 11 API 30 Yes No
Android 12 API 31 (and 32) No No
Android 13 API 33 No No

As shown in column four of Table 3, installing the legitimate app mitigates the issue entirely.

Instant app redirection

The third attack vector features the use of Instant Apps. These are a novel method of distributing Android apps without explicitly installing them. They allow opening apps to be run partially by the Android OS without specifically having to install a full app.

This attack, as described by Tang et al. [1], redirects users to the malicious Instant App (MIA) by giving the MIA a package name ranking higher in the lexicographical order, outranking the legitimate target app. For example, the package name “” would rank higher than “com.example.legitimateapp”. Furthermore, the Android OS supposedly prefers Instant Apps over regular apps when determining an appropriate app to open a clicked link.

Similarly to the previous attack vectors, we were able to observe link hijacking only when the valid target app was not installed.

Installing the legitimate target app stopped link hijacking outright (see Table 4), regardless of running the malicious app as an Instant App with a shorter package name which supposedly was to outrank the legitimate, regularly installed app.

Also, unlike regular apps, initial successful verification of the App Link configuration does not have to occur.

Table 4: Instant App results
Android Version API Level Malicious redirection w/o valid target app installed Redirection w/ valid app installed (fully)
Android 9 API 28 Yes No
Android 10 API 29 Yes No
Android 11 API 30 Yes No
Android 12 API 31 (and 32) No No
Android 13 API 33 No No

Conclusion & mitigation efforts

A lot has changed since these issues were initially discovered. Android 12 saw the introduction of an overhauled verification process for App Links within the Android system which allows for a more finely grained verification of App Links on a per-host-name basis.

The described link hijacking with all three attack vectors no longer works from Android 12 and up as the new App Link verification to have entirely mitigated these. Developers should be aware of the current state, especially on older devices.

Since the described hijacking from all three attack vectors mentioned above is mitigated by having the user install the legitimate target app, the risk lies in using App Links before ensuring the legitimate app for handling these is installed.

We would like to focus on a specific scenario requiring mitigation. If a developer were to choose an App Link in order to open the legitimate app, it may be tempting to also create a website under said link, prompting the user to install the legitimate app. The expected behavior would be to redirect the user to the legitimate app if it is installed or have the user shown the website, prompting to install the app. That scenario is prone to link hijacking using all three of the attack vectors mentioned above, that is, given the user is running an affected Android version shown in Table 1-4.

There are two mitigation options for that scenario we will discuss in the following:

Use the »Get Installed Related Apps API«

Since all three attack vectors are mitigated by installing the legitimate app, App Links shouldn’t be used unless the install state of the legitimate app can be determined.

Developers may use the »Get Installed Related Apps API« [4] on their website to check if the legitimate app is installed before offering an App Link for the user to open. It’s imperative you don’t offer any App Links before you have verified the legitimate target app is installed.

Use of Android Intent Links

Intent links for redirecting a user to an app do not suffer from attacks based on registering App Links maliciously. The only way of intercepting these would be by having the user install a malicious app featuring the same package name as the valid app. This, however, is less likely, as it may be assumed most users only use the Play Store to install applications and does not allow duplications of package names.

This approach can be combined with the use of the »Get Installed Related Apps API« in order to determine whether your app is installed, or links pointing to the Play Store should be shown.

Further mitigation options

Our conclusion draws a very specific scenario of how existing issues with App Links may be exploited. Other options of mitigation have been suggested such as disabling STS, these are, however, out of scope of the affected scenario described in our conclusion, we would therefore like to limit the discussion to the mitigation options available.


[1] Yutian Tang, Yulei Sui, Haoyu Wang, Xiapu Luo, Hao Zhou, and Zhou Xu. 2020. All your app links are belong to us: understanding the threats of instant apps based attacks. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2020). Association for Computing Machinery, New York, NY, USA, 914–926. 

[2] Improving OAuth App-to-App Security, accessed 30.03.23,

[3] Android Studio: Android Platform/API Version Distribution, updated Jan 6, 2023, accessed Mar 30, 2023

[4] Get Installed Related Apps API, Draft Community Group Report, 8 March 2021, URL: accessed Mar 1, 2023

[5] Intents and Intent Filters, Android Documentation, updated Mar 29, 2023, accessed Mar 29, 2023,  URL:

Lawrence Dean

Lawrence Dean joined Fraunhofer AISEC as an IT security researcher in 2020, right after studying computer science at Technische Universität Darmstadt. His main topics of research involve mobile security, secure software engineering as well as digital identities with an added focus on hardware backed security. 

Most Popular

Never want to miss a post?

Please submit your e-mail address to be notified about new blog posts.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.

* Mandatory

* Mandatory

By filling out the form you accept our privacy policy.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Articles

Privacy By Design: Integrating Privacy into the Software Development Life Cycle

As data breaches and privacy violations continue to make headlines, it is evident that mere reactive measures are not enough to protect personal data. Therefore, behind every privacy-aware organization lies an established software engineering process that systematically includes privacy engineering activities. Such activities include the selection of privacy-enhancing technologies, the analysis of potential privacy threats, as well as the continuous re-evaluation of privacy risks at runtime.
In this blog post, we give an overview of some of these activities which help your organization to build and operate privacy-friendly software by design. In doing so, we focus on risk-based privacy engineering as the driver for »Privacy by Design«.

Read More »
Headerbild zum Blogartikel "Neue Studie zu Laser-basiertem Fehlerangriff auf XMSS" im Cybersecurityblog des Fraunhofer AISEC

Fraunhofer AISEC commissioned by the German Federal Office for Information Security (BSI): new study of laser-based fault attacks on XMSS

To ensure the security of embedded systems, the integrity and authenticity of the software must be verified, for example through signatures. However, targeted hardware attacks enable malware to be used to take over the system. What risks are modern cryptographic implementations exposed to? What countermeasures need to be taken? To answer these questions, Fraunhofer AISEC was commissioned by the German Federal Office for Information Security (BSI) to carry out a study of laser-based fault attacks on XMSS. The focus is on a hash-based, quantum-secure scheme for creating and verifying signatures based on the Winternitz One-Time-Signature (WOTS) scheme.

Read More »

Anomaly Detection with Quantum Machine Learning – Identifying Cybersecurity Issues in Datasets

Since the release of ChatGPT, the popularity of Machine Learning (ML) has grown immensely. Besides Natural Language Processing (NLP) anomaly detection is an important branch of data analysis whose goal is to identify observations or events that deviate from the rest of the data. At Fraunhofer AISEC, cybersecurity experts explore Quantum Machine Learning methods for anomaly detection. One approach is based on the classification of quantum matter while a second method uses a type of Quantum Support Vector Machine with a kernel that is calculated on a quantum computer. This blog post explains the fundamentals of anomaly detection and shows the two approaches being pursued by the Quantum Security Technologies group at Fraunhofer AISEC.

Read More »

Towards Automated Cloud Security Certification

Obtaining a cloud security certification requires a lot of preparation time, which mainly involves manual processes that are prone to error. In other words, several employees cannot perform their usual duties during an audit preparation. Our Clouditor tool aims to improve this process by making audit preparations more systematic and automatable. This makes it possible to continuously monitor cloud services and check their compliance with a cloud security catalog such as BSI C5[1], EUCS[2], or the CCM[3].

Read More »