Skip to content

fix(cors): enforce explicit origin allow-list in production - #749

Open
Adjutant500 wants to merge 1 commit into
BlockDash-Studios:mainfrom
Adjutant500:fix/cors-security-allow-list
Open

fix(cors): enforce explicit origin allow-list in production#749
Adjutant500 wants to merge 1 commit into
BlockDash-Studios:mainfrom
Adjutant500:fix/cors-security-allow-list

Conversation

@Adjutant500

Copy link
Copy Markdown

-Here's a PR description you can use:

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────

fix(cors): enforce explicit origin allow-list in production (#662)

Summary

Fixes a permissive CORS configuration that allowed CORS_ORIGIN=* in production and unconditionally set
credentials: true — a combination that lets any attacker-controlled site read authenticated API responses.

Changes

src/main.ts

  • Added a bootstrap guard that throws at startup if CORS_ORIGIN is "*" when NODE_ENV is production or staging —
    misconfigured deployments fail loudly rather than silently
  • credentials is now false when a wildcard origin is in use; true only when an explicit allow-list is configured —
    wildcard + credentials is both browser-blocked and a security vulnerability

src/config/env.schema.ts

  • CORS_ORIGIN in production/staging: wildcard is explicitly rejected, field is required with no default
  • CORS_ORIGIN in development/test: unchanged, still defaults to "*" for convenience
  • Exported ENV_VALIDATION_OPTIONS — it was already imported by config.module.ts and tests but was never exported,
    causing a latent TypeScript error

.env.example

  • Updated CORS_ORIGIN comment to document the production requirement and provide an example allow-list

src/config/cors.spec.ts (new, 34 tests)

  • Schema validation: wildcard accepted in dev/test, rejected in production/staging, explicit origins and
    comma-separated lists accepted everywhere
  • Runtime allow-list: exact-match only, subdomain rejection, prefix-attack rejection, credentials enabled only
    with an explicit list
  • Bootstrap guard: throws on wildcard in production/staging, passes in development/test

Required action for deployment

Set CORS_ORIGIN to a comma-separated list of allowed origins before deploying to production or staging:

CORS_ORIGIN=https://rustacademy.xyz,https://www.rustacademy.xyz

The server will refuse to start without this.

closes #577

- Reject CORS_ORIGIN='*' at startup when NODE_ENV is production or staging
- Disable credentials when wildcard origin is configured (wildcard +
  credentials:true is a security vulnerability)
- Add Joi schema enforcement: wildcard forbidden in production/staging,
  CORS_ORIGIN is required with no default in those environments
- Export ENV_VALIDATION_OPTIONS from env.schema.ts (was imported but
  never exported, causing a latent TS error)
- Add cors.spec.ts with 34 tests covering schema validation, runtime
  allow-list behaviour, and the bootstrap guard

Closes BlockDash-Studios#662
@drips-wave

drips-wave Bot commented Aug 29, 2026

Copy link
Copy Markdown

@Adjutant500 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BA-009 — Configure secure CORS from validated origins

1 participant