Network security config and pinning

Security Mid-level Kotlin 2.0+ API 24+ Reviewed By Best Latest Apps

Pick the fix

After a certificate rotation, all users of a pinned app get network errors. What would have prevented it?

Options
Hint 1 of 1

What do you need ready before rotating?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Pinning public keys with a backup pin and an expiration date

Correct. The backup lets you rotate; expiration stops old apps from failing forever.

Why not the others?
  • B Allowing cleartext traffic. Removes encryption entirely.
  • C Trusting user CAs. Weakens security and doesn't fix pins.
  • D Disabling hostname verification. Opens the app to interception.

30-second answer

network_security_config.xml sets per-domain rules: whether cleartext HTTP is allowed (blocked by default when targeting API 28+), which certificate authorities to trust (user-added CAs aren't trusted by default when targeting API 24+), debug-only overrides, and pins. Pinning protects against mis-issued certificates but can lock users out if certificates rotate, so pin public keys, include a backup pin, and set an expiration.

Practise saying it · 30 s. No recording, just a timer

Explain network security config.

Say your answer out loud, then check which of these points you covered:

  • Cleartext blocked by default
  • User CAs not trusted
  • Debug overrides
  • Pin keys with backup and expiry

Deep dive

<debug-overrides> lets debug builds trust a proxy CA without weakening release.

OkHttp's CertificatePinner is an alternative in code.

Pin the SPKI hash of your intermediate or leaf, with a backup key ready.

Many teams skip pinning and rely on Certificate Transparency and the system trust store.

A config with a pin set
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-06-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
    <debug-overrides>
        <trust-anchors><certificates src="user" /></trust-anchors>
    </debug-overrides>
</network-security-config>

Common mistakes

  • Allowing cleartext everywhere to fix one host.
  • Pinning a single leaf certificate with no backup.
  • Trusting user CAs in release builds.

Senior take & follow-ups

Cover defaults, then give a balanced view on pinning risks.

Follow-up questions

Think of your answer first, then open the hint.

  1. Why include a backup pin?

    Show hint

    So rotating to a new key doesn't break every installed app.

  2. How do you debug traffic with a proxy?

    Show hint

    Trust its CA only in debug-overrides.

Compare on iOS: Certificate and public key pinning Same trade-offs; iOS declares pins in Info.plist or checks them in URLSession.

Related questions

Suggest a fix if something here is wrong or out of date.