Fix Cursor: pass cursor.com's CSRF origin check (v0.2.1) - #10
Merged
Conversation
First live test on a real account: cookies attach fine, but cursor.com rejects the extension's POSTs with 403 'Invalid origin for state-changing request' because extension requests carry a chrome-extension:// Origin. (Claude and Codex use GETs, which is why only Cursor hit this.) Adapters can now declare originOverride; a declarativeNetRequest session rule sets the Origin header to the provider's own origin on requests matching its API prefix — scoped via initiatorDomains to requests initiated by THIS extension only, so no other page's traffic is touched and the provider's CSRF protection stays intact for everyone else. Rules re-sync on startup/install (session rules don't survive restarts) and on every provider toggle. Requires declarativeNetRequestWithHostAccess (no warning prompt; acts only on user-granted hosts); justification added to the store listing and privacy policy. Version 0.2.1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
First live test of the Cursor adapter on a real logged-in account: the session cookie attaches correctly, but cursor.com answers the extension's POSTs with 403
{"error":"Invalid origin for state-changing request"}— extension-initiated requests carryOrigin: chrome-extension://…, and Cursor's CSRF guard only accepts its own origin. Claude and Codex use GETs, which is why only Cursor hit this.The fix
Adapters can now declare
originOverride. AdeclarativeNetRequestsession rule sets theOriginheader to the provider's own origin on requests matching its API prefix, with two deliberate scopes:initiatorDomains: [chrome.runtime.id]— the rule applies only to requests initiated by this extension. Other pages' requests to cursor.com are untouched, so Cursor's CSRF protection is not weakened for anything else.declarativeNetRequestWithHostAccess— the new permission carries no install warning and acts only on hosts the user has already granted at enable-time.Rules re-sync on startup/install (session rules don't survive browser restarts) and on every provider toggle or data wipe. Justification text added to
docs/store/listing.md(needed for the next store upload) and the privacy policy page.Verification
npm run cigreen: 71 tests — new suite covers rule creation/scoping for enabled providers, removal on disable, no-rules for Claude/Codex, and graceful no-op when the API is unavailable.git pull && npm run build, reload the extension, toggle Cursor off and on — the card should populate. (The live 403 was reproduced and diagnosed from the reporter's service-worker capture; the header rewrite addresses exactly the check in the error message.)Version 0.2.1.
Generated by Claude Code