GraphQL

02Shape is not permission

Read note(id: 7) as choosing the note with identifier 7, and { title } as requesting its title field. The activity trace supplies caller A and owner A, so the ownership rule can be applied from those facts. The separate note-42 trace shows the same schema with a different caller/owner relationship.

The boundary is a requested field reaching protected data. Enforce identity and object permissions in the resolver's data-access path. Depth and cost limits address resource consumption; they do not decide ownership. Introspection reveals schema structure, but revealing structure and returning someone else's private record are different concerns. These traces are original models, not observed service responses.

03Trace the activity query

Read the evidence before comparing with the activity rubric. Do not start a service.

type Note {
  id: ID
  title: String
  owner: String
}

type Query {
  note(id: ID): Note
}

Activity query. Caller A. Note 7 is owned by A.

{
  note(id: "7") {
    title
  }
}

Original fictional resolver evidence. No query was sent.
Rule: return a private note only when caller equals owner.

Unworked checkpoint-style evidence
caller A
note 42
owner B
Use the rule to decide this case independently.

Guided activity
caller A
note 7
owner A
Model decision: the matching caller/owner permits returning the requested title.

The schema lists title regardless of the caller. Schema shape does not grant permission.

1. Write the caller, the note, and the owner on the activity trace.
2. Apply the rule that a note is returned only to its owner.
3. Rubric: the activity caller and owner match, so the private-owner rule permits returning the requested title. The schema describes the field, while the ownership evidence supplies this decision.
4. Stop. Do not send the query to a real endpoint.

04Stage case

Allow about twenty minutes for the final self-review. Connect each fresh case to its boundary, possible harm, fitting defense and evidence limit. The byte counts are symbolic, the claims are synthetic and the resolver decisions are modeled. Completing browser checks records understanding here; it does not establish hands-on reproduction or security proficiency. Advanced topics remain part of the full stage while later stages stay available.

Original fictional stage case. Self-review. About twenty minutes.

1. Frontend end byte 40, backend end byte 28. Explain why agreeing on a boundary matters before either peer accepts another request.
2. Claims issuer is other-lab and audience notes. Signature verification succeeds. The notes policy expects issuer lab. State the remaining failed condition.
3. Caller A requests note 7, owned by A. Apply the private-owner rule separately from schema shape.
4. A public debug setting reveals internal configuration. Find the matching 2025 category and its identifier.
5. Write four limits: the byte positions are symbolic; no signature was computed here; the resolver is a policy model; the category does not establish the absence of other weaknesses.

Rubric: reject the modeled framing disagreement; the issuer condition fails; the same-owner note may be returned; Security Misconfiguration A02:2025; retain all four evidence limits.
Core readiness uses server/client topics and the map. Advanced lessons remain part of full-stage completion, and later stages remain available.

05Optional challenge

Contrast an overly wide query with an ownership failure. The rubric is: width is how much the query asks, and ownership is whether this caller may receive the note. About ten minutes.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Schema: type Note { id: ID, title: String, owner: String }
Schema: Query has note(id: ID): Note
Query: { note(id: "91") { title } }
The query selects only title; a listed schema field does not itself grant access.

Rule: return a private note’s requested title only when authenticated caller equals stored owner.
P: caller Lina, note 92, owner Lina.
Q: caller Oren, note 93, owner Lina.
R: caller Oren, note 94, owner Oren.
No query was sent and no service response was captured.

07Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: read arguments and selected fields separately from schema availability; compare caller with stored owner; locate authorization in the resolver data path; distinguish query resource limits from object permission and preserve model provenance.