Man In The Middle in APIs

Man In The Middle (MITM) is an attack where an adversary intercepts and potentially alters communications between two parties without their knowledge. In API contexts, this typically involves an attacker positioned between a client and server, able to read, modify, or inject traffic.

The attack exploits the fundamental nature of network communications. Without proper encryption and authentication, any intermediate node on the network path can intercept traffic. Common MITM scenarios include:

• Public Wi-Fi networks where traffic is unencrypted
• Compromised routers or network devices
• DNS spoofing that redirects traffic to malicious servers
• ARP poisoning on local networks

The core vulnerability is the absence of cryptographic protection. When APIs communicate over HTTP instead of HTTPS, or when TLS implementations are weak, attackers can capture sensitive data including authentication tokens, API keys, personal information, and business logic.

APIs are particularly vulnerable to MITM attacks because they often handle sensitive operations and data. When an attacker successfully positions themselves between a client and API server, they can achieve several malicious objectives:

• Data Theft: Capture API keys, authentication tokens, personal data, and business information in transit
• Data Manipulation: Modify request parameters to alter API behavior, such as changing transaction amounts or user permissions
• Session Hijacking: Steal session cookies or JWT tokens to impersonate legitimate users
• Credential Harvesting: Capture login credentials sent over unencrypted connections
• Business Logic Abuse: Manipulate API calls to bypass rate limiting, access unauthorized resources, or trigger unintended workflows

Real-world impact varies by industry. Financial APIs transmitting payment information are prime targets. Healthcare APIs handling PHI face HIPAA violations. E-commerce APIs processing transactions risk direct financial loss. The common thread is that MITM attacks exploit the trust between client and server when that trust isn't cryptographically enforced.

Detecting MITM vulnerabilities requires examining both network configuration and API implementation. Key indicators include:

• HTTP Endpoints: APIs accessible over plain HTTP instead of HTTPS
• Weak TLS: Support for outdated protocols (SSLv2, SSLv3), weak ciphers, or missing certificate validation
• Certificate Issues: Self-signed certificates, expired certificates, or certificates from untrusted authorities
• Missing HSTS: Absence of HTTP Strict Transport Security headers that enforce HTTPS connections
• Certificate Pinning Absence: Mobile apps or clients that don't verify server certificates against known good values

How middleBrick Detects MITM Vulnerabilities: The scanner tests API endpoints for encryption weaknesses by attempting connections over various protocols and examining certificate configurations. It checks whether endpoints accept HTTP connections, identifies weak TLS configurations, and verifies certificate validity. The scanner also looks for missing security headers that would help prevent MITM attacks in browsers or mobile clients.

For LLM/AI APIs specifically, middleBrick tests whether AI endpoints enforce encryption and proper authentication, as these often handle sensitive prompts and training data that could be compromised through MITM attacks.

Preventing MITM attacks requires a defense-in-depth approach with proper encryption and authentication controls:

1. Enforce HTTPS Everywhere

// Nginx configuration - force HTTPS
server {
    listen 80;
    server_name api.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # Modern TLS configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

2. Implement Certificate Pinning (Mobile/Web Clients)

// iOS example using URLSession
let session = URLSession(configuration: .ephemeral)
let delegate = SessionDelegate()
session.delegate = delegate

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
        // Pin to specific certificate fingerprint
        if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust {
            if let serverTrust = challenge.protectionSpace.serverTrust {
                // Verify certificate matches expected fingerprint
                if verifyCertificate(serverTrust) {
                    completionHandler(.useCredential, URLCredential(trust: serverTrust))
                } else {
                    completionHandler(.cancelAuthenticationChallenge, nil)
                }
            }
        }
    }
}

3. Add Security Headers

// HTTP response headers
response.headers['Strict-Transport-Security'] = 'max-age=31536000; includeSubDomains'
response.headers['Content-Security-Policy'] =