Network Security Quiz

SECURITY › Security

An app targeting API 34 makes a plain http:// request to api.example.com and it fails with a cleartext-not-permitted error. What is the correct fix if the endpoint genuinely must stay HTTP?

• Add a domain-config for that host with cleartextTrafficPermitted="true"
• Set android:usesCleartextTraffic="true" globally as the recommended approach
• Downgrade targetSdk to 27 so cleartext requests are allowed again
• Disable the network security configuration for the app entirely

Answer: Add a domain-config for that host with cleartextTrafficPermitted="true"

On Android 9+ cleartext is blocked by default; the scoped, recommended fix is a domain-config opting that single domain in with cleartextTrafficPermitted="true". A global flag or SDK downgrade is far broader and discouraged.

What value should the digest of an Android <pin> contain?

• A SHA-1 hash of the full leaf certificate, encoded in Base64
• The server's private key, Base64-encoded as the pin value
• A Base64-encoded SHA-256 digest of the certificate's SPKI
• The certificate serial number, written out in hexadecimal

Answer: A Base64-encoded SHA-256 digest of the certificate's SPKI

Android pins are a Base64 SHA-256 digest of the SPKI (public key info). Pinning the public key, not the whole cert, lets the certificate be reissued with the same key without breaking the pin.

A team pins only their current leaf certificate's key with no backup. The CA reissues the cert with a new key. What happens?

• Nothing; Android automatically falls back to system CA trust validation
• Installed apps can't reach that host until an update ships a new pin
• The pin silently auto-updates over the air from Google Play
• Only users running Android 8 or below are affected by this

Answer: Installed apps can't reach that host until an update ships a new pin

With no backup pin matching the new key, the TLS handshake fails the pin check for every already-installed app, breaking connectivity until an updated APK with the new pin is released. This is the core rotation risk of pinning.

Which statement about a raw SSLSocket is correct?

• It encrypts traffic but does not verify the server hostname by default
• It refuses to connect unless certificate pinning is configured
• It performs full hostname verification automatically, just like HttpsURLConnection
• It only works with self-signed certificates

Answer: It encrypts traffic but does not verify the server hostname by default

SSLSocket validates the certificate chain but skips hostname verification, so you must verify the hostname yourself or an attacker with any valid cert could impersonate the host. HttpsURLConnection handles hostname verification for you.

Why is putting a third-party API key in the Android app (even in an encrypted string or native lib) fundamentally insecure?

• Encrypted strings can't be consumed by common networking libraries
• ProGuard always strips string secrets, breaking the app at runtime
• API keys stored in resources are rejected by the Play Store at upload
• The APK can be decompiled or read at runtime, so any secret leaks

Answer: The APK can be decompiled or read at runtime, so any secret leaks

Anything shipped in the client can be reverse-engineered or read from memory, so embedded secrets are recoverable. Real secrets must stay on a backend that proxies the call; the client should use short-lived tokens.

You want to trust a self-signed CA so you can intercept and inspect your app's traffic during development, without affecting production users. What is the safest mechanism?

• Add the CA under <debug-overrides>, active only in debuggable builds
• Add the CA to base-config trust-anchors using src="user"
• Override the global TrustManager in code to accept all certificates
• Set cleartextTrafficPermitted="true" across all app domains

Answer: Add the CA under <debug-overrides>, active only in debuggable builds

A <debug-overrides> trust-anchor is active only in debuggable (non-release) builds and is ignored otherwise, and Play rejects debuggable release builds, so it can't reach production. A trust-all TrustManager or base-config change would weaken the shipped app.

In a network_security_config.xml that has a base-config plus a domain-config for api.example.com, which policy applies to a request to other.example.org?

• The domain-config for api.example.com, because it is the only explicit rule
• No policy; the request is blocked because it is unlisted
• The base-config, since other.example.org matches no domain-config
• The platform default, ignoring both base-config and domain-config

Answer: The base-config, since other.example.org matches no domain-config

domain-config rules apply only to their matching domains; everything else falls through to base-config, which defines the default policy for unmatched destinations. The most specific matching rule wins when one exists.

