The Memory Next Door
One court record was intentionally released from a larger archive. Follow its documented custody relationships and determine whether the service enforces the scope declared by neighboring records.
Objective
By completing this module, you will be able to:
- distinguish object location from object-level authorization; and
- demonstrate an authorization failure through a bounded, evidence-led test.
Before you begin
Open The Memory Next Door and the released record linked by the pane. Review Change a URL safely and JSON and JSON Lines.
Concepts
A direct object reference places an identifier such as a record number in a URL or request. Predictable identifiers are not automatically a vulnerability: the failure occurs when the server returns an object without checking whether the requesting user is allowed to access that specific object. Hiding links or choosing obscure numbers is not a substitute for server-side authorization.
An object identifier locates a record; it does not prove permission to use it. The server must check the authenticated user's relationship to the specific object and requested action. Apply the check to every access path, including downloads and APIs. Unpredictable identifiers can reduce guessing but do not replace authorization.
Suggested tools
- Browser: Follow the released record and make small, deliberate changes to only the numeric path component.
- JSON viewer or evidence table: Record object number, type, relationship, required scope, served scope, and a short description.
Tool practice
Rehearse the worked tool exercise before using challenge data.
Use a formatted JSON view to locate relationship fields before changing the URL. Record the path, returned record ID, required scope, and served scope in one row. Follow only the authored relationships and retained interval.
Investigation
Observe
Begin with the released record. Follow explicit relationship fields and the small retained interval described by the records themselves. Compare the access scope each returned object requires with the scope to which it was served.
Form a hypothesis
Does the archive make an authorization decision for every object, or does it serve a neighboring protected record merely because its number is known? Which fields prove the mismatch?
Test carefully
Change only the numeric record component within the linked, authored interval. Send one request at a time; do not scan the archive or enumerate unrelated addresses. Record the omitted testimony's evidence code and the exact required-versus-served scope pair in the ledger.
Progressive hints
Hint 1
Read the released record's relationship fields and statement before editing the URL.
Hint 2
Stay within the small connected record interval and compare record types rather than searching the whole numeric space.
Hint 3
The decisive record declares one required scope but says it was served to a different scope. Its evidence code and those two scopes are the requested findings.
Troubleshooting and reset
If a path returns 404, restore the exact route grammar shown on the pane and use a canonical decimal record number without extra characters. Return to the released object and follow its relationships again. Avoid broad enumeration; it adds no value to the requested proof and exceeds the exercise boundary.
Witness seal filing and recovery
Record this pane's critical finding in the active session before filing its witness seal. Supporting findings are optional. An unearned seal is rejected without consuming a failed-flag attempt. To recover an earned seal, revisit this pane or repeat the accepted finding in the same session; neither adds progress twice. All six critical findings and their six filed seals unlock release, seal, and return. Supporting findings strengthen the ending and remain available after it.