Verify a session
A production session must come from a protected HTTPS cookie and server-validated identity—not a selectable role or query string.
Who can access what?
Having an account is not enough. The server must check exactly which person is requesting which item, in which community, and for what action. Test those checks against invented people, places and records.
i
Security exercise—not a sign-in page.
All people and records below are fictional. Selecting an identity does not authenticate anyone. The decisions and read restrictions are enforced by the server only for sample content. No personal records, login cookies, community posts or moderator permissions are live on this HTTP preview.
FICTIONAL ACCOUNTS—Includes a guest
MOCK RESOURCES—Distinct owners and Orbits
REAL USER ACCOUNTS0Login stays blocked
PUBLIC WRITE ACCESS0All mutations blocked
TRY COMMON SECURITY MISTAKES
One changed ID should not reveal someone else's life.
Each example chooses a fictional person and record, sends the request to the server, and explains what happened.
SERVER DECISION
WAITING FOR A CHECK
Choose a test above
The browser does not decide access. It displays the response returned by Pocket Universe's sample policy enforcement point.
The server returns a reason and a safe disclosure category, without returning real personal content.
Protected resource response
Not requested yet.
Check identity, scope, resource and action—every time.
Keep Orbits separate
A reviewer assigned to one mock Orbit does not gain permission to read another Orbit's queue.
Protect private evidence
A moderator reviewing public Signal text cannot automatically open the user's restricted Case receipts.
Return only needed data
Even an authorized reviewer receives a redacted sample preview rather than private originals or arbitrary fields.