There is a comfortable assumption most teams carry around, and it sounds like this, we use HTTPS everywhere, so tokens are safe in transit.

That assumption is wrong in more ways than most people realize, and each of those ways is a door an attacker can walk through.

HTTPS protects data between two endpoints, it does not protect data at the endpoints themselves, it does not survive a proxy that legitimately decrypts traffic, and it does not help at all when the attacker controls the device or the network path. Let me walk through how tokens actually get intercepted, and what you can do about it.

Important Disclaimer

This article is intended for educational and defensive purposes only, the techniques described here are shared to help security professionals understand emerging threats so they can better protect their systems.

Do not use these techniques against systems you do not own or do not have explicit written permission to test, unauthorized testing is illegal in most jurisdictions.

The author assumes no liability for any damages, legal consequences, or other outcomes resulting from the use or misuse of this information, always obtain proper authorization before conducting any security testing, and stay legal, stay ethical, stay responsible.

The Comfortable Assumption and Why It Fails

TLS gives you three things, confidentiality, integrity, and authentication of the server, those guarantees hold only as long as four conditions are true.

The endpoint is trustworthy, the certificate chain is valid and unbroken, the client actually validates the certificate, and the traffic is not being terminated and re originated somewhere in the middle.

Break any one of those four and the padlock icon keeps looking fine while the token walks out the door.

Interception Path 1: The Endpoint Owns the Plaintext

This is the most common and the most overlooked, when a browser or app sends a request, the token exists in plaintext inside the process before TLS encrypts it, and it exists in plaintext again after TLS decrypts it.

Anything running on that device with sufficient privileges can read it.

Malware can read browser memory, it can read local storage and cookie stores, it can hook cryptographic functions before encryption, it can even set an environment variable that lets the browser write its own TLS session keys to disk, once those keys land in a file, anyone with the capture can decrypt the traffic offline.

Malicious extensions are worse in some ways, they run inside the session with the same origin privileges the application has, no privilege escalation required.

The lesson here is blunt, TLS does not protect against a compromised endpoint, and most token theft in the wild happens at the endpoint, not on the wire.

Interception Path 2: Legitimate TLS Inspection

Enterprises deploy TLS inspection appliances for good reasons, they need to see inside encrypted traffic to catch malware and stop data exfiltration, and to do that they install a trusted root certificate on every managed device and decrypt traffic at the proxy.

This works, and it also means the proxy sees every token in cleartext.

That creates three problems.

• First, the proxy is now a high value target, if an attacker compromises it, they get a firehose of live tokens.
• Second, the proxy logs, and logs are copied, shipped, archived, indexed, and accessed by teams that did not intend to hold authentication material.
• Third, employee owned devices that are not managed do not trust the corporate root, so teams often push users to accept a certificate warning to reach internal resources, which trains users to click through the exact warning that protects them.

If you run TLS inspection, your tokens are only as safe as your proxy, your log pipeline, and your root certificate lifecycle.

Interception Path 3: Rogue or Installed Root Certificates

A root certificate in the trust store is a master key to every TLS connection that device makes.

Attackers know this, so a common post exploitation step is to install a root certificate, either through malware, through a mobile device management profile that a user approved without reading, or through a malicious configuration profile on a mobile device.

Once that root is trusted, the attacker can transparently proxy traffic and present certificates the client accepts without complaint, the padlock looks perfect, and every token passes through the attacker's hands.

This is also why a stolen or misissued certificate from a public certificate authority is so dangerous, it affects every device that trusts that authority, which is most of them.

Interception Path 4: Certificate Pinning Not Enabled or Bypassed

Mobile applications are the worst offenders in practice.

Many mobile apps either do not implement certificate pinning, or implement it poorly, without pinning, any proxy with a trusted root can decrypt the app's traffic and read the tokens, and testing tools exist that make this a two minute exercise for anyone with physical access to a test device.

Even with pinning, attackers with device access often bypass it, they patch the app, they hook the runtime with instrumentation frameworks, they modify the network security configuration on rooted or jailbroken devices, or they exploit the fact that many apps only pin to some endpoints and leave token refresh calls unprotected.

Pinning raises the bar, it does not close the door, especially on a device the attacker controls.

Interception Path 5: Tokens in the Wrong Places

HTTPS is irrelevant if the token leaks through a channel that is not HTTPS at all, or if it is stored somewhere that gets exfiltrated later.

Common leak channels include tokens placed in URL query strings, which then appear in proxy logs, browser history, referrer headers, and server access logs, tokens written into application logs and shipped to a logging platform with weaker access controls, tokens embedded in crash reports and error tracking systems, tokens included in analytics events and session replay recordings, and tokens passed through third party scripts on the page, which can read them directly.

A token in a URL is a token in every log along the path, and those logs are frequently readable by more people than anyone intended.

Interception Path 6: Compromised Network Path

TLS still holds against a passive network attacker in most configurations, so a random coffee shop Wi Fi is not the main risk anymore.

But active network attacks still exist, captive portals that ask you to install a profile, DNS hijacking combined with a misissued certificate, ARP spoofing combined with downgrade attempts against poorly configured clients, and malicious VPN or proxy services that terminate your TLS themselves.

The realistic threat here is not breaking TLS, it is convincing the client to trust the wrong endpoint.

Real Scenarios

Scenario 1: The Proxy Log Leak

The Setup

A company runs TLS inspection, everything is decrypted at the proxy, the proxy writes full request and response logs including headers to a centralized logging platform.

The Attack

