[Security] Block cross-origin account enumeration by removing wildcard CORS

[advikdivekar]

Problem

backend/server.js applied app.use(cors('*')) globally. This allowed JavaScript running on any origin to call POST /api/auth/signup and read the full response body — no browser restriction applied.

Concrete attack:

// Run from https://evil.com or even file://
fetch('http://localhost:5000/api/auth/signup', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ username: 'probe', email: 'victim@example.com', password: 'Aa1@aaaa' })
}).then(r => r.json()).then(console.log);
// 400 "User already exists" → email is registered
// 201 "User created successfully" → email is free

An attacker could automate this across millions of email addresses in minutes, building a full map of registered accounts with zero rate-limit bypass required. Those accounts could then be targeted for phishing or credential stuffing. Additionally, any future authenticated endpoint is exposed by default the moment it is added — the wildcard is a permanent silent grant.

Changes

backend/server.js

• Removed cors('*').
• Replaced with an explicit origin allowlist read from process.env.ALLOWED_ORIGINS (comma-separated), defaulting to http://localhost:5173.
• Added credentials: true so session cookies flow correctly from the allowlisted frontend.
• Server-to-server requests (no Origin header) pass through unchanged.

backend/.env.sample

• Added ALLOWED_ORIGINS=http://localhost:5173 so all contributors know to configure this for their deployment environment.

Why this approach fixes the root cause

The wildcard was a blanket grant at the infrastructure level — any fix to individual routes would be incomplete because the problem recurs for every new endpoint. Replacing it with an env-var-driven allowlist means the trusted origin set is explicit, per-environment, and auditable. A cross-origin probe from an unlisted origin now receives a CORS error and cannot read the response.

Steps to test

1. Start the backend with default .env (ALLOWED_ORIGINS=http://localhost:5173).
2. From http://localhost:5173, POST /api/auth/signup — succeeds (allowlisted).
3. Open DevTools on http://localhost:5174 and repeat — browser blocks with CORS error, response is unreadable.
4. Confirm Access-Control-Allow-Origin in the response header shows http://localhost:5173, not *.
5. curl -X POST http://localhost:5000/api/auth/signup ... (no Origin header) — still works for server-to-server calls.
6. Add http://localhost:5174 to ALLOWED_ORIGINS, restart — both ports accepted.

Edge cases covered

• No Origin header (curl, health checks, internal tooling) — allowed via the !origin guard.
• Multiple allowed origins — supported via comma-separated ALLOWED_ORIGINS.
• Any unlisted origin — CORS error, response body never readable by the caller.
• Session cookie forwarding — credentials: true ensures cookies flow from the allowlisted frontend.

Regression check

No route handlers, session logic, validators, or tests were changed. All existing endpoints continue to work normally from http://localhost:5173. The only behaviour change is that requests from non-allowlisted origins are now rejected by the browser.

Please review and merge this under GSSoC 2026.

[netlify]

✅ Deploy Preview for github-spy ready!

Name	Link
🔨 Latest commit	4ddd368
🔍 Latest deploy log	https://app.netlify.com/projects/github-spy/deploys/6a11bf240d33890008d6d8b8
😎 Deploy Preview	https://deploy-preview-459--github-spy.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Warning

Review limit reached

@advikdivekar, we couldn't start this review because you've used your available PR reviews for now.

Your plan currently allows 1 review/hour. Refill in 43 minutes and 21 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 133b77b1-711f-422c-b54d-10b805033532

📥 Commits

Reviewing files that changed from the base of the PR and between 373dde2 and 4ddd368.

📒 Files selected for processing (2)

• backend/.env.sample
• backend/server.js

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[advikdivekar]

@mehul-m-prajapati why was my code not merged? did i make any mistakes in my code? please let me know