MCP OAuth consent page: CSP form-action blocks redirect back to claude.ai

[Mark-Milkis]

Summary

After clicking "Allow" on the MCP OAuth consent screen (/api/mcp/oauth/authorize), the page appears to hang — the browser never navigates back to the connecting client (tested with claude.ai as the MCP client).

Root cause

The app's Content-Security-Policy response header includes:

form-action 'self';

This blocks any cross-origin form submission/navigation target. If the consent-grant step redirects the browser back to the client's redirect_uri (e.g. https://claude.ai/api/mcp/auth_callback) via a client-rendered form rather than a server-side HTTP redirect (Location header on a 302/303 response), the browser silently blocks it under form-action 'self'.

Confirmed via server logs: the authorization is actually granted successfully server-side (mcp.oauth.authorize.granted), immediately followed by a CSP violation report hitting /api/monitoring/csp-report — but the browser never leaves the page.

Suggested fix

Either:

• Perform the consent-grant redirect as a real HTTP 302/303 response with a Location header (not subject to CSP form-action at all), or
• If a form-based redirect is intentional, dynamically include the specific client's registered redirect_uri origin in form-action for that response only.

Environment

• HealthLog latest (ghcr.io/mbombeck/healthlog), self-hosted via the documented docker-compose.
• Reproduced with claude.ai as the MCP client, standard OAuth 2.1 + PKCE dynamic client registration flow.
• Workaround in place on our end: a reverse-proxy response-header rewrite that widens form-action to also allow https://claude.ai — not a real fix, since it's specific to one known client and won't help other MCP clients (ChatGPT, etc.) hitting the same issue.

🤖 Generated with Claude Code

[MBombeck]

@Mark-Milkis thank you for tracking this down so precisely. You're right, and it's a bug on our side.

One detail, because it changes the fix: the consent step already answers with a real 302 and a Location header, straight from the server. The catch is that Chrome (and Edge) also apply form-action to a redirect that follows a form submit, while Firefox doesn't. Our consent page posts its form to its own origin, the server redirects to your client's redirect_uri, and Chrome drops that hop because the page carries form-action 'self'. So switching to a server redirect alone wouldn't help here.

The fix goes in the direction of your second idea, without naming any particular client. The consent page gets its own policy that allows exactly the redirect target the server has already checked against the registered client for that request (HTTPS or loopback), and nothing else. That way claude.ai, ChatGPT and desktop clients on a loopback address all work. I'm also switching the redirect after the form post to 303, which is what the current OAuth security guidance recommends, and adding a browser test that clicks Allow in Chromium and has to arrive at the callback.

It will ship with the next release. Until then your reverse-proxy rewrite is a reasonable workaround.

[MBombeck]

@Mark-Milkis v1.38.23 is out with the fix: https://github.com/MBombeck/HealthLog/releases/tag/v1.38.23

The consent page now allows exactly the return address it checked against the connecting client, so Allow takes Chrome and Edge back to claude.ai (and any other client) as it should. The redirect after the decision is a 303 now. Once you've updated, you can take the reverse-proxy rewrite out again.

There's a browser test that clicks Allow and has to arrive at the callback, so this shouldn't come back quietly. Thanks again for the precise report.