Security & Data Privacy¶

Toodle manages user accounts, academic information, tutor allocations, and teaching records. Protecting this information is an important part of the system's design.

Our security approach combines established authentication services, role-based access control, backend validation, and responsible handling of personal information.

Authentication¶

Toodle uses Auth0 to manage authentication rather than implementing its own password management system.

Users sign in through Auth0 Universal Login, which supports Google Sign-In and email/password authentication.

Once authenticated, the frontend sends an Auth0 access token to the backend. The backend verifies the token and checks the user's account before allowing access to protected functionality.

Application roles and permissions are maintained in Toodle's database rather than being determined by the frontend.

Password recovery is handled through Auth0's existing reset process. Toodle does not store user passwords.

Role-Based Access Control¶

Toodle implements four application roles:

Role	Main Responsibilities
Administrator	Manages users, staff access, roles, courses, and platform-wide operations
Lecturer	Manages tutoring activities for assigned courses, including applications, allocations, and approvals
Tutor	Manages assigned courses, availability, timesheets, excusals, and session swaps
Student	Completes onboarding, applies for tutoring opportunities, and volunteers for available work

Permissions are enforced by the backend using role checks, resource ownership, and course-coordinator assignments.

Lecturers are associated with courses through coordinator records. This allows course-management operations to be restricted to authorised staff where appropriate.

Hiding a button or page in the frontend is not considered sufficient protection; protected operations must also be authorised by the API.

Administrator Safeguards¶

Only Administrators can change application roles or approve requests for staff access.

To prevent accidental administrative lockout:

Administrators cannot demote their own accounts.
The last active Administrator cannot be demoted.
Role changes are checked on the backend and take effect through the user's database account.

These safeguards help maintain authorised access to system administration.

Staff Access and Invitations¶

Toodle provides a separate access process for academic staff rather than requiring them to complete Student onboarding.

Administrators can review staff access requests or issue invitations to an email address.

Invitations are associated with the intended staff role and, where applicable, assigned courses. They expire after seven days.

When an invited user signs in, the backend checks the verified email address provided by Auth0 before accepting the invitation and granting the appropriate access.

The system does not trust role selections or email-verification claims supplied directly by the browser.

Existing privileged accounts are not automatically overwritten through the invitation process.

API Security¶

Toodle's REST API acts as the main access point for application data.

The backend implements several protections:

Token validation: Protected operations require valid Auth0 access tokens.
Role and ownership checks: Sensitive actions are restricted according to the user's permissions.
Input validation: Incoming request data is checked before relevant operations are performed.
Business-rule validation: Allocations, applications, timesheets, and other workflows are checked against their requirements.
Rate limiting: API requests are limited to reduce excessive traffic.
Error handling: Production responses avoid unnecessarily exposing internal error details.

Protected requests are evaluated on the server, independently of frontend navigation controls.

Public and Protected Endpoints¶

Not every API endpoint requires the same authentication.

Selected course information can be accessed publicly, supporting external read-only access to the course catalogue and scheduled sessions.

Calendar subscription feeds are accessible through private, revocable URLs. The subscription token acts as the credential for accessing the associated calendar.

User profiles, academic records, tutor-management operations, and administrative functionality require appropriate authentication and permissions.

External machine-to-machine access is limited to the supported read-only API operations and applicable permissions.

For detailed endpoint access rules, see the API Reference.

Database Security¶

Toodle stores relational application data in PostgreSQL hosted on Supabase.

The frontend accesses application data through the Express API rather than connecting directly to the PostgreSQL database.

The backend uses Prisma ORM, database relationships, constraints, and application-level validation to support data integrity.

Important operations use database transactions to coordinate related changes, including allocations, approvals, session swaps, and account-management operations.

Database credentials are stored in backend environment configuration and are not exposed to the frontend.

For the database structure and relationships, see Database Design.

Secrets and Environment Variables¶

Sensitive credentials are managed through environment variables and hosting-platform configuration rather than being written directly into application source code.

These include:

Database connection credentials.
Auth0 configuration and backend management credentials.
Email service API keys.
Supabase Storage credentials.
Deployment and integration secrets.

Files containing real credentials, such as .env, must not be committed to the project repositories.

Example configuration files use placeholders to identify required settings without exposing secret values.

Personal Data and Privacy¶

Toodle collects information needed to support tutor-management activities.

Depending on the user's role, this may include:

Name, email address, and account information.
Academic role and year of study.
Course marks and tutoring applications.
Availability and timetable information.
Course allocations and scheduled responsibilities.
Timesheets and recorded teaching hours.
Excusal requests, volunteer claims, and session swaps.
Notifications and relevant activity history.

Access to this information depends on the user's role and the operation being performed.

Privacy Principles¶

Our approach follows these principles:

Purpose limitation: Personal information is used for relevant Toodle functionality.
Data minimisation: The system should collect only information needed for its workflows.
Controlled access: Users receive access according to their role and responsibilities.
Data accuracy: Users and authorised staff can update information through permitted workflows.
Secure configuration: Credentials and sensitive configuration remain outside application source code.
Responsible logging: Diagnostic and audit records should avoid unnecessarily exposing personal information.
Appropriate retention: Historical records may be preserved where needed to maintain the integrity of academic and work-related activities.

These principles guide how the team handles information; they are not a claim of independently certified regulatory compliance.

Account Closure and Data Retention¶

Users can initiate account closure through their profile.

To prevent accidental closure, the process requires the user to confirm their registered email address.

Before an account can be closed, the backend checks for outstanding responsibilities that require attention, such as future teaching commitments or unfinished timesheets.

What Happens During Account Closure?¶

The account-closure process:

Changes the user's account status to prevent further normal access.
Anonymises relevant current profile information.
Resolves or retires applicable pending activities and access assignments.
Preserves historical academic and work-related records where necessary.
Attempts to remove the associated Auth0 identity and stored avatar.
Records any outstanding external cleanup work so it can be retried.

External identity and storage operations are performed separately from the database transaction. If cleanup cannot be completed immediately, the account remains inaccessible while the remaining work is tracked.

Closing an account therefore does not necessarily mean that every historical record is physically deleted.

Returning After Account Closure¶

Once the required closure and identity-cleanup conditions have been satisfied, a returning user may complete a fresh registration through Auth0.

A newly registered account begins with the default Student role. Previous permissions, tutoring allocations, and historical responsibilities are not automatically restored.

This separates the new account from the previously closed account while retaining the necessary historical records.

Security Checks and Quality Assurance¶

Security-related checks form part of the team's development and review process.

These include reviewing:

Authentication and protected-route behaviour.
Role-based permissions and resource ownership.
Input validation and invalid request handling.
Sensitive information returned in API responses.
Secrets and environment configuration.
Account and role-management safeguards.
Relevant automated tests and integration behaviour.

Security checks are considered alongside the normal testing and Pull Request review process.

Security Incident Handling¶

If a security-related issue is discovered, the team follows a structured response:

Record and communicate the issue.
Assess its impact and avoid exposing sensitive details publicly.
Revoke or rotate affected credentials where necessary.
Implement a correction through the normal development workflow.
Test and review the correction.
Deploy the updated application and confirm the relevant behaviour.

Exposed credentials are treated as potentially compromised, even if the original source-code reference is later removed.

Summary¶

Toodle combines Auth0 authentication, backend access control, input validation, secure configuration, and database integrity measures to protect its users and application data.

The system also separates staff responsibilities, controls access to academic records, and preserves relevant historical information during account closure.

Together, these measures support a practical security and privacy approach for a university tutor-management application.