Teams should make Network Security Configuration explicit, not permissive by default. Set cleartext traffic to false at the base level, allow HTTP only for narrowly scoped domains if absolutely required, and verify that the app backend supports HTTPS. This reduces accidental plaintext transmission while preserving control over exceptions and making insecure endpoints easy to review.
Why network security configuration needs to be explicit
Android network security configuration is safest when teams treat it as a deliberate policy layer, not a convenience setting. The goal is to define the app’s default transport behaviour, then make every exception visible and reviewable. That prevents silent fallback to insecure transport while still allowing tightly scoped legacy cases to keep working during migration.
The practical pattern is simple: disable cleartext at the base level, permit it only for narrowly named domains when there is a documented business reason, and keep that exception list short enough to audit. This gives reviewers a concrete place to see what is still dependent on HTTP, instead of discovering it through production traffic or a failed release.
When teams write the policy this way, they also make backend readiness part of the app release process. If a service cannot support HTTPS yet, the issue is not in the mobile client alone, it is a transport migration gap that should be resolved before the configuration is tightened further.
How to avoid breaking production traffic during rollout
The safest rollout starts with inventory, not enforcement. Identify every host the app talks to, group them by production, staging, and third-party dependencies, then confirm which endpoints already support HTTPS end to end. That prevents teams from assuming a domain is safe to lock down when one overlooked API or file endpoint still depends on HTTP.
Use exceptions as a transition mechanism, not a permanent design choice. A narrow allowlist for specific domains is better than a broad app-wide allowance because it limits blast radius and makes the remaining insecure dependencies obvious in code review. If an exception is needed, pair it with a deprecation date and a backend fix owner so it does not survive past migration.
Teams should also validate behaviour on real devices and real network paths, because production failures often come from redirects, certificate trust issues, or forgotten subdomains rather than the main API host itself. A policy that looks correct in the manifest can still break if the app reaches analytics, auth, content delivery, or update endpoints that were not included in the test plan.
What good implementation and review look like
A solid implementation has three visible properties: the default policy blocks cleartext, exceptions are narrow and justified, and the backend side proves it can serve the same traffic over HTTPS. That makes the configuration easy to reason about and reduces the chance that one permissive setting quietly undoes the rest of the transport posture.
Reviewers should be able to answer a few direct questions: which hosts still need HTTP, why they need it, who owns their migration, and how that exception is monitored. If those answers are not obvious from the configuration and release notes, the team is relying on memory instead of control.
For teams operating at scale, the main failure mode is exception drift. Once one domain is allowed, the same shortcut tends to spread to adjacent environments, test builds, or third-party integrations. Keeping the policy centralized and the exception list small helps prevent temporary compatibility workarounds from becoming the new normal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | Network transport hardening reduces plaintext exposure of app data. |
| Recommendation — Require TLS for app traffic and restrict cleartext exceptions to documented cases. | ||
| OWASP ASVS | V12 — Secure Communication | The question is about enforcing secure transport without breaking app communication. |
| Recommendation — Verify that all sensitive app communications use HTTPS and reject insecure fallback paths. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | TLS-backed transport protection is part of securing data in transit for mobile apps. |
| Recommendation — Specify protected transport requirements and validate that insecure channels are not used in production. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | The answer concerns protecting network traffic in transit and limiting cleartext exposure. |
| CM-6 — Configuration Settings | Android network security configuration is a configuration-control problem with exception handling. | |
| Recommendation — Enforce protected communications and constrain any temporary plaintext exception. Set secure defaults and manage any exceptions through controlled configuration review. | ||
Practitioner Guidance
What to verify: Confirm that every production host the app contacts responds over HTTPS before you remove or tighten any cleartext exception. If one backend cannot yet support TLS, treat that as a migration dependency, not an app-only problem.
Common mistake: Allowing cleartext at the app level to avoid one failing endpoint. That choice usually hides the real issue and makes it harder to see which dependency still needs remediation.
What good looks like: The base policy is deny-by-default for cleartext, exceptions are rare and domain-specific, and the remaining HTTP endpoints are visible enough to track to closure.
Practitioner takeaway: The safest production rollout is not “permit first, tighten later”, it is “prove HTTPS support first, then allow only the smallest necessary exception set while you finish the migration.”
Related resources from NHI Mgmt Group
- How should security teams implement Kubernetes network policies to reduce lateral movement without breaking application traffic?
- How should security teams implement relational authorization in high-traffic applications without turning every access check into a network dependency?
- How should security teams implement runtime application protection without disrupting production traffic?
- How should security teams use virtual Android devices for secure mobile app testing without affecting production accounts?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
