Application security becomes easier to reason about when students separate three questions: who can access the data, what can they do with it, and how is the data protected while stored or transmitted?
Scenario: peer tutoring scheduler
A tutoring scheduler stores available time slots. Tutors can update their own availability, coordinators can view all schedules, and visitors can only request appointments.
| Role | Needed access | Risk if too broad |
|---|---|---|
| Visitor | Create request | Could view private schedules |
| Tutor | Edit own times | Could change other tutors' calendars |
| Coordinator | Review requests | Could accidentally expose all records |
Least privilege
Least privilege means each role gets only the permissions needed. A tutor should not be an administrator just because that is easier to configure. Broad permissions create bigger mistakes when an account is misused.
Protecting the data
- Use HTTPS so appointment details are encrypted in transit.
- Store only the data needed to schedule the session.
- Keep role changes logged.
- Use backups or version history so accidental deletion can be recovered.
Practice prompt
Design a permission table for a school club inventory app. Include visitor, member, officer, and teacher roles. For each role, decide whether they can view, add, edit, or delete records.