Backend Study Lab · Games
← All games

CORS Preflight Pilot

Guide browser API requests through CORS decisions covering origins, preflight, credentials, exposed headers, and cache safety.

Concept
CORS, browser security boundaries, and preflight response design
Difficulty
Intermediate
Play time
6-9 minutes
Path
Foundations

Interactive scenario

Playable game area: Make the next backend decision

Use the controls below. Feedback appears immediately and final scores stay in this browser.

Concept notes

Why this decision matters

CORS Preflight Pilot is focused practice for CORS, browser security boundaries, and preflight response design. It explains why each answer is safe, risky, or production-ready.

CORS bugs are frustrating because the browser, API gateway, cache, and application server all seem involved. This game turns those moving parts into short dispatch decisions so you can learn the backend side of safe cross-origin access.

Learning objectives

  • Explain when browsers send CORS preflight requests.
  • Choose safe Access-Control headers for origins, credentials, methods, and headers.
  • Avoid common CORS mistakes such as wildcard credentials and unsafe origin reflection.

How to play

  1. Read the browser request, origin, credential mode, and API context.
  2. Choose the CORS response or policy that grants the narrowest safe access.
  3. Use the explanation to connect browser behavior with backend headers.

Scoring

  • Correct decisions add points and build a streak bonus.
  • Incorrect decisions reveal the unsafe assumption.
  • Finishing saves your best local CORS decision score.

Backend concept notes

CORS is a browser-enforced read boundary. It does not replace authentication or authorization, but a bad CORS policy can let an attacker-controlled origin read authenticated responses.

Backend APIs should be explicit about allowed origins, credential support, request headers, exposed response headers, and cache variation. Preflight is part of the contract, not noise to ignore.

Common mistakes

  • Reflecting any Origin header for sensitive authenticated APIs.
  • Combining wildcard origins with credentials.
  • Forgetting Vary: Origin when CORS responses differ by origin.
  • Putting response headers in Access-Control-Allow-Headers instead of Access-Control-Expose-Headers.

Review misses from this game

Keep practicing nearby backend concepts while the mental model is fresh.

Auth Intermediate

Auth Token Inspector

Inspect authentication scenarios and choose safe backend decisions for tokens, scopes, sessions, CSRF, and object-level authorization.

Time
6-9 minutes
Concept
Authentication, authorization, sessions, and token safety
  • Foundations
  • Auth
  • JWT
  • sessions
Play Auth Token Inspector
APIs Beginner

API Route Builder

Design REST-style methods and routes for product requirements such as creating users, updating email, searching products, and nested comments.

Time
6-9 minutes
Concept
REST API route design
  • Foundations
  • REST
  • API design
  • routes
Play API Route Builder
APIs Intermediate

Webhook Signature Forensics

Investigate webhook requests and choose safe handling for signatures, replay windows, retries, idempotency, and durable acknowledgement.

Time
6-9 minutes
Concept
Webhook verification, replay protection, idempotency, and retry-safe processing
  • Foundations
  • webhooks
  • HMAC
  • idempotency
Play Webhook Signature Forensics

FAQ

Short answers for how this game fits backend interview and study practice.

Does CORS protect my API from non-browser clients?

No. CORS is enforced by browsers. Servers still need authentication, authorization, validation, and abuse controls for all clients.

Should I just use Access-Control-Allow-Origin: *?

Only for truly public responses that do not rely on credentials and do not expose private data. Sensitive APIs should use an allowlist.

Leaderboard

Top 10 scores for the current ruleset. No account required.

Loading leaderboard...

    Finish the game to load your latest local score.