Revert "fix(execute): block cross-origin session-authenticated workfl…

[TheodoreSpeaks]

…ow runs (#5062)"

This reverts commit 67e02fa.

Summary

Brief description of what this PR does and why.

Fixes #(issue)

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

How has this been tested? What should reviewers focus on?

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 15, 2026 7:54pm

[cursor]

PR Summary

High Risk
Removes browser-oriented CSRF protection on a state-changing workflow execution endpoint for session auth, increasing exposure to cross-site triggered runs unless other mitigations fully cover that surface.

Overview
Reverts the workflow execute cross-origin session CSRF protection added in #5062.

The isCrossOriginSessionRequest helper and its unit tests are deleted. POST /api/workflows/[id]/execute no longer returns 403 Access denied when a session-cookie request looks cross-origin (Sec-Fetch-Site / Origin checks). Session-authenticated runs again follow the same path as before that guard (auth, authorization, billing, and rate limits unchanged).

The async route test that asserted early rejection on Sec-Fetch-Site: cross-site is removed with the behavior.

^{Reviewed by Cursor Bugbot for commit 148e4b8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR reverts #5062, which added a Sec-Fetch-Site/Origin-header-based CSRF guard on the workflow execute endpoint. The revert deletes the same-origin.ts utility, its tests, and the in-route guard that rejected session-authenticated requests proven to be cross-origin.

• route.ts: The isCrossOriginSessionRequest guard (scoped to AuthType.SESSION only) is removed, leaving no origin-validation step for session-cookie callers on this state-changing endpoint.
• same-origin.ts + same-origin.test.ts: The helper and its full unit-test suite are deleted entirely.
• route.async.test.ts: The integration test asserting cross-origin session requests get a 403 is removed alongside the code it covered.

Confidence Score: 3/5

Not safe to merge without a documented rationale or a replacement CSRF control — the change leaves the session-authenticated workflow execute endpoint unprotected against cross-origin browser-driven requests.

The revert removes the only origin-header check on a state-changing endpoint for session-cookie callers, and the PR description provides no explanation of what went wrong with the original fix or what alternative protection exists.

apps/sim/app/api/workflows/[id]/execute/route.ts — the removed guard is the only origin validation for session-authenticated execution requests.

Security Review

• CSRF on workflow execution (session auth) — Removing the isCrossOriginSessionRequest check means a cross-origin page can now trigger POST /api/workflows/[id]/execute with a user's session cookie attached by the browser. The deleted guard was the only origin-header check protecting this mutation endpoint for session-authenticated callers. Non-session callers (API key, public API, internal JWT) were unaffected by the original guard and remain unaffected by the revert. No replacement CSRF control is visible in the diff.

Important Files Changed

Filename	Overview
apps/sim/app/api/workflows/[id]/execute/route.ts	Removes the isCrossOriginSessionRequest CSRF guard that blocked cross-origin browsers from triggering session-authenticated workflow execution; no alternative protection is introduced.
apps/sim/lib/core/security/same-origin.ts	Deleted entirely — this was the isCrossOriginSessionRequest utility that checked Sec-Fetch-Site and Origin headers to detect cross-origin browser requests.
apps/sim/lib/core/security/same-origin.test.ts	Deleted test suite for the removed isCrossOriginSessionRequest utility — no issues beyond the loss of coverage.
apps/sim/app/api/workflows/[id]/execute/route.async.test.ts	Removes the integration test asserting that cross-origin session requests receive a 403 — consistent with the revert but loses the regression guard.

Sequence Diagram

sequenceDiagram
    participant Attacker as evil.example.com
    participant Browser
    participant API as /api/workflows/[id]/execute
    participant Auth as checkHybridAuth
    participant Executor as Workflow Executor

    Note over Attacker,Executor: Before revert (PR 5062 in place)
    Attacker->>Browser: Embed cross-origin form/fetch
    Browser->>API: POST (session cookie, Sec-Fetch-Site: cross-site)
    API->>Auth: checkHybridAuth returns AuthType.SESSION
    API->>API: isCrossOriginSessionRequest returns true
    API-->>Browser: 403 Access denied

    Note over Attacker,Executor: After this revert
    Attacker->>Browser: Embed cross-origin form/fetch
    Browser->>API: POST (session cookie, Sec-Fetch-Site: cross-site)
    API->>Auth: checkHybridAuth returns AuthType.SESSION
    Note over API: Guard removed, no origin check
    API->>Executor: Execute workflow as victim user
    Executor-->>Browser: 200 OK

Loading

_{Reviews (1): Last reviewed commit: "Revert "fix(execute): block cross-origin..." | Re-trigger Greptile}

[greptile-apps]

CSRF guard removed without replacement

This revert strips the only origin-header-based CSRF mitigation for session-cookie-authenticated workflow execution. Any page on any origin can now embed a form or fire a fetch with credentials to POST /api/workflows/[id]/execute, and the user's session cookie will be attached by the browser — triggering an arbitrary workflow under their identity. The deleted guard was narrowly scoped: it only fired when authType === AuthType.SESSION and the request was provably cross-origin via Sec-Fetch-Site or a mismatched Origin. If it was causing false-positives for a legitimate caller, that caller (API-key / public-API / internal-JWT) would never have been gated by the check in the first place. The PR description doesn't document what went wrong or what alternative protection replaces this.