Lesson 1 of 7
Map a request before you trust it
Explanation
A browser request is only a claim: it might say who the user is, which record they want, and what action they want to take. Your server should identify the signed-in user itself, load the real record, check the requested action, and then allow or deny it. This is safer than trusting an id or role sent from a page.
Visual explanation
Read this from left to right: what goes in, what happens, and what comes out.
The server is the checkpoint between an untrusted browser request and a sensitive action.
In plain language
A request is only a request. The server checks who is signed in and what that person may do before changing data.
Remember
The browser asks; the server decides.
What to do
Put these in the safe order: browser request, server checks identity and ownership, allow or deny.