[Security] Replace wildcard CORS with environment-driven origin allowlist#457
[Security] Replace wildcard CORS with environment-driven origin allowlist#457advikdivekar wants to merge 1 commit into
Conversation
cors('*') allowed any website to make cross-origin requests to
the API and read the full response body, bypassing the browser's
Same-Origin Policy for all current and future endpoints.
Replace with an explicit origin allowlist read from ALLOWED_ORIGINS,
defaulting to the local Vite dev server. Restrict permitted methods
to GET and POST and lock allowed headers to Content-Type so the
policy surface stays minimal as the API grows.
Fixes GitMetricsLab#374
✅ Deploy Preview for github-spy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Your plan currently allows 1 review/hour. Refill in 58 minutes and 4 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@mehul-m-prajapati why was my code not merged? did i make any mistakes in my code? please let me know |
Problem
backend/server.jsline 15 appliedapp.use(cors('*'))— a fully open wildcard CORS policy across every API endpoint. This instructs browsers to allow any origin to read API responses, completely nullifying the Same-Origin Policy as a defence layer.Concrete impact:
file://,http://attacker.com) could callPOST /api/auth/signuporPOST /api/auth/loginand read the full JSON response with no browser restriction.passportConfig.js, a cross-origin script could enumerate the entire registered user database in seconds.Changes
backend/server.jscors('*').process.env.ALLOWED_ORIGINS(comma-separated), defaulting tohttp://localhost:5173so local development works out of the box.credentials: trueto allow session cookies in cross-origin requests from the allowlisted frontend.methodsto['GET', 'POST']andallowedHeadersto['Content-Type']— minimises the CORS surface as the API grows.Originheader) are still allowed for health checks and internal tooling.backend/.env.sampleALLOWED_ORIGINS=http://localhost:5173so contributors know to set this variable for their deployment environment.Why this approach fixes the root cause
The wildcard policy was a blanket grant at the infrastructure level. Replacing it with an environment-variable-driven allowlist means the set of trusted origins is explicit, auditable, and different per environment —
http://localhost:5173for dev, the production domain for prod — without any code change required between environments.Steps to test
npm startinbackend/).http://localhost:5173, callPOST /api/auth/signup— request succeeds (allowlisted origin).http://localhost:5174(a different port) and repeat the fetch — browser blocks the request with a CORS error.Access-Control-Allow-Originresponse header showshttp://localhost:5173, not*.ALLOWED_ORIGINS=http://localhost:5173,http://localhost:5174in.envand restart — both origins are now accepted.curl -X POST ...with noOriginheader) still work.Edge cases covered
Originheader (server-to-server, curl) — allowed, as the!originguard passes them through.ALLOWED_ORIGINS.Regression check
All existing routes (
/api/auth/signup,/api/auth/login,/api/auth/logout) continue to work normally fromhttp://localhost:5173. Thecredentials: trueflag ensures session cookies are forwarded correctly from the frontend. No changes to route handlers, middleware order, or tests.Please review and merge this under GSSoC 2026.