fix(security): require Authorization header for streamable HTTP server [DEVX-806]

[geethanga-ct]

Summary

Fixes the insecure auth fallback reported in DEVX-806 / Cure53 COM-15-004 (High). When the MCP server runs in remote/streamable HTTP mode (--remote=true), the /mcp handler treated the Authorization header as optional and fell back to the server's startup/system credentials. An unauthenticated network caller could therefore be served with the same privileges as the configured token.

This makes the streamable HTTP server a strict pass-through: every request must present its own commercetools bearer token, which is forwarded directly to the commercetools API. The startup credentials are no longer used to serve network requests.

What changed

• streamable.ts
  • Added extractBearerToken() — structural validation of Authorization: Bearer <non-empty-token> (case-insensitive scheme).
  • POST /mcp returns 401 Unauthorized immediately when the header is missing/malformed, before any commercetools call — no fallback to config credentials.
  • Builds a per-request auth config with forced type: 'auth_token', so the caller's token is the one forwarded to the CT API. This also fixes a latent bug where a server started with client_credentials silently ignored the per-request header token.
  • Stopped mutating the shared this.authConfig (one request's token could leak into others); getServer() now accepts a per-request authConfig, threaded through stateless and stateful paths.
  • GET /mcp gets the same auth guard.
• configuration.ts — added optional enforceAuthHeader?: boolean (defaults true) to IStreamServerOptions, so SDK embedders who handle auth via an injected server factory can opt out.
• README.md — documented the mandatory Authorization: Bearer <token> requirement, the pass-through behavior, and the enforceAuthHeader opt-out.
• Changeset — minor bump for @commercetools/commerce-agent and @commercetools/commerce-mcp.

Migration

Clients connecting to a remote server (e.g. via mcp-remote) must now send an Authorization: Bearer <commercetools-access-token> header on every request. stdio mode is unaffected.

Testing

• streamable suite: 28/28 pass (new cases: 401 on missing/malformed header, forwarded-token, enforceAuthHeader: false opt-out, GET auth).
• Full agent test suite: 1627/1627 pass.
• Lint + prettier clean; agent and processors packages build successfully.

End-to-end (reproduces the exploit)

# (A) No Authorization header -> 401 (was 200 + served with startup creds before fix)
curl -i -X POST http://localhost:8888/mcp \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":"1","method":"tools/list"}'

# (B) With Bearer header -> passes the gate; token forwarded to the CT API
curl -i -X POST http://localhost:8888/mcp \
  -H "Authorization: Bearer SOME_TOKEN" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":"1","method":"tools/list"}'

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: fe214b7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@commercetools/commerce-agent	Major
@commercetools/commerce-mcp	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ajimae]

🚀