{
	"id": "cf7fd944-38fb-4caa-97bb-60a8e2581d7d",
	"created_at": "2026-04-06T00:16:02.053011Z",
	"updated_at": "2026-04-10T03:21:59.22813Z",
	"deleted_at": null,
	"sha1_hash": "b34876ba6221de401709558d4d56838fb1159882",
	"title": "Guide to Network Security Configuration in Android P",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 80445,
	"plain_text": "Guide to Network Security Configuration in Android P\r\nPublished: 2018-08-15 · Archived: 2026-04-05 17:54:55 UTC\r\nAs data privacy becomes increasingly important, Google has introduced mobile OS enhancements to safeguard all\r\ndata that traverses Android mobile devices and endpoints. Set for release in August 2018, network\r\ncommunications in Android 9.0 P (Pie) will default to TLS. Android mobile app developers will either need to\r\nupdate their back-end services to support HTTPS or implement the Android Network Security Configuration\r\nfeature to prevent app connections from failing.\r\nWhen Android 6.0 Marshmallow was released, Google introduced the manifest attribute\r\nandroid:usesCleartextTraffic as a means to protect against accidental use of cleartext traffic. Android 7.0\r\nNougat extended this attribute by introducing the Android Network Security Configuration feature, which allows\r\ndevelopers to be more prescriptive about secure communications. Network Security Configuration is an XML file\r\nin which developers customize network security settings for an Android app.\r\nSome of you may think this sounds familiar. iOS uses a similar client side check known as App Transport\r\nSecurity. While there are quite a few similarities in what protections Network Security Configuration offers when\r\ncompared to NSAppTranportSecurity, the two take very different approaches to network security on their\r\nindividual platforms. To learn more about ATS, check out my previous blog.\r\nLet’s examine several benefits of using Network Security Configuration in Android mobile apps and dive into best\r\npractices for implementing this feature.\r\n1. Protect against regressions to cleartext traffic\r\nSecurity is more about layers of protection than a single iron wall. The Android Network Security Configuration\r\nfeature provides a simple layer to protect apps from unintentionally transmitting sensitive data in unencrypted\r\ncleartext.\r\nIf you don’t know what “unencrypted communications” means, think of it this way — let’s say your office has a\r\npolicy to send all shipments via UPS. A new intern joins the office and is tasked with shipping equipment to an\r\noffice across the country. Oblivious to the policy and with all the best intentions, the intern sets up all shipments to\r\nbe sent through an unknown, less expensive service. The Android Network Security Configuration feature is like\r\nthe shipping/receiving manager who examines all inbound and outbound shipments and stops the shipment before\r\nthe equipment gets into the hands of an unvetted delivery system. It can be used to prevent the accidental use of\r\nuntrusted, unencrypted connections.\r\nOne of the biggest changes in Android 9 is that cleartextTrafficPermitted is set to false by default. This\r\nmeans that if you don’t see this flag explicitly set to false, and the app is targeting API levels lower than 28, the\r\nflag will be honored as true.\r\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\r\nPage 1 of 7\n\nAnother capability of the cleartextTrafficPermitted flag being used in the Network Security Config is the\nability to enforce the true setting on specific domains and subdomains:\nNetwork Security Configuration\ninsecure.example.com 2. Set up trusted Certificate Authorities for secure connections\nTrusted Certificate Authorities (CA) act as the circle of trust. In the previous example, the office policy was to\nship with UPS, but that policy could be expanded to FedEx, DHL, and so forth. Essentially, who do you trust to\nsecurely send app data and prevent man-in-the-middle attacks? Developers can use the Android Network Security\nConfiguration feature to designate which CAs they trust to issue certificates and ensure secure communications.\nTo start, Android Network Security Configuration gives developers a few options in terms of what CAs they\nshould be trusting. By default, the trust anchor used by Android 7+ (Nougat, Oreo and Pie) will be the pre-installed system CA certificates, noted as system :\nTrust Anchors: Android 7+\nIn Android 6 (Marshmallow) and below, your default trust-anchor will also include user installed certificate,\nnoted as user :\nTrust Anchors: Android 6 and below\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 2 of 7\n\nFinally, you can set a custom trust anchor:\nTrust Anchors: Custom\n3. Implement certificate pinning\nImplementing certificate pinning offers yet another layer of security. Let’s revisit the running example of shipping\nequipment. If trusted CAs are like UPS, FedEx, etc., then certificate pinning is akin to specifying which of those\ncompanies’ drivers you trust to send your shipment. The Android Network Security Configuration feature can be\nused to restrict communications with only specific certificates issued by a trusted CA.\nWe discussed different implementations of certificate pinning in a previous blog post. In the example below, we\nsee we can pin to a specific domain and subdomains, set pins along with backups, and set an expiration date.\nCertificate Pinning with Network Security Config\nexample.com7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE= 4. Debug app network connections\nAnother option offered in Android Network Security Configuration is debug-overrides . This feature allows you\nto have settings in the Network Security Config that will only be usable when android:debuggable is set to\ntrue . For example, you can configure a custom trust-anchor for a quality assurance/pre-production\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 3 of 7\n\nenvironment using a custom CA. This eases testing in a closed environment because the app store does not accept\napps marked debuggable.\nDebug Overrides\nImplementation Advice\nNow that you understand a few of the benefits of deploying Network Security Configuration, let’s cover some best\npractices for implementing this file.\nFirst, check the app manifest to see if it uses this feature. Look for the attribute android:networkSecurityConfig ,\nwhich would appear similar to this:\nSample Manifest with Network Security Config\n... Once you’ve located the Network Security Configuration file, it’s time to check how to permit cleartext traffic.\nThe example code snippet below shows a bad example of how someone might use Network Security\nConfiguration.\nBad Example: cleartext Permissions with Network Security Config\nexample.comcdn.example2.com https://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 4 of 7\n\nWhile this ensures all traffic to example.com and cdn.example2.com is sent over HTTPS, the default\nconfiguration for all traffic sent to other domains can be cleartext. This completely defeats the intended purpose of\nthe Network Security Configuration feature — to improve the privacy of all data transmitted through Android\ndevices.\nIf your mobile app must send data in cleartext, then do this to only allow encrypted communications to certain\ndomains. In addition, carefully scrutinize endpoints that HTTP is explicitly allowed to check for sensitive data and\nother API-related issues:\nRecommended Implementation of cleartext Permissions\ninsecure.example.cominsecure.cdn.example.com Another thing to consider regarding the cleartextTrafficPermitted flag is it defaults to true on Android 8\nand lower. Because of this, explicitly set the flag to false in all apps’ Network Security Configuration.\nLet’s look at another example below:\nBad Example: Default Implementation of Trust Anchors for Android 6 and below\nIn this example, we see the app is accepting user certs within the app’s trust anchor. This means that user-installed certs will be trusted by the app the same way system pre-installed certs are. When configuring the\ntrust-anchors used by the app, it’s best to limit trust only to the system certs and, when necessary, to a\ncustom CA built within the app. This can help prevent MITM attacks where an attacker is able to install a cert on\nthe device. As part of the the protections introduced as part of Android 7, by default a user-installed certificate\nisn’t trusted like pre-installed certificates. As stated earlier, Android 6 and below accept user certs by default, so\nit’s important to explicitly select system and/or a custom CA when necessary and exclude user in all apps.\nRecommended Implementation of Trust Anchors with Custom CA (When Necessary)\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 5 of 7\n\nLet’s look at an example implementation of pinning:\nBad Example: Certificate Pinning with Network Security Config\nexample.com7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y= The example above reveals two potential issues within the app. First, there is no expiration set for the pin-set .\nSecond, there is no backup pin. A smart strategy is to set an expiration for certificates and have multiple backup\npins. It is not unheard of to have four pins in rotation. If you do not explicitly set an expiration date for the pin,\nyour app will fail to connect after expiration occurs. But if you set an expiration and the pin expires, the app will\nfail over to the system CA on the device instead of failing to connect.\nRecommended Implementation of Certificate Pinning with Network Security Config\nexample.com7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE= Finally, let’s talk about the Network Security Config debug-overrides .\nRecommended Implementation of Debug Overrides with Network Security Config\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 6 of 7\n\nWhile the debug feature can help eliminate debug network code in an app, make sure to remove any debug CAs\nfrom the app. As a best practice, avoid leaving unnecessary information in your app that could present a security\nrisk, especially if the internal CA certificates are included with final production build of the app.\nMobile Apps, IoT \u0026 5G\nWATCH LEADERSHIP ROUNDTABLE:\nPowering Innovation and Performance Securely\nFrom the perspective of a security analyst, knowing how to read and spot issues in the Network Security\nConfiguration is important. As we can see, we are able to find some potential issues in the app before install. But\nkeep in mind that these findings alone aren’t proof that your app’s network connections are secure.\nYou’ll still need to determine if your app is performing hostname verification, because Network Security\nConfiguration will not protect against those types of issues. Make sure your third-party libraries honor Network\nSecurity Configuration. If they don’t, these protections may cause issues in your app. In addition, Network\nSecurity Configuration is not honored by lower-level network connections such as websockets. Finally, keep in\nmind that network-related issues in mobile are only a small part of the overall scope in mobile testing.\nOverall, Android Network Security Configuration offers a lot of simple network security features for Android. If\nyour app does not currently take advantage of Network Security Configuration, you will need to use it in the\ncoming year.\nCoinciding with the release of Android P, Google has begun enforcing target API levels in the app stores to reduce\nmobile OS fragmentation and push users to current releases. The current requirement is 26, although Google plans\nto incrementally increase that number with each new release. By this time next year, API Level 30 (Android Q)\nwill probably be out. That means if your app uses HTTP, it must be declared in the Network Security\nConfiguration file because the mandatory target API level will be 28 by then.\nStay abreast of other security enhancements by subscribing to our All Things Mobile DevSecOps newsletter and\nperform automated mobile application security testing to ensure your Android apps safely implement network\ncommunications.\nSource: https://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nhttps://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/"
	],
	"report_names": [
		"a-security-analysts-guide-to-network-security-configuration-in-android-p"
	],
	"threat_actors": [],
	"ts_created_at": 1775434562,
	"ts_updated_at": 1775791319,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b34876ba6221de401709558d4d56838fb1159882.pdf",
		"text": "https://archive.orkl.eu/b34876ba6221de401709558d4d56838fb1159882.txt",
		"img": "https://archive.orkl.eu/b34876ba6221de401709558d4d56838fb1159882.jpg"
	}
}