How do I check that signed-in users can access only their own records?

Separate entering the app from owning a record

A sign-in screen can work perfectly while private entries remain accessible to the wrong person. Authentication answers who is making the request. Authorization answers whether that person may perform this operation on this record. Keep those two questions separate when asking AI to add cloud storage to a personal app.

Give each private entry a trustworthy owner

In a fictional collection app, the server creates a record under the authenticated user’s identity. It should not simply accept an arbitrary owner supplied by the browser. On a later read or edit, the server checks the relationship again. An entry identifier helps locate a record; knowing the identifier should not by itself grant permission to use it.

Prepare two accounts with invented information

Use a development environment you control. Create one practice account named Cedar and another named Finch, with different sample entries. Keep separate browser profiles or sessions so that switching accounts is unambiguous. This is a test of your own application with your own data, not an invitation to probe someone else’s service.

Check every supported record action

Attempt	Intended result for a private collection
Cedar reads Cedar’s entry	Allowed
Cedar updates Cedar’s entry	Allowed
Finch requests Cedar’s entry	Denied without exposing its contents
Finch updates Cedar’s entry	Denied with the original unchanged
Finch deletes Cedar’s entry	Denied with the original preserved
Signed-out request for a private entry	Denied

Use the application’s test tools or ask the assistant to help exercise these cases safely. You should understand the requested operation and inspect both the response and the stored result.

Check the data after a denied change

A message saying “not allowed” is insufficient if the entry changed anyway. After the attempted edit or deletion, return as the rightful owner and verify that the original record remains intact. Also check that a denied read does not reveal the private note in an error message. This makes the outcome observable beyond the appearance of the interface.

Keep public sharing a separate feature

If the app later supports public entries, define that choice explicitly. Test the private default, deliberate sharing, and any supported revocation behavior separately from ownership. A browser filter or hidden button can help the interface, but the trusted service must enforce the rule. Before allowing real users to store important information, review the complete access design with someone able to assess the server and its deployment.

Evidence and scope

• OWASP Authorization Cheat Sheet: Authorization must be checked on every request and enforced in a trusted component.
• MDN Client-server overview: Client-server applications exchange requests and responses, with server-side code processing requests.

The proposed checks are teaching tools; validate their behavior in the actual environment.