Android's network security configuration is an XML file that controls cleartext traffic, trusted certificate authorities and pinning without code changes. Defaults depend on your target API level: from API 28, cleartext is off, and from API 24, user-added CAs are not trusted. Most weakening comes from overrides someone added and forgot.
Where the file lives
You register it in the manifest with android:networkSecurityConfig="@xml/network_security_config" on the application element. The file has up to three kinds of block: base-config for the app default, any number of domain-config blocks for specific destinations, and one debug-overrides block.
If several domain configs match a host, the most specific match wins. Values not set in a domain config come from its parent, then from base-config, then from the platform default.
Defaults by target API level
From Android's documentation:
- 28 and higher. Cleartext default: not permitted. Trust anchors: system CAs only.
- 24 to 27. Cleartext default: permitted. Trust anchors: system CAs only.
- 23 and lower. Cleartext default: permitted. Trust anchors: system and user CAs.
Two things follow. First, raising your target API level changes behavior, so test networking after you do. Second, an app targeting API 28 or higher that needs plain HTTP for some host has to say so explicitly.
Settings that weaken the defaults
A base-config that permits cleartext. The docs label this as something to avoid when possible, because it permits cleartext to any domain. If one legacy host needs it, scope the exception to a domain-config for that host.
Extra trust anchors in base-config. Trusting a custom CA is legitimate for an internal service. Putting it in base-config extends that trust to every connection. Scope it to the domain that needs it. The docs also note that Certificate Transparency verification is not performed on connections that use custom trust anchors.
Trusting user CAs. Including src="user" means any CA a user installs is trusted by your app. For most apps the default is the safer choice.
Debug overrides that ship. The debug-overrides block applies only when the app is debuggable, and it adds trust anchors across all configurations and skips pinning when a debug anchor is used. If the app is not debuggable the whole section is ignored, and app stores do not accept debuggable apps. Still, keep the override in a debug-only resource set so a release build never carries it.
A review checklist
- Find the config file and confirm the manifest points to it.
- Check for any
cleartextTrafficPermitted="true". Is each one scoped to a named host with a ticket explaining why? - List every
trust-anchorsentry. Is each scoped to a domain? - Look for
src="user". - Check pin sets for expiration dates and a backup pin (see the pinning post linked below).
- Confirm debug overrides are not in the release variant.
- Compare your result with MASVS-NETWORK-1: all traffic secured to current best practice, with no way for platform defaults to be bypassed.
MASVS-NETWORK-1 warns that developers can disable platform secure defaults or bypass them with low-level APIs or third-party libraries. A clean config file does not catch a library that makes its own connections, so also test traffic with a proxy.
For pinning rules, see certificate pinning on Android.
Quick check
Does raising targetSdk turn cleartext off?
Yes. Apps targeting API 28 or higher get cleartext disabled by default, so any host that relied on plain HTTP will fail until you configure an exception or move it to HTTPS.
Is the config file enough to prove traffic is secure?
No. Libraries can set up their own connections. Inspect real traffic as well.
Sources
Last reviewed: 19 October 2026.
