API Security HTTPS TLS and Encrypting API Traffic

Every API call carries data between a client and a server. Without encryption, that data travels in plain text — readable by anyone who can observe the network traffic. HTTPS and TLS are the technologies that encrypt this data in transit, making interception by attackers ineffective even when they capture the traffic.

Why Plain HTTP Is Dangerous for APIs

Scenario — Unencrypted API Call on Coffee Shop WiFi:

Client sends:
  GET http://api.bankapp.com/account/balance
  Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMDF9.abc

Network path:
  Client Device
       ↓  (WiFi)
  Coffee Shop Router       ← Attacker sniffs here with Wireshark
       ↓
  ISP Infrastructure       ← ISP can read this
       ↓
  Internet Backbone
       ↓
  API Server

Attacker sees:
  - Destination: api.bankapp.com
  - Path: /account/balance
  - Full JWT token: eyJhb...abc
  - Response: { "balance": 45000, "account": "XXXX1234" }

With the stolen JWT, attacker calls the same API as the victim.

What Is TLS

TLS stands for Transport Layer Security. It is the cryptographic protocol that makes HTTPS work. When you see HTTPS in a URL, TLS is encrypting the connection underneath.

HTTP vs HTTPS:

HTTP:   Plain text. Data readable by anyone on the path.
HTTPS:  HTTP + TLS encryption. Data is ciphertext to observers.

Port 80  → HTTP  (unencrypted)
Port 443 → HTTPS (TLS encrypted)

The TLS Handshake — Step by Step

TLS 1.3 Handshake (simplified):

Step 1: Client Hello
  Client → Server
  "I want to connect securely. I support these cipher suites:
   TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, ..."
  + Client's random number (for key generation)
  + Client's key share (public part of a key exchange)

Step 2: Server Hello + Certificate
  Server → Client
  "Agreed. Using TLS_AES_256_GCM_SHA384."
  + Server's random number
  + Server's key share
  + Server's TLS certificate (contains server's public key)

Step 3: Certificate Verification
  Client checks the certificate:
  ✓ Is it signed by a trusted Certificate Authority (CA)?
  ✓ Is the domain name in the certificate correct?
  ✓ Has the certificate expired?
  ✓ Has the certificate been revoked?

Step 4: Session Key Derivation
  Both sides independently compute the same symmetric session key
  using their random numbers and key shares.
  This is mathematically proven: both arrive at the same key
  without ever transmitting the key over the network.

Step 5: Encrypted Communication Begins
  All subsequent HTTP requests and responses are encrypted
  with the session key. Only the client and server can decrypt them.

Total time: TLS 1.3 completes in 1 round trip (1-RTT).

TLS Certificates Explained

A TLS certificate is a digital ID card for a server.
It contains:
  - The domain name it is valid for (e.g., api.company.com)
  - The server's public key
  - The Certificate Authority's digital signature
  - Validity period (start date, expiry date)
  - Certificate revocation information

