Skip to content

Allow OAuth provider hosts in CSP form-action#28

Merged
murbard merged 1 commit into
mainfrom
fix/csp-oauth-form-action
Jun 18, 2026
Merged

Allow OAuth provider hosts in CSP form-action#28
murbard merged 1 commit into
mainfrom
fix/csp-oauth-form-action

Conversation

@murbard

@murbard murbard commented Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

Operator clicks Re-authenticate on a Gmail connection and nothing happens. The browser console reports:

Sending form data to 'http://localhost:19816/connections/tf-gmail/reauth' violates the following Content Security Policy directive: "form-action 'self'". The request has been blocked.

Root cause: CSP's form-action 'self' covers both the initial form target AND any redirects from that submission. The POST to /connections/{id}/reauth is same-origin (allowed), but the 302 → accounts.google.com is cross-origin (blocked). Same issue applies to Slack OAuth (slack.com) and the GitHub App manifest/install flows (github.com).

Fix

Extend form-action to include the three OAuth-provider hosts. Pin them with TestCSPAllowsTemplateCDNs so a future tightening that drops one will fail loudly.

Risk

Minimal. form-action only constrains where forms can submit; the addition is exactly the set the existing OAuth flows already need. A future connector that posts to a new OAuth host will need this directive extended — explicitly noted in the directive's comment.

Test plan

  • Click Re-authenticate on a Gmail connection in reauth_required → browser navigates to accounts.google.com/o/oauth2/... instead of being blocked.
  • Slack workspace install / re-install still works.
  • GitHub App install/create flow still works.

🤖 Generated with Claude Code

The CSP's form-action directive is `'self'` only, which blocks the
302 redirect from /connections/{id}/reauth (and similar OAuth-install
flows) to accounts.google.com / slack.com / github.com. The browser
reports:

  Sending form data to '...' violates the following Content Security
  Policy directive: "form-action 'self'". The request has been blocked.

…and the operator sees nothing happen on click. form-action covers
both the initial POST target AND any redirects from that submission,
so same-origin POST → cross-origin 302 hits the directive even though
the POST itself is same-origin.

Add the three OAuth-provider hosts to form-action and pin them with
TestCSPAllowsTemplateCDNs. The list is intentionally minimal — a
future connector that posts to a new OAuth host will need this
directive updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the admin UI Content Security Policy (CSP) to allow OAuth provider origins in the form-action directive so form submissions that receive cross-origin 302 redirects (e.g., /connections/{id}/reauthaccounts.google.com) are not blocked by the browser.

Changes:

  • Extend CSP form-action to include Google, Slack, and GitHub OAuth/provider hosts.
  • Add test assertions to ensure these hosts remain allowlisted under form-action going forward.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
internal/web/headers.go Adds an oauthHosts allowlist and appends it to the CSP form-action directive.
internal/web/csp_test.go Extends the CSP regression test to require the OAuth provider hosts under form-action.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@murbard murbard merged commit 1897235 into main Jun 18, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants