app/main.py:79-85 mounts CORSMiddleware with allow_origins=settings.cors_origins and allow_credentials=True, and config.py:102 defaults cors_origins to ["*"].
Starlette treats that combination specially: rather than refusing it, it reflects the caller's Origin back in Access-Control-Allow-Origin and still sends Access-Control-Allow-Credentials: true. So the effective policy is "any origin, with credentials" — the opposite of what a wildcard normally means.
Honest severity: lower than it looks. c2-core authenticates with bearer tokens (Firebase ID token, service key, node API key), and a browser does not attach those automatically cross-origin, so an attacker page cannot ride an existing session the way it could with cookie auth. The drb_session cookie exists but c2-core never reads it — it only drives the Next middleware's UX redirect. This is a misconfiguration waiting for the day something does start trusting a cookie or an origin, not a live account-takeover path today.
Whether production is actually running the wildcard is unverified: CORS_ORIGINS may be set in the server's .env, which is gitignored and not readable from here. Note that drb-c2-core/.env.example is known-stale, so its absence there proves nothing.
Fix: make the bad combination unrepresentable rather than relying on every deployment remembering to override it. If cors_origins contains "*", either force allow_credentials=False or refuse to start, and log at ERROR naming the variable to set. The default in config.py should be the real frontend origin, with the wildcard opt-in for local development.
From the 2026-08-05/06 security audit, listed there as the open MEDIUM item.
`app/main.py:79-85` mounts `CORSMiddleware` with `allow_origins=settings.cors_origins` and `allow_credentials=True`, and `config.py:102` defaults `cors_origins` to `["*"]`.
Starlette treats that combination specially: rather than refusing it, it reflects the caller's `Origin` back in `Access-Control-Allow-Origin` and still sends `Access-Control-Allow-Credentials: true`. So the effective policy is "any origin, with credentials" — the opposite of what a wildcard normally means.
**Honest severity:** lower than it looks. c2-core authenticates with bearer tokens (Firebase ID token, service key, node API key), and a browser does not attach those automatically cross-origin, so an attacker page cannot ride an existing session the way it could with cookie auth. The `drb_session` cookie exists but c2-core never reads it — it only drives the Next middleware's UX redirect. This is a misconfiguration waiting for the day something does start trusting a cookie or an origin, not a live account-takeover path today.
Whether production is actually running the wildcard is unverified: `CORS_ORIGINS` may be set in the server's `.env`, which is gitignored and not readable from here. Note that `drb-c2-core/.env.example` is known-stale, so its absence there proves nothing.
**Fix:** make the bad combination unrepresentable rather than relying on every deployment remembering to override it. If `cors_origins` contains `"*"`, either force `allow_credentials=False` or refuse to start, and log at ERROR naming the variable to set. The default in `config.py` should be the real frontend origin, with the wildcard opt-in for local development.
From the 2026-08-05/06 security audit, listed there as the open MEDIUM item.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
app/main.py:79-85mountsCORSMiddlewarewithallow_origins=settings.cors_originsandallow_credentials=True, andconfig.py:102defaultscors_originsto["*"].Starlette treats that combination specially: rather than refusing it, it reflects the caller's
Originback inAccess-Control-Allow-Originand still sendsAccess-Control-Allow-Credentials: true. So the effective policy is "any origin, with credentials" — the opposite of what a wildcard normally means.Honest severity: lower than it looks. c2-core authenticates with bearer tokens (Firebase ID token, service key, node API key), and a browser does not attach those automatically cross-origin, so an attacker page cannot ride an existing session the way it could with cookie auth. The
drb_sessioncookie exists but c2-core never reads it — it only drives the Next middleware's UX redirect. This is a misconfiguration waiting for the day something does start trusting a cookie or an origin, not a live account-takeover path today.Whether production is actually running the wildcard is unverified:
CORS_ORIGINSmay be set in the server's.env, which is gitignored and not readable from here. Note thatdrb-c2-core/.env.exampleis known-stale, so its absence there proves nothing.Fix: make the bad combination unrepresentable rather than relying on every deployment remembering to override it. If
cors_originscontains"*", either forceallow_credentials=Falseor refuse to start, and log at ERROR naming the variable to set. The default inconfig.pyshould be the real frontend origin, with the wildcard opt-in for local development.From the 2026-08-05/06 security audit, listed there as the open MEDIUM item.