WEB / CASE browser-and-api
The API replied. Why can’t the script read it?
Separate CORS delivery, preflight and script exposure from authentication and authorization.
Observation file
The Atlas browser context and Catalog API have different origins. A fixed read-only request carries X-Atlas-View and needs a preflight. In the denied-preflight branch the actual request was not sent. In another fixed response branch, HTTP receipt exists but script exposure is blocked.
The two failures differ
Preflight denial and withholding an actual response from script occur at different stages. A console message alone does not establish that a server action did not occur. Correlate server traces and Network observations for the request type and branch.
CORS does not replace API authorization. A denial may be normal enforcement rather than an incident. Evaluate allowed origins and credential mode together.
Regression boundary
Trace allowed preflight, denied preflight and actual response exposure separately in the fixed fixture. Verify expected origin policy and credential mode; public API readability is not protected-object permission.
YOUR TURN
Work through this story.
Predict the outcome, find the evidence boundary, and explain it in your own words.
Compare synthetic branches A and B: which reading supports the distinction between request delivery and script exposure?
Selected observations from the synthetic case file
- context
- Atlas browser / Catalog API: different origins
- fixed request header
- X-Atlas-View
- branch A
- preflight denied; actual request not sent
- branch B
- HTTP receipt observed; script exposure blocked
- Neither branch sent an actual request.
- Receipt in B also proves protected-object authorization was allowed.
- A stops at preflight; B stops at script exposure after receipt.
Read the explained answer
A stops at preflight; B stops at script exposure after receipt. — The file contains two different failure boundaries. A explicitly supplies non-delivery of the actual request; B has receipt without script access to the body. Neither substitutes for API object permission.
Why are “the server action definitely did not run and an attack occurred” two unsupported claims after seeing a CORS denial?
- Policy may have worked normally; action outcomes require branch and server observations.
- Every request from another origin is an attack.
- A CORS denial proves that API authorization was completed.
Read the explained answer
Policy may have worked normally; action outcomes require branch and server observations. — Use the console message as a limited browser observation. Nonexecution or incident claims need additional scope and sources; CORS is not the API authorization system.
Write separate checks for allowed preflight, denied preflight and exposure after receipt. Where do credential mode and API permission fit?
Read the explained answer
For allowed preflight, check the expected origin/header policy and the subsequent actual-request stage. In the denied-preflight fixture, observe non-delivery of the actual request separately. After receipt, distinguish Response receipt from the fields script can read. Evaluate credential mode together with policy. None of these outcomes is protected-object permission; verify API authentication and authorization separately.
□ Are actual-request conditions separated for allowed and denied preflight?
□ Are receipt and script exposure distinguished?
□ Are expected origin policy and credential mode evaluated together?
□ Does API object/action authorization remain an independent check?
Lessons connected to this case · 18
Return to the case with these lesson concepts. Connections do not add observations to the case record; they help examine its responsibilities together.