Access control policy

User authentication

• Accounts are created with email/password or Google sign-in; passwords are hashed by the auth provider and never stored by Depozza.
• Leaked-password checking is applied at sign-up and password change.
• Sessions are bearer-token based, expire automatically and are cleared on sign-out.

Authorisation in the product

Every database table enforces row-level security. A user can only read and write rows they own, or rows tied to a booking they are party to. Sensitive columns (payment identifiers, identity-verification data, contact details of counterparties) are additionally revoked at column level, so a policy mistake alone cannot expose them.

Administrative access

• Administrator status is stored server-side and never inferred from client state.
• Privileged operations run through audited server-side functions, not direct table writes.
• Administrator actions on users, listings, disputes and tickets are written to an append-only audit log.

Least privilege on the backend

• Anonymous visitors can only read explicitly public data (published listings, public host profiles).
• Execute permissions on privileged database functions are granted from an allowlist, not by default.
• Service credentials are held only by the server runtime and are never exposed to browsers.

Joiners, movers, leavers

Access is granted on a documented need, reviewed at least annually, and removed the same day someone stops needing it. Requests and removals are recorded.