Security
You are uploading trade licences, bank solvency certificates and contracts. This page says plainly what we do about that — and what we do not yet claim.
Tenant isolation
- Every table holding customer data has PostgreSQL row level security enabled.
- Queries run as the signed-in user, so a bug in application code cannot read another organization's rows: the database itself refuses.
- Tables that no browser session should ever read — raw payment provider payloads, rate limiting counters — have no policy at all and are reachable only by trusted server code.
- Cross-organization isolation is covered by an automated test suite that runs against a real PostgreSQL instance on every change.
Your documents
- Files are stored in a private Cloudflare R2 bucket. Nothing uploaded by a customer is publicly readable.
- Downloads use signed links that expire in minutes, and membership is re-checked on every request.
- Object keys are generated by the server. Your filename is metadata, never part of the storage path.
- Uploads are checked twice: the declared type and extension must agree, and the file's actual leading bytes must match. Executables are rejected.
- Documents are served with a restrictive content policy and a sandbox directive so a malicious file cannot execute in the context of the application.
Accounts and access
- Passwords are hashed by Supabase Auth; we never see or store them.
- Sessions use HttpOnly, Secure, SameSite=Lax cookies.
- Five roles — owner, admin, manager, member and viewer — enforced both in the interface and in database policy.
- An organization can never be left without an owner, and only an owner can grant ownership.
- Nobody can promote themselves to platform administrator: that column is not writable by any user session.
- Invitations are single-use, expiring, and only a SHA-256 hash of the token is stored.
Application hardening
- A Content Security Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and a restrictive Permissions-Policy on every response.
- HSTS once served over HTTPS in production.
- State-changing requests are checked for same-origin, in addition to SameSite cookies.
- All input is validated against an explicit schema before it reaches the database, which has its own constraints as a backstop.
- Rate limiting on sign-in, sign-up, password reset, invitations, uploads, imports and checkout.
- Dependencies are audited automatically on every build.
Payments
- We never receive or store card numbers. Card payments go through Lemon Squeezy as merchant of record.
- A subscription is only ever activated by a verified provider event. A browser returning to a success URL proves nothing and activates nothing.
- Webhook signatures are verified before the payload is parsed, and events are deduplicated so a redelivery cannot double-charge or double-apply.
- A scheduled reconciliation job re-checks subscription state, so a webhook lost in transit self-heals.
Auditability
- Significant actions are recorded: deadline changes, reassignment, document upload and deletion, role changes, renewals and billing changes.
- The audit table is append-only and enforced as such by the database. Entries cannot be edited or deleted, including by us.
- Renewal history is also append-only: recording a new cycle never overwrites the previous one.
- Reminder delivery attempts are logged with the provider's response.
Operational logging
- Logs are structured JSON with request identifiers, so a production problem can be traced.
- Field names matching key, secret, token, password, authorization, cookie, signature or payload are redacted before anything is written.
- We do not log document contents or email bodies.
What we do not claim
DeadlineDesk is a young product. We are not SOC 2 or ISO 27001 certified, we have not commissioned an external penetration test, and we do not offer a contractual uptime guarantee on self-service plans. Backup and recovery capability depends on the infrastructure tier the service runs on; we will not describe it as enterprise-grade disaster recovery when it is not. If any of these are requirements for your business, talk to us before you commit.
Reporting a vulnerability
If you believe you have found a security problem, email hello@getdeadlinedesk.com with enough detail to reproduce it. Please do not test against other customers' data. We will acknowledge your report and keep you informed while we fix it.