Codewise
Menu
Choose another case

Request Investigator · Case 02

The page loaded, but the data did not

Start with the observed symptom. Inspect evidence, state what it proves, and choose a useful next check.

Observed symptom

Start with what the user can see

The product page shell and navigation appear, but the product area says “We could not load this product.”

All requests, addresses, identifiers and logs in this exercise are illustrative. Nothing connects to a real service, and no result is saved.

System traceArchitecture for this caseThe components in scope. No failed boundary is marked; inspect the evidence before drawing a conclusion.
  1. Browser documentRequests and renders the HTML shell
  2. Page JavaScriptStarts a separate same-origin API request
  3. API authenticationChecks the supplied session identifier
  4. Product handlerRuns only after required identity checks
Scenario assumptions and boundaries

This illustrative application serves HTML and a same-origin JSON API from app.example.com. Its API authenticates requests with a cookie named session. A valid cookie must map to an active server-side session before authorization runs. For this case, a failed session lookup returns 401 with a Session challenge. Other applications may use tokens, redirects or different status behavior.

Compare the browser requests

The Network panel records more than one request. Inspect the document and API entries independently.

  1. Document requestInspect evidence
    Document request — illustrative evidencetext
    Illustrative browser Network entry
GET https://app.example.com/products/42
Type: document
Status: 200 OK
Content-Type: text/html
Transferred: 8.4 kB

    Observation: the initial HTML document returned successfully. Inference: the browser could display the page shell. Unknown: whether later requests made by the page also succeeded.

  2. Page-data requestInspect evidence
    Page-data request — illustrative evidencetext
    Illustrative browser Network entry
GET https://app.example.com/api/products/42
Type: fetch
Status: 401 Unauthorized
WWW-Authenticate: Session realm="codewise-example"
X-Request-ID: cw-401-02
Response: {"error":"authentication_required"}

    Observation: a separate same-origin fetch reached the API and received 401. Inference: this application did not accept valid authentication credentials for this API request. Unknown: whether credentials were absent, sent but unrecognized, expired, or rejected for another authentication reason.

Decision 1

What does “the page loaded” prove?

Choose the strongest conclusion supported by the two Network entries.

The 200 document means every request required by the page succeeded.
Not established by the evidence

The document and API are separate HTTP exchanges. The document returned 200 while the fetch returned 401.

What would support it: Successful Network entries for the page's required API and resource requests would be needed to support this broader claim.

You can close this and inspect another hypothesis. No score is recorded.
The HTML document succeeded; the separate API request reached an authentication boundary and failed there.
Supported by the evidence

Supported. These are separate HTTP exchanges: the visible shell came from the successful document response, while the product data depends on a later request with its own status and evidence.

You can close this and inspect another hypothesis. No score is recorded.
The browser could not parse or render the HTML document.
Not established by the evidence

The shell and navigation are visible, and the document returned 200. That does not fit a document parsing failure.

What would support it: A blank or malformed document together with parsing or rendering diagnostics would support this direction.

You can close this and inspect another hypothesis. No score is recorded.
The user is authenticated but lacks permission to view product 42.
Not established by the evidence

A 401 in this application signals that authentication was not accepted. We do not yet know whether authorization ran.

What would support it: An accepted identity followed by an authorization decision—commonly a correlated server trace and often a 403 response—would support this claim.

You can close this and inspect another hypothesis. No score is recorded.

Inspect the authentication boundary

Use the request ID to compare what the browser sent with what the API accepted.

  1. API request headersInspect evidence
    API request headers — illustrative evidencetext
    Illustrative browser Network entry — secret value redacted
GET /api/products/42
Cookie: session=[redacted]
Sec-Fetch-Site: same-origin
X-Request-ID: cw-401-02

    Observation: a session cookie was present on this API request. Inference: “the browser sent no cookie” is not supported. Unknown: whether its value names an active server-side session or why it might not.

  2. Correlated authentication recordInspect evidence
    Correlated authentication record — illustrative evidencetext
    Illustrative authentication log — normalized fields
request_id=cw-401-02
credential_source=cookie
cookie_present=true
session_lookup=not_found
authorization_check=not_run
status=401

    Observation: this application received the cookie but found no active matching session, so authorization did not run. Inference: the first uncertainty is session recognition, not product permission. Unknown: whether the session expired, was invalidated, points at a different session store, or was never created there.

Decision 2

What should you inspect next?

Revise your hypothesis using both the request headers and correlated authentication record.

