Critical: CORS misconfiguration with allow_credentials=True and allow_origins=['*']

[namann5]

Vulnerability Description

A critical CORS misconfiguration exists in backend/app/main.py where allow_origins=["*"] is used alongside allow_credentials=True.

Impact

According to the CORS specification (RFC 6454), when Access-Control-Allow-Credentials: true is set, the Access-Control-Allow-Origin header must specify an explicit origin, not a wildcard. The current configuration allows any external website to make authenticated cross-origin requests to the API.

This means:

1. An attacker can host a malicious website
2. When a logged-in InterXAI user visits that site, the attacker's JavaScript can make API calls with the user's credentials (JWT token from Authorization header or cookies)
3. The browser will include credentials because allow_credentials=True
4. The attacker can read, modify, or delete user data

Location

backend/app/main.py:46-51

CVSS Score

8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Fix

The fix restricts allowed origins to specific development URLs and makes them configurable via Settings.CORS_ORIGINS.

[github-actions]

👋 Hey @namann5, thanks for raising this issue!

A maintainer will review it shortly. If you'd like to work on a fix, please read the guidelines below before opening a PR.

---

📋 Before You Start

Look at our merged pull requests to understand the expected commit style and code quality before writing a single line.

Merged PRs are the best source of truth for:

• How commits should be worded and structured
• How code is organised (file structure, naming, patterns)
• What a clean, reviewable PR looks like

---

✅ Clean Commit History — Required

We follow Conventional Commits:

Prefix	Use for
feat:	New feature
fix:	Bug fix
chore:	Tooling / config / deps
docs:	Documentation only
refactor:	Code restructuring (no behaviour change)
test:	Adding or fixing tests

Branch naming: feat/<short-description> or fix/<short-description>

Rules:

• 🚫 No force-push to main or shared branches
• 🚫 No merge commits inside your feature branch — rebase instead
• ✅ One logical change per commit
• ✅ PR must reference this issue: Closes #138

---

Happy contributing! 🚀

[ShreeniG99]

@sathwikshetty33
Heyyaa, I'm Shreenidhi, a GSSoC'26 contributor. I'd like to have this issue assigned to me.
Using allow_origins=[""] with allow_credentials=True is actually rejected by browsers as a security violation bcoz credentials cannot be sent with wildcard origins. The fix is to replace "" with an explicit list of allowed origins that are pulled from env variables.
Thanks!

[Aasritha-sure]

Hi @namann5,

I would like to work on this issue under GSSoC 2026 if it becomes available.

After reviewing the vulnerability report, I understand that the current CORS configuration uses:

allow_origins=["*"]
allow_credentials=True

which is insecure and violates the CORS specification because credentialed requests must not be allowed with a wildcard origin. This could potentially allow authenticated cross-origin requests from untrusted websites.

Proposed Fix

• Replace the wildcard origin with an explicit allowlist of trusted frontend domains.
• Load allowed origins from environment variables (e.g., CORS_ORIGINS) for flexibility across development and production environments.
• Keep allow_credentials=True only when using explicitly trusted origins.
• Validate CORS behavior for both local development and production deployments.
• Update configuration documentation and environment setup instructions.

Verification Plan

• Test requests from allowed origins and verify successful authentication flows.
• Confirm requests from unauthorized origins are blocked.
• Validate preflight (OPTIONS) requests.
• Ensure existing frontend functionality remains unaffected.

Expected Benefits

• Eliminate the credentialed wildcard-origin vulnerability.
• Improve security and standards compliance.
• Provide a maintainable and environment-specific CORS configuration.

I have understood the issue and would be happy to contribute if the current linked PR is not pursued or if additional improvements are required.

Thank you!