Separate association from authorization
Domain verification establishes a relationship between a domain and application identity under the platform's rules. Your app still needs to validate the route, parameters and user access before showing or modifying protected data.
The App Links verification guide explains the domain association and testing workflow. Use the certificate fingerprint for the actual distributed signing identity, not automatically the upload key or a local debug certificate.
Validate parsed values
| Input | Validation question |
|---|---|
| Scheme | Is it an explicitly supported scheme? |
| Host | Does it exactly match an allowed host? |
| Path | Is the route recognized and appropriately scoped? |
| Object identifier | Is the current account authorized for this object? |
| Redirect destination | Is it constrained to an approved destination? |
Avoid substring host checks and do not execute an arbitrary action named by a query parameter. Decode and parse carefully so alternate encodings do not bypass the intended route rules.
Inspect the exported handler
Link-handling activities are often intentionally exported. Follow the exported-component guidance and protect sensitive operations after entry. An activity being reachable is not itself proof of a vulnerability; the question is what untrusted callers can cause it to do.
Test a route matrix
Test valid public links, protected links while logged out, cross-account object IDs, malformed parameters, unknown hosts and canceled authentication. Include the actual release certificate and the relevant domain-association files in the test record.
A browser opening the app once does not prove every host and route is verified correctly.
Use APKLint for the declaration review
The Exported Activity Checker can help inspect intent filters and exposure. It cannot verify your domain's live association file or enforce backend authorization. Combine static review with current platform verification tests and application-level route tests before publishing a release.
Write a route contract before writing the matcher
For an illustrative invoice route, define the allowed HTTPS host, the path structure and the identifier grammar. Decide how duplicate parameters, an empty identifier and an unexpected fragment are handled. A route parser should produce either one unambiguous supported action or a rejected result; it should not let different layers select different meanings from the same URL.
The deep-link security guide describes the validation boundary. Compare parsed components rather than accepting any URL containing a trusted word. Include a look-alike host and a URL whose user-info contains the trusted hostname in your local parser tests, because a visual resemblance is not an exact host match.
Use two accounts to test protected destinations
Create one synthetic invoice for each of two test accounts. Open the first invoice while signed into its owner, then open the second without switching accounts. The second request should be denied by the data access boundary even if Android correctly verified the domain and opened the intended activity. Domain association does not grant access to an account's records.
Repeat while logged out, cancel authentication and confirm that the protected destination remains unavailable. Then complete authentication with the other account and recheck authorization for the pending route. Do not save a pre-login authorization Boolean and reuse it after the identity changes.
Review domain association separately using the App Links verification workflow. Test the distributed signing identity and the intended host set. An upload certificate, debug certificate and Play-distributed certificate can represent different test conditions; record the one associated with the installed artifact.
Finally, test a legitimate public link, an unsupported path and a link that asks to redirect elsewhere. Keep the redirect destination constrained by its own contract. A handler that rejects unknown hosts initially but later opens an arbitrary destination supplied in a query parameter has moved the same trust decision into a second, unchecked step.
Sources and further reading
- Android Developers: Verify Android App Links
- Android Developers: android:exported
- Android Developers: Security best practices
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