Change CORS settings because the browser blocked the request.
Not established by the evidence

The same-origin request reached the API and exposed a 401 response. This evidence does not show a browser CORS block.

What would support it: A browser CORS diagnostic or blocked response would be needed to investigate that boundary.

You can close this and inspect another hypothesis. No score is recorded.
Fix cookie attachment because no session cookie was sent.
Not established by the evidence

The Network entry explicitly shows a redacted session cookie on this request.

What would support it: An absent Cookie header, together with cookie scope or credentials-mode evidence, would support this hypothesis.

You can close this and inspect another hypothesis. No score is recorded.
Correlate the session identifier with session creation, expiry/invalidation and the session store used by this deployment.
Supported by the evidence

Useful next check. It can distinguish expiry or invalidation from a store/configuration mismatch without treating the secret value as safe log data.

You can close this and inspect another hypothesis. No score is recorded.
Change the user's product permission because authorization denied access.
Not established by the evidence

The correlated record says authorization did not run; the session lookup failed first.

What would support it: An accepted session followed by an explicit authorization denial would be required to investigate permissions.

You can close this and inspect another hypothesis. No score is recorded.

Write the investigation result

A useful report separates observations from remaining possibilities. Reveal this one after you have formed your own summary.

Reveal the investigation summary
Last confirmed successful boundary
The HTML document loaded, and the later API request reached the API authentication boundary.
First observed failure or uncertainty
The API did not find an active session matching the cookie supplied with the data request; authorization was not reached.
Evidence supporting the conclusion
200 document entry, separate 401 fetch with request ID cw-401-02, Cookie header present, and the correlated session_lookup=not_found record.
Plausible causes still open
Session expiry or invalidation, a session-store/configuration mismatch, or an identifier never created in the store used by this deployment.
Next useful check
Safely correlate the session identifier with session creation and expiry/invalidation records and confirm which session store the API deployment uses.

Unseen transfer challenge

Use the method on a different boundary

This is a new illustrative incident. Work from its evidence before comparing your reasoning with the model report.

Start the transfer challenge

The project page appears, but opening its settings shows “You do not have access.” Inspect the correlated evidence for this particular application.

Application rules for this exercise: project settings require the project_admin role. Browser and server records can be correlated only when their request identifiers match. Treat the fields below as observations from this illustrative application, not as a universal explanation for every 403 response.

Transfer challenge — illustrative evidencetext
Illustrative browser Network entries
GET /projects/atlas                 200 OK   (document)
GET /api/projects/atlas/settings    403 Forbidden (fetch)
X-Request-ID: cw-transfer-403

Illustrative correlated authorization record
request_id=cw-transfer-403
identity=user-17
authentication=accepted
resource=project:atlas/settings
required_role=project_admin
granted_roles=project_member
authorization=denied

Write a brief investigation note before revealing the model report. Your text remains in this browser page, is not submitted, and disappears when you reload.

Reveal the model investigation report

A 403 status alone does not prove this explanation. In this exercise, the matching request ID and correlated policy record support the case-specific inference below.

Definitely worked
The document loaded, the later fetch reached the application, and this application's correlated record says identity user-17 was authenticated.
Failed or unknown
Authorization to project:atlas/settings was denied because the required project_admin role was not present. The evidence does not tell us whether the policy or the user's recorded membership is correct.
Next useful check
Inspect the policy inputs and the source of project membership for user-17, then confirm whether the route really requires project_admin. This distinguishes a correct denial from stale role data or a misconfigured policy.

Understand the boundaries

References & further reading

References & further reading5 sourcesPrimary standards and official documentation used for this lesson.
  1. RFC 9110: HTTP Semantics — 401 Unauthorized (opens in a new tab)

    IETF

    Defines 401 and its authentication-challenge requirement.

  2. RFC 9110: HTTP Semantics — 403 Forbidden (opens in a new tab)

    IETF

    Defines 403 semantics; the transfer challenge relies on correlated evidence for its case-specific authorization conclusion.

  3. Fetch Standard — credentials (opens in a new tab)

    WHATWG

    Defines request credential modes and how same-origin requests handle credentials.

  4. Cookie header (opens in a new tab)

    MDN Web Docs

    Explains the Cookie request header; the example redacts its illustrative value.

  5. Session Management Cheat Sheet (opens in a new tab)

    OWASP Cheat Sheet Series

    Supports the distinction between a client-held session identifier and server-side session state.