Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Security Basics  ›  Lesson

Check Who Can See What

Security Best Practices 15 minLogging in proves identity, but every request must separately check that the user is allowed to act on the specific data it touches.

Check Who Can See What

Kitty now has accounts, and other flats have started using it. While testing, you log in as yourself and open /flats/12/expenses, your own flat. Out of curiosity you change the 12 to 13 in the address bar, and you see a stranger's grocery bills. Your login worked perfectly. What was missing was a different check entirely.

The rule

Login proves who you are; every request must still check what you may do.

Two words are easy to mix up:

  • Authentication answers "who are you?" It is the login: a password checked, a session started.
  • Authorisation answers "are you allowed to do this, to this thing?" It has to be asked again on every request, for every flat, expense and payment it touches.

Assistants often build a solid login and then forget authorisation, because the feature "works" when you test it with your own data. The fix is a check inside every function that reads or changes data:

def list_expenses(db, current_user, flat_id):
    is_member = db.execute(
        "SELECT 1 FROM members WHERE flat_id = ? AND user_id = ?",
        (flat_id, current_user.id),
    ).fetchone()
    if is_member is None:
        raise PermissionError("You are not a member of this flat")
    return db.execute(
        "SELECT * FROM expenses WHERE flat_id = ?", (flat_id,)
    ).fetchall()

Two more rules. Deny by default: a new action is forbidden until a rule allows it, not allowed until a rule forbids it. And hiding a button is not protection. If the delete button is hidden but the server accepts the delete request, anyone who sends that request directly can still delete.

The shortcut

Change the number. For every address or request that contains an id, ask: what happens if I change it to someone else's? Then test it for real with two test accounts in two different flats.

Testing Kitty with two accountsStep 1 of 4
  1. Set up

    Test account A belongs to flat 12, test account B to flat 13. Use made-up data only.

The trap is testing only with your own account. Every check passes when you are allowed to do everything you try.

Drills

Answer fast — trust the rule.

quick drill

What is the difference between authentication and authorisation?

quick drill

Logged in as a member of flat 12, you change the address to flat 13 and see its expenses. What is missing?

quick drill

The assistant hid the delete button from people outside the flat. Is that enough?

quick drill

Which default is safest for a new action in Kitty?

Remember

  • Rule: login proves who you are; every request must still check what you may do.
  • Shortcut: change the number, with two test accounts in two different flats.
  • Trap: testing only as yourself, and treating a hidden button as a locked door.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainLock the delete

Explain how you would check that Kitty's 'delete expense' action is properly protected. Include the test you would run with two accounts, and explain why hiding the delete button is not enough.