[Dextheking1]

What

Non-GET routes in createStudioApi now reject cross-origin requests. The guard compares the Origin host against the request Host and also rejects requests whose Fetch Metadata (Sec-Fetch-Site) marks them cross-site.

Why

The studio API is unauthenticated, and loopback binding is the only mitigation (the F-001 note in the CLI server code). CORS-safelisted POSTs (text/plain bodies, form data) are sent without a preflight, so any website open in the user's browser could create and upload project files and trigger renders while hyperframes preview runs.

Related work

Refs the F-001 note in packages/cli/src/server/portUtils.ts. No separate issue; self-contained fix.

How

Middleware in createStudioApi: a non-GET request gets a 403 when the Origin host does not match the request Host, when the Origin is unparseable (including the opaque literal null), or when Sec-Fetch-Site is cross-site. Requests with no Origin header (curl, tests, in-process callers) and all reads are unaffected.

Test plan

• Unit tests added/updated: 8 new tests in createStudioApi.originGuard.test.ts, all passing. The file is pinned to the node vitest environment on purpose: the package default (happy-dom) follows the browser fetch spec and silently drops forbidden headers such as Origin, which made the first version of the tests simulate nothing.
• Manual testing performed: verified against the real preview server. Before the fix, cross-origin file create (text/plain body), multipart upload, and duplicate-file all returned 201 and wrote the files. After the fix, all three return 403 and write nothing. Same-origin and no-Origin controls still return 201.
• Documentation updated (if applicable): no docs change, the only behavior change is rejecting cross-origin writes.

[miguel-heygen]

Thanks for picking this up, the threat is real and the tests go through the actual API object, which is the right way in. One gap: the guard only asks whether the Origin host equals the Host header, so a page whose DNS points its own name at 127.0.0.1 sends a matching pair and gets through. The server already has the missing half in isLoopbackHost and identityAllowed, and sameOriginPost in the CLI server applies both for the open in desktop route, including a stricter Sec-Fetch-Site rule. Could this reuse that helper, lifted somewhere both can import, so there is one answer to "is this write same origin" instead of two that disagree?

Also worth knowing: no test or lint workflow has run on this PR yet, only the mergeability check.

[Dextheking1]

fixed. writeOriginAllowed is gone, the guard now calls sameOriginPost. lifted it with isLoopbackHost and identityAllowed into studio-server (helpers/requestIdentity.ts, new ./request-identity subpath in the descriptor), cli imports it from there. desktopRoutes and telemetryIdentity re-export, so their callers and tests did not move.

one plumbing note: when a request has no Host header it never came over the wire, so the middleware falls back to the host in the request URL. on a real server that URL is built from the Host header, so nothing changes there.

new tests in createStudioApi.originGuard.test.ts: origin and host both rebind.example (a name pointing at loopback) gets a 403 and writes nothing, same with no origin on that host, and sec-fetch-site same-site no longer passes. guard suite 11/11.

local runs, ci has not run on this pr:

• studio-server full suite: 1349 passed, 6 failed. all 6 fail on the base commit too in this environment (media codec and peak decode, file mode, rename math, sharp import timeout), none in the api area.
• cli server suites: 13 files, 207 passed, 0 failed.
• typecheck clean in both packages, oxlint and oxfmt clean on the changed files.
• check:package-subpaths, check:package-cycles and check:cli-lazy-deps pass.