Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.

Add an HSTS header to your MCP endpoint

What we checked

We read the response headers from your endpoint and looked for an HTTP Strict Transport Security header:

The HSTS (Strict-Transport-Security) header is present.
HSTS check failed: the Strict-Transport-Security header is absent.
HSTS not yet verified: we couldn't read the response headers to check for it.

Why it matters

HSTS tells clients “from now on, only ever reach me over HTTPS.” Once a client has seen the header, it refuses to make a plaintext connection to your host at all (even if a user or a tampered link tries to), which closes the small window between the first plaintext request and your HTTPS redirect. It’s a cheap, one-line hardening step that turns “we redirect to HTTPS” into “plaintext is never attempted.” The remote rubric credits the header as part of your endpoint’s transport hardening.

How to fix it

Send a Strict-Transport-Security response header over HTTPS. A sensible value is max-age=31536000; includeSubDomains (one year). Add preload only when you’re certain: see the caution below.

server {
  listen 443 ssl;
  server_name mcp.example.com;
  # ssl_certificate / ssl_certificate_key omitted - see the TLS guide.

  # 'always' ensures the header is sent on error responses too.
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

  location /mcp {
      proxy_pass http://localhost:3000;
  }
}

How we re-check

We re-read your response headers on our next crawl. Once a Strict-Transport-Security header is returned over HTTPS, the check passes on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt
Context: this repository (or its infrastructure) runs a remote MCP server
at an HTTPS endpoint. VerifyMCP's HSTS check failed, which means HTTPS
responses don't carry a `Strict-Transport-Security` header, so a client
that lands on `http://` for this host even once could still be intercepted
before any redirect happens.

Goal: HTTPS responses, including error paths, return a
`Strict-Transport-Security` header, so the next crawl records the header
as present.

Do this:
1. Confirm HTTPS already works reliably on the apex, and on every
   subdomain if you plan to use `includeSubDomains`, since HSTS enforces
   that before anyone checks it.
2. Start with a short `max-age` (for example `max-age=86400`, one day)
   rather than a year, so a misconfiguration is cheap to recover from
   while few clients have cached it.
3. Add the header at the edge or app layer over HTTPS only, for example
   Nginx's `add_header Strict-Transport-Security "max-age=86400" always;`,
   Caddy's `header Strict-Transport-Security ...`, or an Express
   middleware setting it on every response.
4. Once the short `max-age` has run cleanly for a while, raise it towards
   `max-age=31536000; includeSubDomains`.
5. Only consider `preload` once `includeSubDomains` is stable across every
   subdomain and HTTPS-only is a permanent commitment; see Rules first.

Rules:
- Do not add `preload` or submit the domain to the HSTS preload list
  without explicit confirmation from the human first: it is very hard to
  reverse and can lock browsers out of the apex and every subdomain over
  plaintext HTTP indefinitely, including ones that weren't ready.
- Don't jump straight to a long `max-age` or `includeSubDomains` before
  confirming every affected host actually serves valid HTTPS; a mistake
  here stays cached by clients for as long as the `max-age` says.
- Never set the header on a plaintext response, it has no effect there.

Report back: the files changed, the `max-age` you chose and why, and
`curl -sI https://<host>/` showing the `Strict-Transport-Security` header
in the response.

Reference: https://verifymcp.io/docs/remote/hsts

Written by Stuart Blackler · Last reviewed 30 June 2026.