Certificate Authority (CA):
  A trusted third party that verifies domain ownership and
  issues certificates. Browsers and operating systems maintain
  a list of trusted CAs (e.g., DigiCert, Let's Encrypt, Comodo).

Chain of Trust:
  Browser's Trusted Root CA
         ↓ signed
  Intermediate CA
         ↓ signed
  api.company.com Certificate

Browser trusts the Root CA → trusts the Intermediate CA
→ trusts the server certificate → establishes secure connection.

TLS Versions and What to Use

TLS Version History:

SSL 2.0 (1995) → Broken. Never use.
SSL 3.0 (1996) → Broken (POODLE attack). Never use.
TLS 1.0 (1999) → Deprecated. Disable.
TLS 1.1 (2006) → Deprecated. Disable.
TLS 1.2 (2008) → Still acceptable. Widely supported.
TLS 1.3 (2018) → Current standard. Fastest and most secure.

Recommendation:
  Support: TLS 1.2 and TLS 1.3
  Disable: TLS 1.0, TLS 1.1, SSL 2.0, SSL 3.0

Nginx configuration:
  ssl_protocols TLSv1.2 TLSv1.3;

Apache configuration:
  SSLProtocol -all +TLSv1.2 +TLSv1.3

Cipher Suites

A cipher suite is a combination of algorithms used for:
  - Key exchange (how session key is agreed on)
  - Authentication (verifying server identity)
  - Encryption (protecting data)
  - Integrity (ensuring data was not tampered with)

Strong cipher suites (TLS 1.3 — all are secure):
  TLS_AES_256_GCM_SHA384
  TLS_AES_128_GCM_SHA256
  TLS_CHACHA20_POLY1305_SHA256

Weak cipher suites to disable (TLS 1.2):
  Anything with: RC4, DES, 3DES, MD5, NULL, EXPORT, anon

Recommended Nginx cipher configuration:
  ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
               :ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
               :ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
  ssl_prefer_server_ciphers on;

HTTP Strict Transport Security (HSTS)

Problem without HSTS:
  A user visits http://api.company.com (no S).
  Browser makes an unencrypted connection first.
  Only then is it redirected to https://api.company.com.
  That first unencrypted request is visible to attackers.

  SSL Stripping Attack:
  Attacker intercepts the HTTP request.
  Prevents the HTTPS redirect.
  Serves the site over HTTP to the victim.
  Victim thinks they are on HTTPS but are not.

HSTS Solution:
  Server sends header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  
  Browser stores this policy for 31536000 seconds (1 year).
  Next time the user visits, browser automatically uses HTTPS
  WITHOUT making an initial HTTP request.
  SSL stripping attack cannot work — HTTPS is enforced before any request.

HSTS Preload:
  Submit your domain to the HSTS preload list (hstspreload.org).
  Major browsers hardcode your domain as HTTPS-only.
  Even a first-ever visit from a new browser goes directly to HTTPS.

Certificate Management Best Practices

Certificate Expiry Monitoring:
  TLS certificates expire (typically 90 days to 2 years).
  An expired certificate causes browsers to block your API.
  Set up monitoring to alert 30, 14, and 7 days before expiry.

  Free automation with Let's Encrypt + Certbot:
    Certbot auto-renews certificates every 60 days.
    No manual renewal required.

Certificate Pinning:
  Mobile apps can "pin" the expected certificate or public key.
  If the server's certificate changes (or is replaced by an
  attacker's certificate), the app refuses to connect.
  Covered in detail in the next topic.

Private Key Security:
  The private key that corresponds to your TLS certificate
  must be kept absolutely secret.
  If stolen: attacker can impersonate your server.
  Store: Hardware Security Module (HSM) or secrets manager.
  Never: commit to Git, store in shared file systems, log it.

Wildcard vs SAN Certificates:
  Wildcard: *.company.com (covers all subdomains)
  SAN: Multiple specific domains in one certificate
  
  Security concern with wildcards: if one subdomain is compromised,
  the wildcard certificate can be used for any subdomain.
  SAN certificates limit exposure to specifically listed domains.

Common TLS Misconfigurations in APIs

Misconfiguration 1: Self-Signed Certificates in Production
  Self-signed certs are fine for testing.
  In production: clients must disable certificate validation to use them.
  Disabling cert validation defeats TLS entirely.
  Always use a CA-signed certificate in production.

Misconfiguration 2: Mixed Content
  API served over HTTPS but loads resources (scripts, images) over HTTP.
  HTTP resources can be intercepted and replaced with malicious content.
  Always serve all resources from HTTPS URLs.

Misconfiguration 3: Disabling Certificate Validation in Code
  Python:
    requests.get(url, verify=False)    ← NEVER in production
  
  Node.js:
    process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'  ← NEVER
  
  These disable ALL TLS security. Used temporarily during development
  and accidentally left in production code.

Misconfiguration 4: Long Certificate Lifetimes
  Certificates valid for 2+ years increase the window if a private
  key is compromised. Short-lived certificates (90 days) are better.
  Modern best practice: automate renewal, use short lifetimes.

Misconfiguration 5: Missing OCSP Stapling
  OCSP (Online Certificate Status Protocol) checks if a cert is revoked.
  Without stapling, client must make a separate request to the CA.
  With OCSP stapling, server includes fresh revocation status in TLS handshake.
  Enable: ssl_stapling on; ssl_stapling_verify on; (Nginx)

Testing Your TLS Configuration

Free testing tools:

SSL Labs Server Test (ssllabs.com/ssltest):
  Comprehensive analysis of TLS configuration.
  Checks protocol versions, cipher suites, certificate chain,
  HSTS, OCSP stapling, and known vulnerabilities.
  Assigns a grade (A+ to F).
  Aim for A or A+ rating.

testssl.sh (command line):
  ./testssl.sh api.company.com
  Tests TLS locally without sending data to a third party.
  Useful for internal APIs.

OpenSSL (verify certificate):
  openssl s_client -connect api.company.com:443 -servername api.company.com
  Shows the full certificate chain and TLS version used.

Key Points

  • Plain HTTP exposes all API traffic — credentials, tokens, and data — to anyone who can observe the network.
  • TLS encrypts the connection through a handshake that establishes a shared session key without transmitting it over the network.
  • Support TLS 1.2 and TLS 1.3. Disable SSL and TLS 1.0/1.1 entirely.
  • HSTS forces browsers to always use HTTPS, preventing SSL stripping attacks. Add your domain to the HSTS preload list for maximum protection.
  • Never disable certificate validation in code — it makes TLS meaningless. Always use CA-signed certificates in production.
  • Test your TLS configuration with SSL Labs and aim for an A+ rating.
Previous lessons
Back to courses
Next lessons

Leave a Comment