Your assetlinks.json and apple-app-site-association are public by design. Here's what they tell people.

If you ship an Android or iOS app that opens links into itself, you have two small files in your web root that you may have never looked at. /.well-known/assetlinks.json for Android, /.well-known/apple-app-site-association for iOS. The operating system fetches them to confirm that your app and your website are run by the same people, which is what lets a link to yoursite.com/order/123 open in your app instead of the browser.

Both files have to be world-readable. That's not a mistake to fix, it's how the verification works: the OS, on millions of strangers' phones, has to be able to read them. So this isn't a vulnerability article. It's a "know what you're publishing" article, because while these files are supposed to be public, most people who deploy them have no idea what's actually inside.

What the files spell out

The contents are app identifiers, and they're more specific than you might assume.

assetlinks.json lists your Android package name (the com.yoursite.app identifier) and the SHA-256 fingerprint of the certificate you sign your APK with. The package name is a handle an attacker can use to find your app on the Play Store and pull it apart. The signing fingerprint isn't a secret either (it's derived from a certificate, and the certificate's public half is in the APK already), but it confirms the exact signing identity behind your app.

apple-app-site-association lists your Apple Team ID and the bundle IDs of your apps, and it spells out the deep-link path map: which URL patterns your app claims to handle. That last part is the interesting one for recon. The path map is, in effect, a list of the routes your app cares about, /order/*, /invite/*, /reset-password/*, published in a tidy JSON document. It's a sketch of your app's important surfaces, handed over without anyone having to install anything.

Why we list it, and why it doesn't touch your grade

It would be easy to turn this into a scary finding. It isn't one, and treating it like a misconfiguration would be wrong, the kind of false alarm that makes a security report read as untrustworthy. So this is reported as informational, and it's graded as completely neutral: it doesn't move your score, it isn't counted among your real findings, and it never reads as something you did wrong.

The reason to surface it at all is that the surface an attacker maps first is the surface you should know is visible. Someone planning an attack on your app reads these files early, because they're a free, accurate description of your app's identity and its important routes. Knowing what they say, and confirming nothing landed in them that shouldn't have, is just awareness. There's no action to take if you ship a mobile app, because the files have to be there. The only thing worth doing is reading your own, the way an outsider would, and confirming the path map doesn't accidentally advertise an internal or sensitive route you'd rather not announce.

Reading your own well-known files

These files are fetched by every phone that verifies your app, so reading them yourself takes no special access, and a scanner reads them the same way the OS does. SurfaceCheckr requests both well-known paths, confirms each is the genuine file (a valid assetlinks.json array, or an apple-app-site-association with the real applinks/webcredentials/appID structure, so an unrelated JSON page can't trip it), and reports what they disclose. It files this as awareness, grade-neutral, never as a finding, because penalizing a file that's required to be public would be wrong. What you get is a plain account of what your app's public identity files say about you, which is the first thing someone scoping your app would go read.

For the broader picture of what an outsider learns before touching your site, the passive reconnaissance article is the overview, and the security.txt piece covers another well-known file, this one you actually want people to find.