Apps permitting cleartext (HTTP) traffic

What this finding means

An Android app that permits cleartext traffic can make plain HTTP requests. Since Android 9 the platform default is to refuse them, so an app that permits them has either set the manifest attribute or shipped a network security configuration that allows them.

We have recorded this in 1,416 apps. It is a configuration signal, not evidence that anything sensitive was ever sent unencrypted.

The attribute is not the whole answer, and this check used to get that wrong

android:usesCleartextTraffic is the coarse control, but from API 24 a network security configuration overrides it. An app can set the attribute to true and then forbid cleartext in res/xml, and the configuration wins. Reading only the manifest therefore overstates the problem.

Our check used to do exactly that. It now parses the network security configuration as well, and only base-config with cleartextTrafficPermitted set to false clears the finding. A domain-config is different: it names specific hosts and says nothing about the default, so an app that forbids cleartext for one API host while leaving the default permissive still permits cleartext.

An unreadable or unparseable configuration leaves the finding standing. Failing to parse a file is not evidence that it forbids anything, and treating it as such is how a scanner quietly stops reporting real problems.

How to fix it

• Remove android:usesCleartextTraffic and let the modern platform default apply.
• If you need a configuration file, set cleartextTrafficPermitted to false in base-config so the default is secure, then open up only what must be open.
• Scope any exception with a domain-config for the specific host, and keep debug-only exceptions inside debug-overrides so they cannot ship.
• Audit your dependencies' endpoints too: an SDK making plain HTTP calls needs the permission as much as your own code does.
• Remember that cleartext to a host on the local network is still cleartext, and local networks are frequently hostile.

How we detect it, and what we do not claim

Both the manifest attribute and res/xml network security configurations are parsed from the APK. Resolving the manifest's configuration resource id to a specific file would require reading resources.arsc, so the check examines the configurations present in the package.

What this cannot show is traffic. We do not run the app, so a permissive configuration is a capability rather than an observation. Treat the finding as a question about intent: if cleartext is permitted and nothing needs it, the permission should not be there.