CHAPTER 10 / 13 · READ → DECIDE → BUILD

Challenge the trust boundaries.

Try the actions the interface is designed to prevent.

20 min + practiceA threat model and access reviewJump to practice ↓

Think in concrete misuse paths

List what your app protects: user identity, task ownership, coordinator actions, and any secrets used by the server. Then ask how an unauthorized person might reach each operation. Change a task ID. Submit another user's ID. Call a coordinator endpoint directly. Repeat a request after access has been revoked. Use synthetic accounts in your own test environment. The point is to verify your boundaries, not to attack unrelated systems.

Review the places data escapes

Check browser bundles, environment-variable exposure, logs, error responses, repository history, and exported artifacts for secrets or private data. Do not paste discovered credentials into the workbook or an AI prompt. If a real secret has been exposed, containment includes revoking or rotating it, not just deleting the visible string. Limit the permissions of coding agents and avoid giving a routine development session production access.

Treat AI and external content as untrusted inputs

Repository files, retrieved pages, and tool output can contain instructions that do not belong to your task. An assistant should treat that material as evidence. A product with AI tool use also needs permission checks outside model-generated text. For this simple course app, keep the runtime free of unnecessary AI features. A code scanner can find some problems, but a clean scan cannot prove complete security.

SEE THE DIFFERENCE

A small example. A better decision.

THE INITIAL APPROACH

Only coordinators see the Delete button, so deletion is protected.

THE MORE USEFUL APPROACH

The server validates the caller's role and ownership before every delete request. A volunteer calling the endpoint directly receives a denial and the record remains.

Interface visibility helps usability. Server-side enforcement protects the action.

Your build steps

Draw assets, actors, and trust boundaries for your slice.
Run synthetic cross-user and unauthorized-action checks.
Inspect secret-handling and logging paths without copying sensitive values.
Write unresolved risks with owners and verification steps before release.

FROM THE PROMPT LIBRARY

A useful brief for this step.

Threat-model a new feature ↗Finds concrete misuse paths before the feature handles real data.Audit secret exposure paths ↗Finds credentials accidentally reaching source control, logs, or browsers.Review authentication lifecycle ↗Checks more than just a successful login.All security & review prompts

MAKE THE CALL

Think like the reviewer.

The admin button is hidden from volunteers. What additional evidence matters?The hidden button uses a secure-looking icon.A direct volunteer request is denied and the protected data stays unchanged.The page has no visible console warnings.

BUILD YOUR WORKBOOK

A threat model and access review

0/3 notes ready

Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.

1. Threat and boundary mapAdd a specific note of at least 20 characters.2. Access-check evidenceAdd a specific note of at least 20 characters.3. Residual risks and next checksAdd a specific note of at least 20 characters.

Before moving on

I checked authorization outside the visible interface.The workbook contains no passwords, keys, or private records.I stated remaining security uncertainty instead of claiming complete safety.

Loading your workbook…