Security & data

Your data, and what we do with it

Your bookings, customers and payment records are your business records. This page sets out where they live, how they are protected, who can reach them, and how you get them back.

We have tried to describe mechanisms rather than make claims. Where something depends on how a specific environment is configured, we say so.

Hosting

Glovebox runs as a managed Laravel application on cloud infrastructure, deployed and provisioned through Laravel Forge. Application media and database backups are stored in Cloudflare R2 object storage, which is S3-compatible and globally distributed rather than pinned to a single named region.

[REVIEW] Hosting provider and server region. Forge is provider-agnostic and the committed configuration does not name a compute provider or region, so "DigitalOcean" and any NZ or Australian region claim cannot be verified from this codebase. Confirm the actual provider and server region before publishing this section. (The object-storage line above is verified: the environment documentation states production runs Cloudflare R2, using R2's literal auto region. Note that "globally distributed" means data residency is not a single-country guarantee, so do not turn this into an NZ data-residency claim.)

Backups

The database is dumped on a schedule, not on request:

  • A full database backup runs every six hours, on one server, in the background so a slow upload never blocks anything else.
  • Dumps are compressed and written to the configured storage disk. In an environment with an object-storage bucket configured, that means offsite storage rather than the application server.
  • The 50 most recent backups are kept and older ones are pruned automatically. At a six-hourly cadence that is roughly 12.5 days of history.
  • Every run reports its outcome to a monitoring portal as a signed heartbeat, so a backup that fails or silently stops running is visible rather than being discovered when it is needed.

Retention length and the destination disk are configurable, so an operator-specific arrangement is possible.

[REVIEW] Restore testing. The backup schedule and retention are verifiable in code; how often a restore has actually been rehearsed, and the target recovery time, are operational facts this codebase cannot answer. Either state the real position or drop the sentence.

Encryption

In transit

Glovebox is served over HTTPS. Custom domains attached to an operator's booking site have their TLS certificates issued and renewed automatically, and the platform tracks certificate issuance until a domain is live.

[REVIEW] TLS specifics. Certificate issuance for custom domains is verifiable, but the TLS version floor, cipher policy, HSTS, and whether HTTP is redirected or refused are all edge/server configuration that is not committed to this repository. Confirm with the actual server and CDN configuration before making any specific claim.

At rest

Beyond whatever the storage layer provides, particularly sensitive fields are encrypted by the application before they are written, so they are unreadable in a database dump without the application key. That currently includes:

  • vehicle lockbox codes;
  • accounting integration tokens (Xero access and refresh tokens);
  • messaging provider API credentials;
  • partner IRD numbers and bank account numbers;
  • partner vehicle insurance policy numbers; and
  • stored payment gateway responses.

Card numbers are not among that list because Glovebox never receives them. Card details are entered directly into the payment provider's hosted fields, and Glovebox stores only the provider's token and the last four digits.

[REVIEW] Storage-layer encryption at rest (full-disk or managed-database encryption) depends on the hosting provider and plan, which is the same unverified item as the Hosting section above. Confirm before claiming it.

[REVIEW] PCI DSS. The hosted-fields description above reflects how the code integrates with the payment provider. Any formal PCI compliance level or SAQ type is a certification question, not a code question. Do not state one without the paperwork.

How workspaces are kept separate

We would rather describe this precisely than reassuringly, because the mechanism is the thing that matters.

Glovebox is a multi-tenant application running on a shared database. Every record belonging to an operator carries that operator's workspace id, and separation is enforced in the application layer: a global query scope adds a workspace filter to every query against workspace-owned data, so one workspace's queries return only that workspace's rows.

That is a real and standard mechanism, and it is the one most SaaS products of this size use. It is worth being clear about what it is not: it is not physical separation, and it is not a separate database per operator. Its correctness depends on the application applying the filter everywhere it should, which means it is guarded by tests rather than by the storage engine.

Concretely, on our side that means: a cross-workspace isolation test sweep runs against the workspace-owned models as part of the test suite, entry points that can run outside a workspace context (webhooks, scheduled jobs, command-line tooling) are the ones we treat as highest risk, and we have hardened specific paths after finding them. We would rather tell you that than claim the problem cannot occur.

Separately from database rows, cached data, queued jobs and uploaded files are also partitioned per workspace.

[REVIEW] Independent assessment. If a third-party penetration test or security review has been done, say who and when. If not, this section should say nothing about external validation. Do not imply one has happened.

Who can access your data

Your team

People you invite, and only within your workspace. Access is role-based, so staff do not automatically get owner-level reach. If someone belongs to more than one workspace they switch between them explicitly; there is no view that spans workspaces.

Owner accounts must have two-factor authentication enabled. Enrolment is phased in rather than switched on without warning, and once the deadline passes an owner without two-factor is redirected to set it up before they can carry on. Other roles can enable it too. Password resets require a minimum password length of 12 characters.

Us

Glovebox platform staff hold a separate super-administrator flag, which is deliberately not mass-assignable and can only be granted through explicit, trusted paths in the code. It exists so we can support you, investigate a problem you have reported, and operate the platform.

[REVIEW] Support access policy. The technical mechanism is verifiable; the policy around it is not. Say plainly whether staff access to an operator's live data requires the operator's request or consent, whether such access is logged and notified, and how many people hold the flag. An honest short answer here is worth more than a vague strong one.

Sign-in audit trail

Sign-ins, failed sign-ins, sign-outs and password resets are recorded to an audit log with the email, IP address, user agent, workspace and host. Those records are kept for 180 days and pruned automatically after that.

Getting your data out, and what happens if you leave

Your operating data is yours. We hold it to run the service for you, not as something we acquire by holding it.

Our platform terms commit to this: you can close your account at any time, and after termination you can export your data for 30 days, after which it may be deleted.

[REVIEW] Export mechanism. The 30-day commitment above is quoted from the published platform terms and is safe to state. What is not verifiable from the codebase is how an operator performs a full account-wide export: the repository has a comprehensive CSV import pipeline and a targeted abandoned-booking CSV export, but no general "export everything" tool was found. Before publishing, either point this paragraph at a real self-serve export, or state plainly that export is handled by request through support and give the turnaround.

[REVIEW] Deletion timeline. State what "may be deleted" means in practice after the 30 days, and how long deleted data persists in the rolling backups described above (on the current retention that is roughly 12.5 days). Also confirm whether deletion is on request or automatic.

Reporting a security issue

If you think you have found a security problem in Glovebox, email hello@getglovebox.co.nz with enough detail to reproduce it. Please give us a reasonable chance to fix it before disclosing it publicly.

[REVIEW] Consider a dedicated security address and a stated response window. Also decide whether to publish a /.well-known/security.txt. Neither exists today.

Questions about any of this? Get in touch.