CWE-319 in APIs
- CWE ID
- CWE-319
- Category
- Encryption
- Severity
- HIGH
- Short Name
- Cleartext Transmission
What is Cwe 319?
Cwe 319, officially titled "Cleartext Transmission of Sensitive Information," describes a fundamental security weakness where sensitive data is transmitted over unencrypted channels. This allows attackers who can intercept network traffic—through methods like man-in-the-middle attacks, packet sniffing, or compromised network infrastructure—to read the data in its raw, unprotected form.
The weakness occurs when applications fail to implement proper encryption for data in transit. Instead of using secure protocols like HTTPS/TLS, they transmit sensitive information (credentials, personal data, financial details, API keys) over HTTP, unencrypted email, or other cleartext channels. The data remains readable to anyone with network access, completely bypassing any authentication or access controls that might exist at the application layer.
This weakness is particularly dangerous because it renders other security controls ineffective. Even if an API has robust authentication, proper authorization, and secure coding practices, cleartext transmission exposes all that data to anyone monitoring the network. The attacker doesn't need to compromise the application itself—they only need to be in the right network position to capture the traffic.
Cwe 319 in API Contexts
APIs face unique Cwe 319 risks due to their networked nature and the sensitive data they routinely handle. API endpoints often transmit authentication tokens, API keys, personal identifiable information (PII), and business-critical data between clients and servers. When these transmissions occur over unencrypted channels, the entire API's security model breaks down.
Common API manifestations include:
- API endpoints accessible via HTTP instead of HTTPS, exposing request/response payloads
- Authentication headers (Bearer tokens, API keys) sent over cleartext
- API documentation or specification files (Swagger/OpenAPI specs) served without TLS
- Callback URLs or webhook endpoints configured to use HTTP
- API responses containing sensitive data transmitted without encryption
The risk extends beyond just the API endpoint itself. Many APIs integrate with third-party services, making HTTPS-to-HTTP downgrades particularly dangerous. An attacker performing a man-in-the-middle attack could intercept API calls, steal credentials, and potentially pivot to compromise connected services or internal systems.
Mobile and IoT API clients are especially vulnerable since they often connect through untrusted networks (public Wi-Fi, cellular networks) where traffic interception is trivial. Without proper encryption, every API call becomes a potential data breach waiting to happen.
Detection
Detecting Cwe 319 requires examining both the API's configuration and its actual runtime behavior. The most straightforward detection method is attempting to access API endpoints over HTTP. If an endpoint responds to HTTP requests or redirects from HTTPS to HTTP, it indicates a configuration issue that could expose sensitive data.
middleBrick's scanning approach tests the unauthenticated attack surface by attempting to access API endpoints and analyzing their security posture. The scanner checks whether endpoints enforce HTTPS, examines response headers for security configurations, and attempts to interact with the API to observe data transmission patterns. For LLM/AI endpoints specifically, middleBrick tests whether system prompts or sensitive model configurations are transmitted without proper encryption.
Additional detection techniques include:
- Network traffic analysis using tools like Wireshark to capture and inspect API communications
- SSL/TLS certificate validation to ensure proper encryption is configured
- HTTP security header analysis (HSTS, Content-Security-Policy) to verify HTTPS enforcement
- API specification analysis to identify endpoints that should require encryption but don't
middleBrick's parallel scanning architecture tests 12 security categories simultaneously, including encryption verification. The scanner provides a security risk score (A–F) based on findings, with Cwe 319 violations typically resulting in significant score deductions due to their severity. The tool also generates actionable findings with specific remediation guidance for each detected issue.
Remediation
Remediating Cwe 319 requires implementing proper encryption for all API communications. The foundation is enforcing HTTPS everywhere—every API endpoint, every subdomain, every callback URL. This means configuring web servers to redirect all HTTP traffic to HTTPS and setting up proper TLS certificates.
Frequently Asked Questions
Can Cwe 319 be exploited even if my API has strong authentication?
Yes, absolutely. Cwe 319 vulnerabilities bypass authentication entirely because they exploit the transport layer, not the application layer. Even with perfect authentication mechanisms, cleartext transmission exposes all data to anyone monitoring the network. An attacker doesn't need valid credentials—they just need to intercept the traffic. This is why encryption is considered a fundamental requirement, not an optional enhancement.Are internal APIs safe from Cwe 319 since they're not exposed to the internet?
No, internal APIs are still vulnerable. Internal networks can be compromised through various attack vectors including insider threats, supply chain attacks, or network infiltration. Additionally, many organizations use cloud services where traffic may traverse shared infrastructure. The principle of defense in depth means all API communications should be encrypted regardless of perceived network boundaries. middleBrick's scanning can help identify internal APIs that lack proper encryption.