A token appears in an Authorization header, it gets logged, the logging platform is accessible to a wider group of engineers than the identity system is, an attacker with access to that platform finds live tokens in the logs.

The Result

The attacker replays tokens against the identity provider and SaaS applications, no login alert fires because the tokens are valid.

The Lesson

Full request logging plus TLS inspection equals tokens in your logs, scrub authentication headers at the proxy before anything is written.

Scenario 2: The Malicious Mobile Profile

The Setup

An employee receives a message asking them to install a configuration profile to fix email sync issues, they approve it.

The Attack

The profile installs a root certificate and a proxy configuration, all traffic from the device now routes through an attacker controlled endpoint and is decrypted transparently.

The Result

Every token the device receives is captured, including refresh tokens for mail, file storage, and SaaS apps.

The Lesson

Root certificate installation is a privileged action, users should be trained to treat it as one, and mobile device management should control who can push profiles.

Scenario 3: The Mobile App Without Pinning

The Setup

A financial application uses OAuth, it stores the refresh token in the app's data directory, it does not pin certificates.

The Attack

An attacker with device access installs a proxy tool and its root certificate, opens the app, and captures the token refresh request in cleartext.

The Result

The attacker extracts a long lived refresh token and gains persistent access to the user's account.

The Lesson

Without pinning, any trusted root on the device can read your tokens, and on a device the attacker controls, the device is the threat model.

Scenario 4: The Token in the Query String

The Setup

A web application passes a session identifier in a URL parameter, because it made the initial integration with a partner service easier.

The Attack

The URL is written to the reverse proxy access log, the log is shipped to a third party observability platform, and a partner integration copies the URL into a support ticket.

The Result

The session identifier is now in at least four places, none of which are covered by the session revocation process.

The Lesson

Tokens belong in headers or cookies, never in URLs.

Defensive Controls That Actually Help

1. Treat the Endpoint as the Primary Threat Model

If the device is compromised, tokens will be stolen, plan for that instead of pretending otherwise, prefer short access token lifetimes so a stolen token is useful for minutes, not days.

2. Scrub Authentication Material Before It Is Logged

Configure your proxy, your reverse proxy, your application, and your observability pipeline to strip Authorization headers, cookies, and any token bearing fields before storage, verify it is actually happening.

3. Inventory and Monitor Root Certificates

Maintain a list of every root certificate installed on managed devices, alert on additions, remove stale enterprise roots, and treat any unexpected root as an incident.

4. Implement Certificate Pinning Where It Matters

Pin in mobile apps and in high value native clients, pin to the public key or the intermediate, not to a leaf certificate, and cover refresh endpoints as carefully as login endpoints.

5. Prefer Cookies With HttpOnly and Secure Over Local Storage

If a script cannot read the token, script based theft becomes much harder, pair that with SameSite settings appropriate to your flows.

6. Use Sender Constrained Tokens

Bind tokens to a cryptographic key the client holds, so that a stolen token cannot be used from a different machine, this is the single most effective control against replay after interception.

7. Enable Mutual TLS Where Feasible

For service to service and high value clients, client certificates make token replay from an unrelated device far harder.

8. Keep Tokens Out of URLs

No query parameters, no fragments, no path segments, headers or cookies only.

9. Monitor for Token Replay

Correlate token usage by IP, ASN, geography, device fingerprint, and user agent, alert on impossible travel and on sessions that survive password resets.

10. Shorten Refresh Token Lifetimes and Rotate Them

Rotate refresh tokens on every use where supported, detect reuse of an old refresh token as a signal that a token was stolen.

11. Provide a Fast Revocation Path

Know how to revoke sessions and refresh tokens per user, per client, and globally, and test it before you need it.

12. Consider Not Decrypting What You Do Not Need

TLS inspection has real value, it also creates real exposure, narrow the scope, avoid decrypting identity provider traffic if you can, and if you must, make sure nothing is logged.

Quick Reference: Interception Paths and Defenses

The Bottom Line

HTTPS is necessary and it is not sufficient, the padlock tells you the channel is encrypted, it does not tell you the endpoint is clean, it does not tell you the proxy is not logging, and it does not tell you the root store is intact.

Token interception happens at all three of those places, and the defense is not better encryption, the defense is reducing the value of a stolen token and reducing the number of places a token can be read.

Shorten lifetimes, bind tokens to keys, keep them out of URLs and logs, monitor how they are used, and know how to revoke them fast.

Encrypt the channel, then assume the token can still leak, and design for that world.

FAQ Section

Does HTTPS protect tokens in transit?

Yes, against a passive network attacker, but not against a compromised endpoint, a trusted proxy performing TLS inspection, or an installed rogue root certificate.

Why can a corporate proxy see my tokens?

Because it decrypts traffic to inspect it, the client trusts the enterprise root certificate, so the proxy can present its own certificate and read everything in cleartext.

What is certificate pinning and does it prevent token theft?

Pinning restricts which certificates the client will accept, it blocks interception through a trusted proxy, but it can be bypassed on a device the attacker controls.

Are tokens in URLs dangerous?

Yes, URLs are recorded in proxy logs, browser history, referrer headers, and server logs, a token in a URL leaks to every system that records the request.

What is the best defense against token replay after interception?

Sender constrained tokens that bind the token to a cryptographic key held by the client, so a stolen token cannot be used from another machine.

How quickly should I rotate tokens?

Access tokens should be measured in minutes, refresh tokens in hours to days at most, with rotation on every use where the platform supports it.

Sources:

OWASP

IETF

OWASP MASVS

MITRE ATT&CK