Security & Data Privacy

Toodle handles user accounts, academic information, tutor allocations and work records. Security and privacy therefore need to be considered throughout development.

Authentication

Authentication is handled through Auth0 rather than implementing a custom authentication system.

Google Sign-In is available through Auth0 and has been successfully tested on the deployed application.

Using an established authentication provider reduces the risk of insecure password handling and gives the project a standard authentication flow.

Role-Based Access

Toodle has three main user roles:

• Organiser
• Tutor
• Student

Users should only be able to access functionality appropriate to their role.

For example:

Role	Example Access
Organiser	Manage courses, tutors and allocations
Tutor	View allocations, availability and timesheets
Student	View and volunteer for available overflow work

Authentication identifies the user, while role-based access rules determine which functionality that user may access.

Role restrictions should be enforced by the backend and not rely only on hiding frontend elements.

API Security

Protected API endpoints should require a valid authenticated request.

The backend should:

• verify authentication tokens;
• reject unauthenticated requests to protected endpoints;
• enforce role permissions;
• validate incoming request data;
• return appropriate error responses; and
• avoid exposing unnecessary internal information.

Client-side restrictions alone are not considered sufficient protection.

Secrets and Environment Variables

Sensitive values must not be stored directly in source code.

Examples include:

• database credentials;
• Auth0 secrets;
• API credentials;
• deployment tokens; and
• service keys.

These values are stored using environment variables or hosting-platform secrets.

Files such as .env containing real credentials must not be committed to Git.

Example environment files may contain variable names, but should use placeholder values rather than real secrets.

Database Security

The PostgreSQL database is hosted through Supabase.

Database access should occur through authorised application services rather than exposing database credentials directly to users.

The application should:

• validate data before storing it;
• use appropriate database relationships and constraints;
• restrict unnecessary database access;
• avoid exposing sensitive fields through API responses; and
• maintain audit information where required.

Personal Data

Toodle should collect only information required for tutor-management functionality.

This may include:

• user identity;
• university-related user role;
• course information;
• tutor marks;
• availability;
• allocations;
• timesheet information;
• excusals; and
• volunteer-work information.

Data should not be collected simply because it may be useful later.

Data Privacy Rules

The project follows these privacy principles:

1. Purpose limitation
   User information should only be used for legitimate Toodle functionality.

2. Data minimisation
   Only information necessary for tutor-management workflows should be stored.

3. Access control
   Users should only see information required by their role.

4. Secure configuration
   Credentials and secrets must remain outside the source code.

5. Controlled sharing
   User information should not be exposed to unrelated users or external services without a legitimate system requirement.

6. Data accuracy
   Users and organisers should be able to correct information where the application workflow permits it.

7. Responsible logging
   Logs should help diagnose problems without unnecessarily recording sensitive information.

Access Restrictions

Access restrictions are applied according to the user's authenticated role.

Examples include:

• students should not have organiser administration privileges;
• tutors should not modify allocations that require organiser authority;
• unauthenticated users should not access protected tutor-management information; and
• organiser-only API operations should verify organiser permissions on the server.

As additional functionality is implemented, each protected feature should define which roles are permitted to access it.

Security Checks

Before changes are merged or deployed, the team should check that:

• no credentials have been committed;
• protected routes require authentication;
• role restrictions are enforced;
• invalid input is rejected;
• sensitive data is not unnecessarily returned by APIs;
• environment variables are correctly configured; and
• authentication still works after deployment.

Security Incident Handling

If a security problem is discovered:

1. record and communicate the issue to the team;
2. avoid exposing sensitive information in public discussions or commits;
3. remove or rotate compromised credentials where necessary;
4. correct the problem on an appropriate branch;
5. review and test the fix; and
6. deploy the corrected version.

A leaked credential should be treated as compromised even if the related commit is later deleted.

Why This Approach?

Toodle uses established services such as Auth0 and structured backend access controls instead of creating custom security mechanisms unnecessarily.

Combining authentication, role-based access, input validation, protected secrets and data-minimisation principles reduces the risk of unauthorised access while keeping the security approach appropriate for the scale of the project.