Man In The Middle with Api Keys

Man-in-the-middle (MITM) attacks targeting API keys exploit the trust relationship between clients and servers. In API contexts, attackers intercept communication channels to steal, manipulate, or reuse API keys, granting unauthorized access to services and data.

The most common MITM vector for API keys is network-level interception. When API keys are transmitted over unencrypted channels or when HTTPS validation is improperly configured, attackers positioned on the network can capture these credentials. Public Wi-Fi networks, compromised routers, or even malicious browser extensions can serve as MITM points.

Consider this vulnerable Node.js example:

// VULNERABLE: No HTTPS verification, API key in query params
const axios = require('axios');

async function makeApiCall() {
  const apiKey = 'sk-1234567890abcdef'; // Hardcoded key
  const url = `http://api.example.com/data?apikey=${apiKey}`;
  
  try {
    const response = await axios.get(url);
    console.log(response.data);
  } catch (error) {
    console.error(error);
  }
}

makeApiCall();

This code exposes multiple MITM vulnerabilities: the API key travels in plaintext via query parameters, uses HTTP instead of HTTPS, and is hardcoded in the source code. An attacker on the same network could intercept this request and immediately use the stolen key.

Another MITM pattern involves proxy-based attacks where malicious proxies intercept API traffic. Mobile apps and desktop clients often trust system-level proxies, allowing attackers to route traffic through their own servers. The stolen API keys can then be used to impersonate legitimate users.

Time-based MITM attacks represent a more sophisticated threat. Attackers capture API keys and replay them within the key's validity window. This is particularly dangerous for long-lived keys or keys without proper rotation policies.

API key injection through compromised client applications creates another MITM scenario. Malicious versions of legitimate apps can transmit captured keys to attacker-controlled servers, creating a distributed key harvesting network.

Detecting MITM vulnerabilities in API key implementations requires both static analysis and dynamic testing. Security scanners must examine how keys are transmitted, stored, and validated.

Network traffic analysis reveals MITM vulnerabilities. Tools like Wireshark or mitmproxy can capture API traffic to verify whether keys are encrypted in transit. Look for API keys appearing in:

• URL query parameters (visible in browser history and server logs)
• HTTP headers sent over unencrypted connections
• Client-side JavaScript where keys are exposed to browser dev tools
• Mobile app binaries where keys are embedded

middleBrick's black-box scanning approach specifically tests for MITM vulnerabilities by attempting to intercept API key transmissions. The scanner verifies HTTPS implementation, checks for certificate validation bypasses, and tests whether keys are transmitted over secure channels.

Static code analysis identifies hard-coded keys and insecure transmission patterns. Tools like middleBrick's OpenAPI spec analysis cross-reference API definitions with runtime behavior to detect discrepancies between documented security requirements and actual implementations.

Consider this detection scenario:

# Test for MITM vulnerabilities using curl
curl -v -k https://api.example.com/endpoint \
  --resolve "api.example.com:443:127.0.0.1" \
  --connect-to "api.example.com:443:127.0.0.1" \
  -H "Authorization: Bearer $API_KEY"

This command attempts to intercept traffic to test if the API accepts connections even when certificate validation is bypassed. A vulnerable API would respond successfully, indicating potential MITM susceptibility.

middleBrick's 12 security checks include specific MITM-related tests:

The scanner's black-box approach means it doesn't need API credentials to test these vulnerabilities, making it effective for assessing third-party APIs or production systems without requiring special access.

Remediating MITM vulnerabilities in API key implementations requires a defense-in-depth approach. The primary strategy is ensuring all API key transmissions occur over properly validated HTTPS connections.

Proper HTTPS implementation includes certificate pinning to prevent man-in-the-middle attacks even when attackers have valid certificates. Here's a Node.js example with certificate pinning:

const axios = require('axios');
const https = require('https');
const fs = require('fs');

// Load your API's certificate
const cert = fs.readFileSync('api.example.com.crt');

const httpsAgent = new https.Agent({
  cert: cert,
 {
    // Custom validation to prevent MITM
    if (cert.subject.CN !== 'api.example.com') {
      throw new Error('Invalid certificate subject');
    }
  }
});

async function makeSecureApiCall(apiKey) {
  const url = 'https://api.example.com/data';
  
  try {
    const response = await axios.get(url, {
      httpsAgent,
      headers: {
        'Authorization': `Bearer ${apiKey}`
      }
    });
    return response.data;
  } catch (error) {
    if (error.code === 'UNABLE_TO_VERIFY_LEAF_SIGNATURE') {
      throw new Error('Certificate validation failed - potential MITM');
    }
    throw error;
  }
}

This implementation prevents MITM attacks by validating the server certificate against a known good copy and implementing custom validation logic.

Transport Layer Security (TLS) configuration must use strong cipher suites and modern TLS versions. Avoid SSLv2, SSLv3, and TLS 1.0/1.1. Configure your servers to use TLS 1.2 or higher with strong cipher suites.

API key transmission should never occur in URL parameters. Instead, use HTTP headers:

# Secure Python implementation
import requests
from requests.auth import AuthBase

class ApiKeyAuth(AuthBase):
    def __init__(self, api_key):
        self.api_key = api_key
    
    def __call__(self, r):
        r.headers['Authorization'] = f'Bearer {self.api_key}'
        return r

def make_api_call(api_key, url):
    response = requests.get(
        url,
        auth=ApiKeyAuth(api_key),
        verify=True,  # Enforce certificate verification
        timeout=10    # Prevent slowloris attacks
    )
    return response.json()

This approach keeps API keys out of logs, browser history, and network traces while ensuring proper encryption.

Key rotation policies reduce the impact of successful MITM attacks. Implement automatic key rotation with short lifespans (hours to days rather than months or years). Use refresh tokens or key versioning to maintain service availability during rotation.

Monitor for anomalous API key usage patterns that might indicate MITM attacks. Track geographic locations, request volumes, and timing patterns. Sudden changes in usage patterns could indicate key compromise.

Implement request signing to detect MITM modifications. Include cryptographic signatures in API requests that cover the payload and metadata. This ensures that even if an attacker intercepts and forwards requests, they cannot modify the content without detection.

const crypto = require('crypto');

function generateRequestSignature(apiKey, payload, timestamp) {
  const hmac = crypto.createHmac('sha256', apiKey);
  const message = `${timestamp}.${JSON.stringify(payload)}`;
  return hmac.update(message).digest('hex');
}

// Include signature in headers
const signature = generateRequestSignature(apiKey, data, Date.now());
axios.post(url, data, {
  headers: {
    'Authorization': `Bearer ${apiKey}`,
    'X-Request-Signature': signature,
    'X-Request-Timestamp': Date.now().toString()
  }

This signature allows the server to verify that requests haven't been tampered with during transit, providing protection against active MITM attacks.