State that remote MCP endpoints use HTTPS, that session IDs are random and never used to authenticate anyone, that every request is authorised independently, and that local servers are not exposed on the network. Those four sentences cover most transport and session questions reviewers ask.
What the specifications say
The MCP authorization specification says all authorization server endpoints must be served over HTTPS, and redirect URIs must be localhost or HTTPS. The security guidance says servers must not use sessions for authentication and must use secure, non-deterministic session IDs. It describes session hijack attacks when several stateful servers handle requests: an attacker who obtains a session ID can inject events, which may reach a client as if they came from the real server.
You will hear reviewers echo these points.
Four statements to make
1. Encryption in transit. "Remote MCP endpoints are served over HTTPS only. Redirects to HTTP are refused."
2. Session handling. "Session identifiers are random, not guessable, and bound to the authenticated user. They are not used as proof of identity."
3. Per request authorisation. "Every request carries a token that we validate for the intended audience. Losing or guessing a session ID does not grant access."
4. Local exposure. "Local servers listen on loopback only and are not reachable from other machines."
If you run multiple server instances behind a load balancer, add how you protect session state. Binding the session to a user, and rotating identifiers, limits what a stolen ID can do.
Common mistakes that questionnaires uncover
| Mistake | Why it hurts |
|---|---|
| Treating the session ID as a login | Anyone with the ID acts as the user |
| Predictable identifiers | Guessing becomes possible |
| HTTP on internal networks | Traffic can be read by anything on the path |
| Local server bound to all interfaces | Reachable by other devices |
| Tokens in query strings | Appear in logs and history |
See why a session ID is not authentication for a longer treatment.
Server side hygiene to mention
The MCP tools specification says servers must validate all tool inputs, implement access controls, rate limit tool invocations and sanitize tool outputs. Pair the transport answer with those so the reviewer sees defence in depth rather than a single lock on the door.
A note on client side requests
Clients that fetch metadata URLs during OAuth discovery can be steered to internal addresses if a malicious server controls the URL. The security guidance calls this server side request forgery and recommends controls. If you build a client, say what you do about it. See SSRF defences in MCP clients.
Evidence
A configuration excerpt showing HTTPS only, the session ID generation approach, and a test result showing a request with only a session ID is refused. Safeguard's free scan and API security scan demos show the kind of check that supports this evidence.
Quick check
Is HTTPS enough?
It protects data in transit but says nothing about who is allowed in. Pair it with token validation and scoped access.
Do stdio servers have transport security?
They use the process pipe between client and server, not the network. The risk shifts to what the process can do on the machine.
Sources
Last reviewed: 19 October 2026.
