Understand permissions with two fake accounts

Separate signing in from permission

Signing in establishes which account someone is using. Permission determines what that account may do afterwards. A customer can be correctly signed in and still be allowed to open someone else’s private note by mistake. That is broken access control. OWASP describes it as a major application risk. [1]

Imagine you built a tutoring app. Ella and Noah each have private lesson notes. “Signed-in customers can open notes” is too broad: it says nothing about whose notes. A clearer rule is: “Ella can read Ella’s notes; Noah can read Noah’s notes; neither can open the other’s notes unless an intentional sharing feature allows it.” Write the actual product rule before asking AI to judge code.

Bring Ruthless a tiny, complete example

Ask your builder to make a private copy of the app for fake users, with Ella-test and Noah-test accounts. Save a note containing ELLA-FAKE and a separate note containing NOAH-FAKE. These visible markers help you recognise a leak without using private information. Keep the real users out of the exercise.

Open GetRuthless chat, inspect Choose model and select an available model suited to explaining the rule. If the answer needs code, ask your builder for a redacted excerpt of the request handler: the small piece of service code that responds when someone opens a note. Also ask for the saved ownership field, such as ownerAccountId, explained in words. Share no passwords, keys or browser login values.

Teach me how to check permissions in my own tutoring app. Private test copy only: Ella-test owns note E-10 containing ELLA-FAKE; Noah-test owns note N-20 containing NOAH-FAKE. Neither account may read or edit the other note. Explain what my builder should check in the service that opens and saves notes. Give one allowed read, one forbidden read and one forbidden edit, with exact evidence needed. Distinguish a proposed check from a test someone actually ran. Ask for missing redacted code rather than guessing.

Read the result behind the screen

A good plan begins with Ella reading E-10 successfully. That confirms the feature works for its owner. The builder then keeps Ella signed in and asks the service for N-20, using only the fake note identifier you already created. An identifier is the label the app uses to locate a record; it is not proof of permission.

For the forbidden read, a pass means no NOAH-FAKE content comes back. For the forbidden edit, a pass means the service refuses it and Noah’s saved note remains unchanged when Noah opens it. A red “not allowed” message is insufficient if the private content was returned anyway. Ask Ruthless to explain the builder’s redacted before-and-after evidence if you cannot read it.

If your app includes file downloads or team sharing, those are separate paths. Passing the notes-page check says nothing about an attached file’s download link. Pick the next path deliberately rather than accepting “permissions fixed everywhere” from one successful result.

Turn a result into your next question

Try this exercise: write who should be able to edit a shared lesson note after a teacher removes a collaborator. Ask Ruthless which account must be used to prove removal took effect. A strong answer checks the removed account directly, then confirms the remaining teacher still has access. If the rule is unclear, settle the intended sharing behaviour before anyone changes code.