New
Introducing React Bench, see how different models perform on React code

react-doctor/cors-cookie-trust-risk

Combining credentialed CORS with a wildcard or less-trusted origin, or scoping auth cookies to a parent domain, lets other sites or subdomains ride a user's session.

  • Category: Security
  • Severity: warn
  • Source: oxlint-plugin-react-doctor
  • Framework: global
  • Enabled when: production source files (.js/.ts/.tsx) or config/CI files; tests/build/docs/generated paths skipped
  • Tags: security-scan
  • Default: Enabled

Validate the diagnostic

Confirm the reported code matches this rule before you edit it.

Fires in production source or config/CI files on two shapes: (1) credentialed CORS — Access-Control-Allow-Credentials: true within ~700 chars of an Access-Control-Allow-Origin of *, https://docs., or a mintlify host (combining credentials with a wildcard or less-trusted docs origin); or (2) a broad auth-cookie scope — a session/auth/token/jwt cookie string carrying Domain=. (a leading-dot parent-domain scope that shares the cookie across all subdomains). FALSE POSITIVE to suppress: an Access-Control-Allow-Origin: * endpoint that serves only PUBLIC, non-credentialed data (so the Allow-Credentials: true is a stale/unused header), or a Domain=. cookie that is intentionally non-sensitive (not a real session token despite a matching name) — confirm the cookie actually authenticates and that the wildcard origin is genuinely paired with credentials.

How to fix

Follow the rule guidance while preserving unrelated behavior.

Copyable fix prompt

Copy this self-contained prompt into your coding agent after you confirm the diagnostic.

Do not pair Access-Control-Allow-Credentials: true with a wildcard or less-trusted (docs/vendor) Access-Control-Allow-Origin; when credentials are required, reflect only an explicit allowlist of fully-trusted origins, and serve docs and marketing domains without credentialed CORS. Keep auth cookies host-only by dropping the leading-dot Domain=., and set HttpOnly, Secure, and SameSite. Isolate documentation and custom domains from the app session so an XSS there cannot use app cookies.

More Security rules from the rules reference:

  • react-doctor/dangerous-html-sink: Passing user- or request-derived data into an HTML sink like `dangerouslySetInnerHTML` or `innerHTML` without sanitizing it allows cross-site scripting.
  • react-doctor/firebase-client-owned-authz-field: When the client writes ownership or role fields (`ownerId`, `orgId`, `role`, `isAdmin`) to Firebase/Supabase, an attacker can forge them and grant themselves access.
  • react-doctor/firebase-permissive-rules: A Firebase rule of `if true` or `if request.auth != null` leaves data open to everyone (or to every signed-in user), treating sign-in as authorization and exposing other users' data.
  • react-doctor/firebase-query-filter-as-auth: Relying on a client-side Firestore `.where('userId', '==', …)` filter for access control is unsafe, because a client can drop the filter and read everyone's data.
  • react-doctor/git-provider-url-injection-risk: Interpolating request input into a Git provider URL without encoding lets an attacker inject extra path segments or parameters and redirect the request.