Secure Data Transfer Between Mobile App and Server

1. The simple mental model

When an iOS app sends data to a backend, we usually think, “I am sending JSON to the server.” But the network does not understand Swift dictionaries or readable JSON objects. The data passes through multiple layers before it leaves the phone.

Swift Dictionary
    ↓ JSON serialization
JSON text: {"name":"Ajeesh"}
    ↓ UTF 8 encoding
Raw bytes
    ↓ TLS encryption
Encrypted bytes over the network

2. Why mobile API security matters

A mobile app may send login credentials, access tokens, payment details, health data, BLE device readings, subscription status, or internal business information. If the request is not protected properly, someone between the phone and server can read or modify the message.

• Healthcare app: patient reports, device readings, or medical history can be exposed.
• Fintech app: payment amount, account details, or session tokens can be stolen.
• IoT app: device commands, sensor values, or user location can be manipulated.
• Subscription app: entitlement status or API responses can be tampered with.

3. What TLS does behind HTTPS

HTTPS = HTTP over TLS. TLS is the modern security protocol that protects data in transit. In iOS, when we use URLSession or Alamofire with an HTTPS URL, Apple’s networking stack performs the TLS handshake automatically.

• The app opens a TCP connection to the server.
• The app and server exchange TLS capabilities through ClientHello and ServerHello.
• The server sends its certificate.
• iOS validates the certificate chain, expiry, domain name, and trusted Certificate Authority.
• RSA in older TLS or ECDHE in modern TLS establishes a shared secret.
• Actual HTTP traffic is encrypted using fast symmetric encryption such as AES GCM or ChaCha20 Poly1305.

4. What is inside a certificate?

A server certificate is like a digital identity card for a backend domain. It is public. Anyone on the network can see it during the TLS handshake. That is not a problem because the certificate contains the public key, not the private key.

iOS maintains a trust store of trusted root Certificate Authorities. When a server sends a certificate, iOS builds and verifies the certificate chain. If the chain is valid and the domain matches, normal TLS trust succeeds.

5. RSA and ECDHE

TLS needs both sides to end up with a shared secret. That secret is then used to derive fast symmetric encryption keys. RSA and ECDHE are two different ways to establish that secret.

Forward secrecy means that even if the server’s long term private key is leaked in the future, old recorded TLS traffic should still remain safe.

6. AES GCM protects the actual data

RSA or ECDHE is not used to encrypt every JSON request. That would be slow. Once the shared secret is established, TLS derives session keys and uses fast symmetric encryption for real traffic.

If an attacker changes even one encrypted byte, AES GCM tag verification fails and the server rejects the message.

7. Man in the Middle attack

A successful MITM attack usually does not break TLS mathematics. Instead, the attacker tricks the app into creating a secure connection with the attacker, while the attacker separately creates another secure connection with the real server.

For this attack to succeed, the device must trust the attacker’s certificate. This can happen during development with Charles Proxy or Burp Suite when a proxy root certificate is installed manually. In a malicious scenario, a compromised or user installed root certificate can make the app trust the wrong certificate.

8. What SSL pinning adds

Normal TLS asks: “Is this certificate trusted by the operating system?”

SSL pinning asks one more question: “Is this the exact certificate or public key my app expects for this backend?”

9. Certificate expiry and key rotation

Certificate pinning has an operational risk: certificates expire and get renewed. If the app pins the full certificate and the backend replaces it, old app versions can fail until users update.

Public key hash pinning reduces this risk when the certificate changes but the same key pair is reused. But if the backend changes the key pair, the pinned public key hash also changes.

10. Where SSL pinning happens in iOS

In native iOS, pinning is commonly handled in URLSessionDelegate through the server trust challenge callback. iOS first performs normal trust evaluation. Then the app adds its own pinning check.

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (
        URLSession.AuthChallengeDisposition,
        URLCredential?
    ) > Void
) {
    // 1. Confirm this is a server trust challenge
    // 2. Get serverTrust from challenge.protectionSpace
    // 3. Let iOS validate normal certificate trust
    // 4. Extract server certificate or public key
    // 5. Hash the public key using SHA 256
    // 6. Compare with pinned hash in the app
    // 7. Match: use credential
    // 8. Mismatch: cancel connection
}

Final mental model

Mobile App
   ↓
HTTPS API request
   ↓
TLS handshake
   ↓
Certificate validation by iOS
   ↓
Optional SSL pinning by the app
   ↓
RSA or ECDHE establishes shared secret
   ↓
TLS derives session keys
   ↓
AES GCM / ChaCha20 encrypts HTTP data
   ↓
Backend receives protected request

If there is one thing to remember, it is this: TLS protects the communication channel. SSL pinning strengthens the app’s confidence that the channel is connected to the real backend, not a trusted looking attacker.