Authorization vs authentication: logged in isn't the same as allowed

You're logged in. You change the id in the address bar to someone else's. Do you see their order?

If yes, the app authenticated you but never authorized you. Those are two different questions.

Supabase draws the line in two sentences: "Authentication means checking that a user is who they say they are." And: "Authorization means checking what resources a user is allowed to access."

The classic bug lives in the gap: a correctly logged-in user changes a record's id and reads someone else's data. OWASP calls this broken object level authorization, and it's consistently one of the most common API weaknesses. Note that authentication worked perfectly; authorization was simply never checked.

On a Supabase-style app, the fix is the toggle above. Supabase: "Use RLS policies to authorize data access from the client." A Row Level Security policy adds a filter to every query so a request only ever returns rows the asker is allowed to see.

OWASP's two guiding habits: grant "only the minimum privileges necessary" (least privilege), and "deny access by default", so a resource is locked unless a rule explicitly opens it. The Moltbook lesson is what happens when neither is true.

Try it with the rules off. In the sandbox, flip Row Level Security off and, while logged in as Ana, read Ben's order by asking for it. You were authenticated the whole time. Turn RLS on and the same request returns only your own rows.