Protect data in transit

TLS protects a connection from passive reading and tampering, as long as certificate validation succeeds. That last clause carries all the weight.

Use HTTPS for the whole application, not only the login page. Every request carries the session cookie, so one plaintext page is enough to steal an authenticated session on a hostile network.

What TLS does not do

TLS is a transport guarantee, nothing more. It does not authorize the signed-in user, validate application input, or protect data after the endpoint decrypts and processes it. A perfectly encrypted connection will happily deliver a forged request or a malicious payload.

And it authenticates endpoints, not intentions. TLS proves you are talking to the server named by the certificate. It does not prove the signed-in user may reset another account. Authorization is a separate control for a reason.

The second hop

Here is where real systems leak. The browser uses HTTPS, but the application sends reset requests to an internal email service over plaintext HTTP:

browser --HTTPS--> app server --HTTP--> internal email service
                               ^ reset tokens cross here in plaintext

The secure browser connection does not protect that second hop. Anyone who can observe internal traffic — a compromised container on the same network, a misconfigured switch port — reads live reset tokens. Internal service traffic can carry sensitive data too. “It’s inside our network” is an assumption, not a control.

Trace one sensitive flow, like a password reset, across every network hop. For each hop, capture the scheme and the certificate result:

curl -sv https://mail.internal.example.com/send 2>&1 | grep "SSL certificate verify"
# SSL certificate verify ok.

Fail closed, never fall back

The most dangerous TLS bug is the quiet fallback: code that retries over plain HTTP when the handshake fails, or an HTTP client configured to skip certificate verification “temporarily.” Both convert a visible outage into an invisible leak.

Break certificate validation on purpose in a test environment — point the client at a host with a self-signed certificate — and require the request to fail closed with an error. If the data goes through anyway, you found a fallback path that an attacker with network position can trigger whenever they want.