Skip to content
Web security Reviewed 2026-09-12

Cleartext Protocols

What does this mean ?

A cleartext transport sends information without channel encryption. A party able to observe or alter that network path may read or modify the traffic. Sensitive application traffic needs both encryption and verification of the intended peer; merely using a TLS-capable library does not establish those properties if certificate checks are disabled.

What can happen ?

Exposed passwords, session cookies or bearer tokens can permit impersonation. Unprotected responses can be modified before they reach a client. Network position and deployment boundaries affect exposure; “internal” should not be treated as proof that a channel is confidential.

Recommendation

Use HTTPS throughout authenticated browser sessions and API calls, with current TLS configuration and normal certificate/hostname validation. Mark session cookies Secure and HttpOnly and choose a suitable SameSite policy. Use HSTS for browser services after confirming HTTPS works across the intended scope. Review transport beyond the public edge, including proxy-to-origin, database and mail connections.

Configure STARTTLS clients to fail when encryption is unavailable if the channel carries sensitive data. Do not accept all certificates to work around a trust-store problem; configure the correct CA trust. Bound redirects so a protected request cannot silently fall back to HTTP or forward credentials to another service.

Hashing a credential and placing it in a cookie does not encrypt the channel; the hash may itself become a replayable credential. Do not store a remembered password in a browser cookie, even encrypted. Use a revocable server-managed session. Encoding arbitrary ciphertext as UTF-8 is also not a transport-security control.

Sample Code

These helpers reject an insecure operator-configured API endpoint before the client is created. They do not perform requests. Use the validated endpoint only with a client that verifies certificates and rejects unsafe redirects. Do not adapt them into an arbitrary user-URL fetch feature without SSRF controls.

from urllib.parse import urlsplit

def require_https_endpoint(value: str) -> str:
    parsed = urlsplit(value)
    if parsed.scheme.lower() != "https" or not parsed.hostname:
        raise ValueError("An absolute HTTPS endpoint is required")
    if parsed.username is not None or parsed.password is not None:
        raise ValueError("Do not embed credentials in endpoint URLs")
    return value

Keep the HTTP library's certificate verification enabled. Configure credentials separately and never include them in logs.

function requireHttpsEndpoint(value) {
  const endpoint = new URL(value);
  if (endpoint.protocol !== 'https:' || !endpoint.hostname) {
    throw new Error('An absolute HTTPS endpoint is required');
  }
  if (endpoint.username || endpoint.password) {
    throw new Error('Do not embed credentials in endpoint URLs');
  }
  return endpoint;
}

Do not set rejectUnauthorized: false or disable Node TLS verification. For a fetch that does not require redirects, use redirect: 'error'.

static Uri RequireHttpsEndpoint(string value)
{
    if (!Uri.TryCreate(value, UriKind.Absolute, out var endpoint) ||
        endpoint.Scheme != Uri.UriSchemeHttps || string.IsNullOrEmpty(endpoint.Host))
        throw new ArgumentException("An absolute HTTPS endpoint is required");
    if (!string.IsNullOrEmpty(endpoint.UserInfo))
        throw new ArgumentException("Do not embed credentials in endpoint URLs");
    return endpoint;
}

Retain the default server-certificate checks. Do not attach a callback that always returns true.

static java.net.URI requireHttpsEndpoint(String value) {
    var endpoint = java.net.URI.create(value);
    if (!"https".equalsIgnoreCase(endpoint.getScheme()) || endpoint.getHost() == null) {
        throw new IllegalArgumentException("An absolute HTTPS endpoint is required");
    }
    if (endpoint.getRawUserInfo() != null) {
        throw new IllegalArgumentException("Do not embed credentials in endpoint URLs");
    }
    return endpoint;
}

Retain the configured trust manager and hostname verification. A custom trust manager accepting every peer defeats TLS authentication.

Regression checks

Unit-test that HTTPS configuration is accepted and HTTP, relative URLs and embedded credentials are rejected. In a local TLS fixture, verify a certificate from the configured test CA succeeds while an untrusted certificate or wrong hostname fails. Test redirect behavior separately. Inspect test responses for Secure cookies and ensure no password or token appears in URLs or logs. Do not disable certificate checks to make the test pass.

References