News
assetlinks.json vs apple-app-site-association
March 19, 2022
assetlinks.json vs apple-app-site-association is Android App Links versus Apple Universal Links, both published under /.well-known/. Google looks at https://example.com/.well-known/assetlinks.json. Apple looks at apple-app-site-association (often without a file extension) on the HTTPS origin that matches the applinks domain. Both files are meant to be public: package names, SHA-256 cert fingerprints, team IDs, and path prefixes. They are not API keys. Do not put signing secrets, internal hostnames, or debug bundle IDs you would not print on the marketing site. Path statements should not open authenticated deep links that skip login — that is an open-redirect-class product bug, not a roast finding. RoastMyOpsec does not require these files, does not score them, and does not verify app signatures. Missing them is an app-link gap, not an OPSEC F.
The practical difference
assetlinks.json is a JSON statement list: this Android package, this cert fingerprint, may handle these relations (typically delegate_permission/common.handle_all_urls). AASA is Apple's JSON: applinks details with appIDs and paths or components. Serve both over HTTPS with a boring Content-Type. Do not hide them behind a login.
security.txt and change-password are other well-known files with different jobs. Do not merge them.
How to choose what to publish
Production apps only. Staging package names belong on staging hosts, not on the brand apex. Paths: public content you actually want to open in-app. Exclude /reset?token= style URLs from associated paths so a mail client does not hand a token to the wrong surface — see tokens in URLs.
| File | Platform | Typical contents | Takeaway |
|---|---|---|---|
| /.well-known/assetlinks.json | Android App Links | Package + cert fingerprints | Public by design; no secrets |
| /.well-known/apple-app-site-association | iOS Universal Links | Team ID + bundle + paths | HTTPS only; no auth wall |
| /.well-known/security.txt | Researchers | Contact, policy | Different well-known |
| /.well-known/change-password | Password managers | Redirect to the form | Different well-known |
What the roast can prove
A 404 on either file is not a finding. A 200 that is HTML from a SPA catch-all is a product bug for App Links — browsers and OS fetchers need JSON, not the homepage. Confirm Content-Type yourself. The roast does not parse AASA.
Common mistakes
The first mistake is serving AASA only on www while applinks lists the apex.
The second mistake is leaving a debug team ID in production AASA.
The third mistake is treating a missing assetlinks.json like a missing CSP.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Are Digital Asset Links a vulnerability if public?
- No. The file is supposed to be public. Secrets and leftover debug apps in it are the miss.
- Can I robots.txt Disallow these files?
- OS fetchers still need them. Disallow does not hide them from a GET. Do not use robots.txt as access control.
- Does RoastMyOpsec check App Links files?
- No. They are not scored. Missing them is not an OPSEC F.