When "Signed In" Is Doing a Permission Check's Job

When a route treats a valid session as permission to touch one specific record, signed in is not authorization: the login is doing a permission check's job, and it can't. The two only line up on routes where every signed-in user may see everything. That stops being true the moment a second customer's data lands in the same table.

The same document, two routes, two verdicts

Take one saved document and two actions on it: editing it and deleting it. Both routes require a signed-in session. Neither compares the document's owner to the person asking. On paper, that's the same mistake made twice. In the worked example that ships with Logged-In Is Not Allowed, the two routes land in different places.

Both routes miss the same line of logic, and only one is graded as if it had no protection at all. That is the correct read, and the reason behind it decides what you fix first.

Why the identical gap gets two verdicts

The edit route is broken in a way that needs someone to already have, or stumble on, a specific document's id. The delete route is broken in a way that needs nothing. Sign up for a free account, count from one, and every document in the table is reachable in order. The login requirement isn't protecting the delete route from anything, and calling it LOGGED-IN ONLY like its sibling would understate how little stands in the way.

So the read-off treats a countable id with no ownership check the same as a route with no signed-in check at all. Both read NOBODY IS CHECKING, because both offer the same protection, which is none. The login screen looks identical either way.

Three verdicts for a whole app

Roll every route up and the app lands in one of three places. PERMISSIONS HOLD means no route reads LOGGED-IN ONLY or NOBODY IS CHECKING. SIGNED IN IS DOING TOO MUCH means at least one route stops at signed in on a record that could be someone else's, and none is worse. ANYONE CAN WALK IN means at least one route reads NOBODY IS CHECKING. The roll-up doesn't average. A stranger only needs one open door, so nine good routes don't change what happens at the tenth.

The kit's ten-route worked example plays out like this. Three routes read NOBODY IS CHECKING: viewing a customer order with no signed-in check, the countable delete route, and a third that the next section explains. Two read LOGGED-IN ONLY. The other five pass: downloading an invoice, opening a saved document and changing the account email read AUTHORIZED, while opening the dashboard and submitting feedback read MEMBERSHIP IS ENOUGH and never count against the app. The verdict is ANYONE CAN WALK IN, the worst of the ten, because that's the honest answer to "can anyone reach data that isn't theirs."

When you can't find the answer

Two routes in that sample show what "can't find" does. R-10 reads the team directory, a route that only touches data the whole account shares. Nobody could find whether it checks for a signed-in user, so it's scored as having no check and reads NOBODY IS CHECKING. R-08, an admin list of every user, does have a login check, but nobody could find anything confirming the caller's right to see that list. That unknown is scored as unchecked, and R-08 reads LOGGED-IN ONLY. An answer you can't find after a real look resolves to the unsafe side, because from a stranger's side of the request, "I couldn't find the check" and "there is no check" work the same way.

That rule has a cost, and the kit says so. It can make a result look worse than the app is: R-10 may well have a login check that nobody located. The dashboard counts the routes resolved from "can't find" separately, so you can see how much of the verdict is broken and how much is not yet looked at. The fix for the second kind is to go and look.

Audit routes as a group, not one at a time

The edit-and-delete split above tends to repeat across an app: several actions on one type of record, built at different times, guarded differently. Checking them as a group catches it.

1. Group routes by record type. Documents, orders, invoices, whatever your app's core objects are. Test: list every action your app performs on each type: view, edit, delete, download, share.
2. Check every action the same way. Test: for each action, find the login guard and the ownership comparison, as you would for a single route.
3. Look for inconsistency in a group. Test: if viewing a document checks ownership but deleting it doesn't, you have one record type with a hole in it, and the hole is whichever action skipped the check.

Pairs well with

A login check that only runs in the browser isn't a signed-in check at all, and The Browser Line Read-Off ($59) rolls those up to LINE HOLDS, LINE LEAKS or NO LINE. The Supabase RLS Read-Off ($69) reads the database layer underneath, where one browser-reachable service-role key rewrites the whole matrix to PROJECT OPEN. And the Vibe-Coded App Hardening Kit ($79) covers the rest of a production-readiness pass, with a 10-antipattern catalog and a 6-layer checklist. Our guide on how to secure an AI-built app walks the same ground in plain steps.