An app sets targetSdkVersion to 27 and ships no network_security_config.xml. It makes a plain http:// request. What happens?

• The request succeeds, because cleartext is allowed by default for API 27 and below
• The request fails, because cleartext is blocked on every Android version, no matter the targetSdk
• The request succeeds only on devices running Android 8 or lower, and fails on newer ones
• The build is rejected at upload time by the Play Store for including cleartext traffic

Answer: The request succeeds, because cleartext is allowed by default for API 27 and below

The cleartext-blocked-by-default behavior kicks in for apps targeting API 28+. Apps targeting 27 or lower still permit cleartext by default, since the default is governed by targetSdk rather than the device's OS version.

What is the effect of setting an expiration date on a <pin-set>, and its main security tradeoff?

• After expiry the app refuses all TLS connections to that domain until updated
• After expiry, pinning stops for the domain; an attacker past the date bypasses it
• It automatically rotates the pins to the new certificate when the date is reached
• It only governs how long a matched backup pin remains cached in device memory

Answer: After expiry, pinning stops for the domain; an attacker past the date bypasses it

Once the expiration passes, pin enforcement is dropped for that domain, which keeps un-updated apps from losing connectivity but means an attacker who can outlast (or roll the device clock past) the date escapes pinning.

A domain-config declares <domain includeSubdomains="true">example.com</domain>. To which hosts does this configuration apply?

• Only the exact host example.com, with no subdomains included
• Every domain the app contacts, since includeSubdomains is global
• Only www.example.com, as if it were the single canonical subdomain
• example.com and all of its subdomains, like api.example.com

Answer: example.com and all of its subdomains, like api.example.com

includeSubdomains="true" extends the rule to the named domain and everything below it; without the attribute, the rule matches only the exact host listed.

Even over a correctly configured HTTPS/TLS connection, what can a passive network observer still typically determine?

• The full URL path and query string of each request are still visible
• The decrypted request and response bodies can be read by the observer
• The destination host via SNI and DNS, plus traffic size and timing
• Any login password carried in the request body remains plainly exposed

Answer: The destination host via SNI and DNS, plus traffic size and timing

TLS encrypts the request and response contents, including the path, headers, and body, but the destination IP, the SNI server name, DNS lookups, and packet sizes/timing remain visible as metadata.

Besides the declarative <pin-set> in network_security_config.xml, how can an app enforce certificate pinning at runtime with OkHttp?

• By adding a CertificatePinner to OkHttpClient with host SPKI SHA-256 pins
• It cannot; OkHttp only trusts the system CA store and has no pinning API
• By setting usesCleartextTraffic to false on the client builder only
• By removing the HostnameVerifier, so the pinned certificate chain is checked

Answer: By adding a CertificatePinner to OkHttpClient with host SPKI SHA-256 pins

OkHttp exposes CertificatePinner, where you register a hostname plus one or more sha256/ SPKI pins that it enforces during the TLS handshake, serving as a programmatic alternative or complement to the XML pin-set.

To make certificate rotation less likely to break already-installed apps, pinning is often done against which certificate in the chain?

• The leaf certificate’s key, which changes every time it’s renewed
• An intermediate or root CA public key, which stays stable across renewals
• The server’s ephemeral session key, which is different for each connection
• The client app’s own certificate, which isn’t part of the server chain

Answer: An intermediate or root CA public key, which stays stable across renewals

Leaf certificates are reissued frequently, so pinning the more stable intermediate/root CA public key (still an SPKI SHA-256 digest) survives routine leaf renewals; the tradeoff is widening trust to anything that CA signs.

By default, which trust anchors does an app targeting API 24 (Android 7.0) or higher use to validate TLS server certificates?

• Both the system CA store and any user-installed CAs are trusted
• Only CAs manually installed by the user through Settings count
• Only the preinstalled system CA store; user CAs are ignored
• No CA store is trusted; each server cert must be pinned instead

Answer: Only the preinstalled system CA store; user CAs are ignored

Since Android 7.0, apps trust only the system CA store by default and ignore user-installed CAs unless the network security config explicitly opts in (for example trust-anchors with src="user"), which protects users from rogue or coerced CA installs.

Back to Network Security