Home / Knowledge hub / Encryption in transit
Knowledge hub
Encryption in transit
Protecting data while it travels between a browser and your servers.
What it means
Encryption in transit protects data while it travels between a browser and your servers. In practice that means TLS, the protocol behind the padlock, specified by the IETF and now in its 1.3 version.
TLS stops anyone in between reading or changing what passes. It says nothing about either end, where the data gets handled, stored, and shown to whoever asked for it.
Why it matters
This is a baseline, not an achievement. Browsers warn on pages without it and customers assume it without asking. Getting it right avoids a visible failure rather than earning you any credit.
Everything else leans on it, which is the better reason to care. Session tokens, passwords, reset links and API keys all travel over these connections, so one unprotected path undoes careful work everywhere else. It is also one of the few areas where the check is quick, the fix is well understood, and nobody argues about whether it is worth doing.
How it shows up
The gaps sit behind the front door rather than at it. Internal calls between your own services on plain connections. A redirect from an unencrypted address that still carries a token in the URL. An old subdomain with an expired certificate. A mobile app that accepts any certificate because somebody disabled the check during development and never re-enabled it.
Also check two quiet ones. Cookies without the secure flag. And anything sensitive passed in a query string, where it lands in logs and browser history whatever else you do. MITRE catalogues this as cleartext transmission of sensitive information. See HTTPS.
Questions people ask
Encryption in transit, answered
Does HTTPS mean our data is safe?
It means the journey is protected. Nobody on the network in between can read or alter the traffic.
It says nothing about what happens once the request arrives. Every access control bug, injection flaw and leaked export happens over a perfectly good TLS connection.
Do we need TLS between our own internal services?
Yes, in almost every modern setup. A private network is not a trusted network once anything else runs on it, and the traffic between your services often carries the most sensitive material you hold.
Mutual TLS also gives you authentication between services, which is worth having on its own.
Is TLS 1.2 still acceptable?
Yes, for compatibility. OWASP's guidance is to default to TLS 1.3 and support 1.2 where you must, while disabling everything older.
If you still accept TLS 1.0 or 1.1, that is the finding, and turning them off is usually a configuration change rather than a project.
Do we need to encrypt traffic inside a VPC?
Treat the VPC as a boundary, not as a guarantee. A compromised container, a misconfigured peering link or a noisy logging sidecar all sit inside it.
The cost of encrypting internal calls is low now. The cost of explaining why you did not is high.
Does our mobile app need certificate pinning?
It helps against an attacker who can install a certificate on the device, which mostly matters for high-value apps like banking.
The more common problem is the opposite one. Teams disable certificate validation entirely to make local testing work, then ship it. Check that before you consider pinning.
Related
Terms that sit next to this one
HTTPS
The encrypted web protocol, and the minimum for anything with a login.
Encryption at rest
Stored data scrambled so a stolen disk is useless without the key.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Token
A string that stands in for an identity or a permission.
TLS on, tokens in the address bar?
We look at what travels and where it lands: tokens in addresses, cookies missing flags, redirects that leak a session. Each finding comes with its request. Ask us to check one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.