Prepare two fictional records
This is a paper-based teaching example. All accounts, clients, contracts and amounts below are fictional. You can use the cases in your own practice project and then record the actual results.
| Practice account | Client record it may read | Contract ID | Amount |
|---|---|---|---|
| A | A-001 | HT-A-01 | 10,000 CNY |
| B | B-001 | HT-B-01 | 20,000 CNY |
The first requirement is to look up a contract by record ID after login, returning only records the current account may access. Adding, editing and exporting are outside this first exercise.
How the problem might arise
Suppose the page requires login, but its API looks up only the record ID in the input. A enters A-001 and gets its own contract. If entering B-001 also returns B's contract, the query lacks a data access restriction.
Showing only A's clients in the page does not protect the API. A request can come through another route or be modified.
How to arrange the query
- Obtain the current identity on the server from a validated login state. Reject reads of restricted material when there is no login.
- Search within the records that identity may access, together with the entered record ID. Do not trust an account identity supplied by the request itself.
- If there is no accessible record, return a message without contract content. The page might say, “No accessible record found.”
A real system may grant access by person, team or another business rule. Write the rules first, then choose the data structure and implementation that fit.
A test plan for checking a change
The table below contains planned tests and expected results. You need to run them in your own project; these are not completed test results.
| Login state and action | Expected result |
|---|---|
| A looks up A-001 | Return HT-A-01, amount 10,000 CNY |
| A looks up B-001 | Do not return B's contract or amount |
| B looks up B-001 | Return HT-B-01, amount 20,000 CNY |
| B looks up A-001 | Do not return A's contract or amount |
| No login; request A-001 directly | Reject the read without returning contract content |
| A bypasses the page and requests B-001 directly | Apply the same access check; do not return B's records |
| A enters an ID that does not exist | Show a clear message without other contract content |
Record the account, input and actual result for each attempt. Check whether the response contains other records that the page does not display. Looking only at the page can miss extra data returned by the API.
Apply the same rule to new entry points
If you later add search, export or AI Q&A, check that each uses the same data access scope. The system's permissions should also determine what AI can read before answering.
These cases mainly check reading across accounts. A complete project needs other checks according to its features: input handling, editing permissions, logs, deployment and backups. Use the pre-launch checklist to add relevant checks, and the one-page brief to define requirements first.
Questions
Is this a real client project?
Why might a logged-in user still see someone else’s records?
Read next
- Investigating a project problem — Start with specific steps and conditions
- Pre-launch checklist — Add checks for the actual features
- From Vibe Coding to more of your work — Requirements, action, checking and reuse
