Security at DueDocs.
A plain-language account of the controls implemented today, their limits, and the work required before production launch.
The short version
- DueDocs uses authenticated accounts and server-managed sessions.
- User-owned database records are protected with Supabase Row Level Security policies.
- Original files are uploaded, downloaded, and previewed only through short-lived, server-authorised links generated after an ownership check.
- Uploads begin under a user-scoped quarantine key and are limited to supported image or PDF types within a defined size cap.
- Auth, uploads, AI extraction, exports, and reminder creation are all rate-limited per account (or per IP before sign-in).
- AI is optional. Suggested information is separate from confirmed document data until you review and save it.
- DueDocs does not currently offer end-to-end or client-side encryption.
Account security
Authentication is provided through Supabase Auth using email verification, password-based sign-in, password-reset flows, and server-side session cookies. Authenticated application routes redirect unauthenticated requests to sign in.
MFA and step-up authentication for especially sensitive documents are not yet implemented. They remain planned controls rather than current features.
User isolation and database controls
DueDocs enables Row Level Security on current user-data tables. Policies generally require the authenticated Supabase user ID to match each record’s owner ID.
Because RLS is enforced per table, it alone can’t stop a request from referencing another user’s record on a related table (for example, attaching a reminder to a folder you don’t own). Every write path that accepts a folder or document reference now independently verifies ownership of that reference before the write, backed by an automated test.
Private file uploads
The browser does not receive R2 credentials and cannot choose another user’s storage prefix. The server verifies the authenticated user owns the draft document, generates a random object key scoped to that user, and issues a short-lived presigned upload URL.
Object keys are scoped per-user and per-document under a quarantine prefix and are not guessable from the client. The upload API accepts a limited set of image and PDF formats within a defined size cap. Completion checks the stored object’s declared content type and size before changing its database status.
Quarantine and file inspection
The quarantine prefix and file-status workflow are implemented, and uploaded files now have their content verified against their declared type, but antivirus scanning, checksum verification, promotion to permanent storage, and abandoned-upload cleanup are not yet complete.
Every uploaded file has its first bytes checked against a known signature for its declared type (for example, that a file claiming to be a PNG actually starts with PNG file-format bytes) before it is made available anywhere else in the product. A file that fails this check is rejected and deleted, and is never made available for review, download, or AI processing. This is a structural content check, not antivirus scanning — it does not detect malware embedded inside an otherwise validly-formatted file.
Until antivirus scanning is implemented and tested, DueDocs should remain a development product and should not accept real sensitive customer documents.
File viewing and downloads
Uploads, downloads, and previews all go through short-lived, server-authorised links. Before issuing a download or preview link, the server re-reads the document record under Row Level Security, so a request for a file you do not own returns nothing rather than a signed link.
Signed links are bearer credentials during their short validity period. They must not be written to analytics, logs, emails, or browser history unnecessarily.
Encryption and its limits
Connections to deployed DueDocs and its providers are intended to use HTTPS/TLS. Infrastructure providers may apply their standard storage-level encryption and access controls.
DueDocs has not implemented application-level, end-to-end, zero-knowledge, or passkey-based file encryption. Authorised server processes and configured AI providers may need to read a file when you request processing. We avoid vague claims such as “military-grade” or “bank-level” security.
AI processing
Provider keys are server-side and never exposed to the browser. DueDocs runs extraction against a primary AI provider (Anthropic) and automatically retries with a fallback provider (OpenAI) on the same request if the primary attempt fails, behind a common extraction contract. See the Privacy Policy for the named providers.
Fallback is currently evaluated per request, not as a standing circuit breaker that remembers a provider outage across requests — that cooldown behaviour is not yet implemented. AI output always remains unconfirmed until you review and save it. Cross-border-processing disclosures are in the Privacy Policy.
Sensitive identifiers
The product specification requires personal document numbers to be masked before confirmed fields are stored and prohibits unmasked values in logs, analytics, and emails.
Document-number masking is implemented client-side: the browser masks the number as you type, and only the masked string is ever submitted to the server, so raw values are never received, stored, or logged. A server-side format check independently rejects any submitted value that is not already in masked form, in case the client is bypassed. Original files may still visibly contain sensitive numbers even after structured metadata is masked.
Secrets and environments
Supabase service credentials, R2 credentials, Anthropic and OpenAI keys, Resend keys, and payment secrets are server-only environment variables. Client-visible variables are limited to publishable configuration intended for browser use.
Secrets must be rotated after any suspected exposure, kept out of source control, separated between development/staging/production, and restricted to the minimum required permissions.
Security work before launch
Done: authenticated private preview/download endpoints, rate limits on auth/uploads/AI/exports/reminders, audit events for sensitive and destructive actions, security headers (CSP, HSTS, X-Frame-Options, Permissions-Policy), relational ownership checks with automated tests, retention/cleanup of abandoned uploads and drafts, dependency and secret scanning, and error monitoring.
Responsible disclosure
If you believe you have found a security issue, do not access, modify, retain, or disclose another user’s data; do not run denial-of-service tests; and do not publicly disclose the issue before we have had a reasonable opportunity to investigate.
Report suspected security issues to support@duedocs.com. We aim to acknowledge reports within 5 business days and to resolve or provide a remediation plan within 120 days. If you follow the rules above and report in good faith, we will not pursue legal action or law-enforcement referral against you for the research itself. DueDocs does not currently operate a paid bug-bounty program.
Limits of this page
This page describes implementation evidence and current development intent in good faith. Security changes over time, software can contain defects, and no system can guarantee absolute security. This page is not a warranty and must be updated whenever the implementation materially changes.