chore: remove permissive CORS from server and master - #193
Merged
Conversation
Both binaries wrapped their routers in `CorsLayer::permissive()`, which sends `Access-Control-Allow-Origin: *` and allows any method and header. Combined with the absence of authentication, that instructs every browser to permit cross-origin calls from any page on the internet to endpoints that delete stores and mutate training data. Nothing needs it. The master serves its SPA itself (`fallback_service`) and the UI fetches a relative `/api/v1`, so admin traffic is same-origin in production; in development the vite proxy forwards `/api` to the master, so it is same-origin there too. No preflight is involved on either path. The data-plane server has no browser client at all. Drops the now-unused `cors` feature from both `tower-http` dependencies; the workspace builds clean, which confirms nothing else relied on it. A deployment that genuinely needs cross-origin access should opt in with an explicit allow-list of origins rather than a blanket wildcard. Co-Authored-By: Claude <noreply@anthropic.com>
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.
Problem
Both binaries wrapped their routers in
CorsLayer::permissive():crates/lance-context-server/src/main.rs:78crates/lance-context-master/src/main.rs:70That sends
Access-Control-Allow-Origin: *with any method and any header. Since neither service has authentication, it actively instructs browsers to allow cross-origin requests from any page on the internet to endpoints that delete stores, trigger compaction, and mutate training data. It converts "unauthenticated on a trusted network" into "reachable from any tab the operator has open".Why nothing needs it
fallback_service(ServeDir)(main.rs:58-59), and the UI calls a relative base —const API = "/api/v1"(ui/src/api.ts:118). Same-origin, no preflight.vite.config.tsproxies/apito the master process, so the browser still only ever talks to the vite origin. Same-origin again.Change
Remove the layer from both binaries, drop the now-unused imports, and remove the
corsfeature from bothtower-httpdependencies. The workspace builds clean without it, which confirms nothing else was relying on the feature.A deployment that genuinely needs cross-origin access should opt in with an explicit origin allow-list rather than inheriting a wildcard by default.
Testing
cargo test -p lance-context-server -p lance-context-master→ 51 + 12 passed, 0 failed. fmt + clippy clean across the workspace.Not a functional change for any supported deployment: every current client path is same-origin.
🤖 Generated with Claude Code