Do you rely on TLS Pinning or OS level HTTPS handling for all your API privacy? You may either break your app or insufficiently protect your information on corporate networks.
It is not unusual for large corporations to use HTTPS proxy for data inspection. According to a paper titled "The Sorry State of TLS Security in Enterprise Interception": Network traffic inspection, including TLS traffic, in enterprise environments is widely practiced. — https://dl.acm.org/doi/10.1145/3372802
According to data reported by Cloudflare, "between 4% and 10% of the web’s encrypted traffic (HTTPS) is intercepted." — https://blog.cloudflare.com/understanding-the-prevalence-of-web-traffic-interception/
The impact on your API communication can be either exposing your user's private data to unintended third-party observers, or service interruption if you are doing TLS pinning.
This is why I have been pushing for API level security, using public/private keys, building on the foundations of Zero-Trust Architecture.
When building your next API, if you are transferring PII (Personally Identifiable Information) you shouldn't rely on the transport layer to provide the security. It should be built into your infrastructure and API layer.
Zero-Trust Architecture: A Quick Primer
Zero-Trust is a security model built on a simple premise: no network location, device, or connection is inherently trusted. Every request must prove its legitimacy, every time.
The concept was formalized by NIST in SP 800-207 ("Zero Trust Architecture"), which lays out the core tenets: verify explicitly, use least-privilege access, and assume breach. The traditional perimeter-based model "everything inside the firewall is safe" falls apart when your traffic is being inspected, rerouted, or decrypted by middleboxes you don't control.
This is directly relevant to API security. If your confidentiality guarantee lives entirely in the transport layer, then anyone who terminates that TLS session — legitimately or not — sees everything in plaintext. Zero-Trust pushes that trust boundary down to the application itself. The data should be protected independent of the pipe it travels through.
If you want to go deeper, NIST SP 800-207 is the canonical starting point (https://csrc.nist.gov/pubs/sp/800/207/final). For a more practical take, the CISA Zero Trust Maturity Model gives a staged adoption framework (https://www.cisa.gov/zero-trust-maturity-model).
Strategies for API-Level Cryptography
Web Apps
JWE (JSON Web Encryption, RFC 7516) is a well-supported standard for this. You encrypt the payload using the recipient's public key, and only their corresponding private key can decrypt it. Libraries exist for virtually every major language and platform.
For simpler cases, you can use a hybrid approach: exchange a symmetric key using asymmetric encryption (e.g., ECDH or RSA key exchange), then encrypt payloads with AES-GCM. This is essentially what TLS does internally. You're just moving that negotiation into your application protocol.
Encryption gives you confidentiality, but you also need to know the message hasn't been tampered with and actually came from who it claims to. Message signing addresses this.
JWS (JSON Web Signature, RFC 7515) lets the sender sign a payload with their private key, and the recipient verifies with the sender's public key. This proves both origin and integrity. You can combine JWS and JWE (sign-then-encrypt) for both properties.
HTTP Message Signatures (RFC 9421) is a newer standard worth watching, it lets you sign not just the body but also specific HTTP headers, method, and path, which protects against replay and request-manipulation attacks that payload-only signing misses.
Mobile Apps
For mobile applications, you can go a step further than software-only cryptography by leveraging hardware-backed key storage. Both iOS and Android offer secure hardware enclaves that can generate, store, and use cryptographic keys in a way that the private key material never leaves the hardware — not even your own app can extract it.
iOS: Secure Enclave + CryptoKit
On iPhone, the Secure Enclave supports P256 elliptic curve keys for both key agreement (ECDH) and signing (ECDSA). AES-GCM is hardware accelerated on Apple silicon. The general flow:
On the server side, generate an ECC P256 key pair in an HSM (or a cloud KMS such as AWS KMS or GCP Cloud HSM). Publish the public key through a key discovery endpoint, including a key ID for rotation. Avoid hardcoding the key in your app binary, as this creates the same update-to-rotate problem as TLS pinning.
In your mobile app, use the Secure Enclave to generate a hardware-bound P256 key agreement key pair via CryptoKit's SecureEnclave.P256.KeyAgreement.PrivateKey.
Perform ECDH between the client's Secure Enclave private key and the server's public key to derive a shared secret.
Use HKDF to derive AES symmetric keys from that shared secret. Be deliberate about the HKDF parameters: use a unique salt per session and include context in the info parameter (e.g., client identifier, server identifier, and key purpose) to bind the derived key to a specific use.
Encrypt payloads using AES-GCM, which provides both confidentiality and integrity in a single operation, with fallback to AES-CTR + HMAC-SHA256 if you require streaming encryption.
For request authenticity, the Secure Enclave also supports P256 signing (SecureEnclave.P256.Signing.PrivateKey). Have the client sign each request (or a digest of it) so the server can verify the request genuinely came from a device holding the corresponding private key. This gives you the mobile equivalent of the message signing pattern described in the web section above.
A note on algorithm choice: prefer AES-GCM over AES-CTR. AES-CTR provides confidentiality only, it has no built-in integrity protection, meaning a payload encrypted with CTR alone can be silently modified in transit. If you require the ability to stream data for encryption, for example encrypting very large file in an app extension, you may have to fallback to AES-CTR and implement your own integrity validation using HMAC-SHA256 which is also hardware accelerated.
Android: Keystore + StrongBox
Android offers a similar model through the Android Keystore system, with StrongBox providing hardware-level protection on supported devices (Pixel 3+, Samsung Galaxy S9+, and most flagships since 2018).
Generate a P256 key pair in the Android Keystore with setIsStrongBoxBacked(true)where available (falling back to TEE-backed Keystore otherwise).
Use KeyAgreement with ECDH to derive a shared secret against the server's public key.
Derive AES keys using HKDF with the same parameter discipline as on iOS.
Encrypt with AES-GCM via Cipher.getInstance("AES/GCM/NoPadding").
For signing, the Android Keystore supports ECDSA with P256 (SHA256withECDSA), giving you the same request authentication capability.
Key Discovery and Rotation
A natural question is how the app gets the server's public key in the first place, and how you rotate it over time. Bundling the operational encryption key directly in your app binary works initially, but creates the same update-to-rotate brittleness as TLS pinning.
The temptation is to solve this with a key discovery endpoint, fetching the latest key when you encounter an unknown key ID. But this reintroduces the problem you are trying to solve: that request isn't protected by your API-level encryption, so you're trusting the transport layer for the most sensitive exchange of all.
The approach that avoids this chicken-and-egg problem is to separate the trust anchor from the rotatable keys:
Bundle a long-lived signing-only public key in your app. This key does not encrypt anything. Its sole purpose is to verify the authenticity of other keys. Store its private counterpart in an HSM, use it for nothing else, and treat it as a root of trust.
Your key discovery endpoint then serves rotatable encryption and key-agreement public keys, each accompanied by a signature produced by the long-lived signing key and a key ID. When the app encounters an unfamiliar key ID, it fetches the new key from the endpoint and verifies the signature against the bundled trust anchor before accepting it. If the signature doesn't verify, the key is rejected regardless of what the transport layer says.
This gives you the ability to rotate operational keys at will, no app update required, while keeping trust rooted in a narrow, infrequently-changing anchor. The only scenario that forces an app update is compromise of the signing key itself, which is a much rarer event when that key lives in an HSM and is used exclusively for signing other keys.
It doesn't eliminate the bundled-key dependency entirely, but it reduces it to the smallest possible surface: a single verification key with a long lifespan and a minimal attack profile.
Conclusion
Transport-layer security is necessary but not sufficient. If your API handles sensitive data, and most do, the confidentiality and authenticity guarantees should live where the data lives: in the application layer. The standards and tooling are mature enough that this is no longer a heroic engineering effort. It's a design choice.
Start by identifying which API endpoints carry PII or other sensitive payloads. You don't need to encrypt everything, focus on where the exposure actually matters. Pick the strategy that fits your platform: JWE/JWS for web applications with broad library support, hardware-backed cryptography for mobile where the Secure Enclave and Android Keystore give you stronger guarantees. Design for key rotation from day one, because the alternative is painting yourself into the same corner that TLS pinning creates.
The building blocks are all standardized and well-documented. What's been missing is the habit of reaching for them.
Further Reading
