Unprotected Transport of Credentials

Credentials (a password, an API key, a session token) are transmitted over a channel that doesn't adequately protect them in transit - plain HTTP instead of HTTPS, or a protocol/channel with no encryption at all - letting anyone positioned on the network path between client and server passively capture them.

Whether a connection uses HTTPS at all, and whether HTTPS is actually enforced (rather than merely available alongside an unencrypted option), is externally observable and already tested as part of baseline transport-security auditing.

Checking whether a target requires HTTPS and correctly signals that requirement to browsers through HSTS covers the externally verifiable transport-security question this category depends on.

Tip: This class is typically found by intercepting traffic with a controlled proxy and observing whether the client actually rejects an invalid, expired, wrong-hostname, or revoked certificate — a passive traffic capture on a supposedly encrypted internal link is the other common discovery path, for the plaintext-transport variant specifically.

Real-World Impact

Man-in-the-middle exposure, broken certificate-chain validation, and credentials sent over an unprotected transport all share the same underlying failure: the connection isn't actually providing the confidentiality and authenticity guarantee the application assumes it is. An attacker positioned on the network path, a compromised Wi-Fi access point, a malicious proxy, a rogue router, can intercept or tamper with traffic that the application believes is safely encrypted end-to-end.

Once that trust assumption is broken, everything the connection carries is exposed: credentials, session tokens, and any sensitive data moving in either direction, with no obvious indication to the user that anything is wrong, since a partially-broken TLS setup can still display as "secure" in a browser depending on exactly what failed.

Certificate-revocation checking gaps are a related but narrower failure: even a properly-validated certificate chain doesn't help if the client never checks whether a certificate was revoked after a private key compromise, which means a stolen and revoked certificate can still be accepted as valid.

Prevention and Secure Design

Preventing Unprotected Transport of Credentials takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Enforce TLS everywhere, with no fallback to plaintext. Every connection carrying credentials or sensitive data — including internal, service-to-service traffic — should require TLS with no unencrypted fallback path.

Validate the full certificate chain, hostname, and revocation status. Chain trust alone isn't sufficient — confirm the hostname matches and check revocation status (OCSP or a current CRL) rather than assuming a presented certificate is still valid just because it was once issued correctly.

Use HSTS to prevent protocol downgrade. HTTP Strict Transport Security tells browsers to never attempt an unencrypted connection to your domain, closing off a common downgrade-attack vector.

Never disable certificate or transport validation, even temporarily. A validation bypass added for debugging or local development is one of the most common ways this class ends up shipped to production.

Pin certificates for high-value, first-party connections. For a mobile app or service talking to its own backend, pinning adds a layer beyond standard CA trust, at the cost of needing a clear certificate-rotation plan.