How AiresDocs keeps documents safe and provable

Overview

• Encrypted in transit and at rest. HTTPS everywhere; AES-256 encryption on stored files and the database.
• Hashed. SHA-256 of the original upload and the final PDF, recorded and printed on the certificate.
• Append-only audit trail. Events can be added, never edited or deleted.
• Expiring, unguessable links. 256-bit random tokens, stored hashed, expiring after 30 days by default.
• Stored in London. Database and files in the UK (AWS eu-west-2 via Supabase).
• Yours to export or delete. ZIP export and account deletion from settings, no email required.

Encryption in transit and at rest

Every connection to airesdocs.com, app.airesdocs.com and api.airesdocs.com is over HTTPS (TLS 1.2 or later), terminated by Cloudflare and encrypted again between Cloudflare and our backend services. HTTP Strict Transport Security is enabled so browsers refuse to connect insecurely. Signing links, downloads and API calls are never served over plain HTTP.

At rest, documents, signature images and logos are stored in private Supabase Storage buckets, and metadata in a Supabase Postgres database; both are encrypted at rest with AES-256 by the underlying AWS infrastructure. Backups are encrypted in the same way. Supabase states: All customer data is encrypted at rest with AES-256 and in transit via TLS. (Supabase security page, checked 11 October 2026). There is no public bucket: a file can only be fetched with a signed URL that our API mints for the document owner or for the specific signer holding a valid token, and those URLs expire after 5 minutes.

Hashing and integrity

A hash is a fixed-length fingerprint of a file: change one byte and the fingerprint changes completely. AiresDocs computes the SHA-256 hash of your PDF when you upload it and stores it with the document. When the last signer finishes, the fields are flattened into the PDF, the completion certificate page is appended, and the final file is hashed again. Both hashes are stored, printed on the certificate and sent to every party.

Anyone who later holds a copy can confirm it is unaltered: upload it to the public verification page, or run sha256sum on it, and compare with the final hash. Because the certificate page is part of the final file, the hash on the page describes the file that contains it. Verification does not need an account and does not depend on trusting us: the arithmetic is the same anywhere. See How to verify a signed contract.

Append-only audit trail

Each document has an event log: created, sent, viewed, consented, field completed, signed, declined, reminded, voided, completed. Each event stores a UTC timestamp, the actor's email address, their IP address, their browser's user agent string and any details (such as a decline reason). The table that holds these events accepts inserts only: a database-level trigger rejects any UPDATE or DELETE, and only our server-side API, not the browser app, can insert. Document owners can read their own documents' events through row-level security; nobody else can.

This is what makes the certificate credible: the log that is printed on it could not have been edited after the fact, by a customer or by us.

Signing links and access codes

• Tokens. Each signer's link contains a 32-byte random token (256 bits of entropy). We store only the SHA-256 hash of the token; the raw token exists in the email and nowhere else, so a copy of our database cannot be used to sign as someone else.
• Expiry. Links expire 30 days after sending by default (senders can choose up to 180 days). An expired, voided or completed link no longer opens the document.
• Access codes. A sender can require a per-signer access code, shared separately. Codes are stored hashed, limited to 5 attempts before a 15-minute lock, and the certificate records that a code was required.
• Rate limits. Public endpoints (signing, verification) are rate-limited per IP address and per token to slow down guessing and abuse.
• Email security. Mail is sent from no-reply@airesdocs.com with SPF, DKIM and DMARC configured so receiving systems can check it is really from us. Signing buttons are plain links; we never ask for passwords in email.

Storage and data location

The database and file storage are hosted by Supabase in the London region (AWS eu-west-2). Documents, signatures, audit events and account details stay there; they are not replicated to other regions by us. Our API runs on Cloudflare Workers, which executes code in the Cloudflare data centre nearest the user and reads from and writes to the London database over an encrypted connection; no document content is persisted at the edge. Email is relayed by Resend, so recipient addresses and, for completed documents under 10 MB, the attached PDF pass through Resend's infrastructure in the course of delivery.

We do not use analytics scripts, advertising networks or session recording in the app or on this site. The only cookies and local storage used are strictly necessary for login and preferences; see the cookie policy.

Accounts and access

• Sign-in is by email magic link or Google; there is no password to leak. Sessions are short-lived tokens issued by Supabase Auth.
• Row-level security in the database means an account can only read its own documents, recipients, fields and events, even if the app had a bug.
• Signers never get an account. A signer can see only the document their token belongs to, and only their own fields.
• Staff access. Our staff do not read customer documents. Operational access to production is limited to the people who run the service, uses individual accounts with multi-factor authentication, and is used for incident response, not browsing.
• Secrets (service keys, payment and email API keys) live in the Worker's encrypted secret store, never in the browser app or in source code.

Deletion and export

From Settings you can download a ZIP containing every completed PDF and the audit trail of each document as JSON, and you can delete your account. Deletion removes your profile, documents, fields, signature images, logos and templates, and cancels any subscription. Event records are deleted with their documents. Backups roll off within 30 days. Signers who want a copy of a document they signed, or want their details corrected, should contact the sender, who is the controller of that document; if that fails, the privacy policy explains how to reach us.

Sub-processors

These are the companies that process personal data on our behalf to run AiresDocs. We will update this list before adding a new sub-processor; the changelog records the date.

These are used only for features a sender switches on for a contract:

The trust centre keeps the full list in one place.

Transfers to the United States (Stripe, Resend and, for the optional features above, Twilio and Anthropic) rely on the UK International Data Transfer Agreement or Addendum and, where the provider is certified, the UK-US data bridge. The DPA summary has the details.

Engineering practices

• Uploads are checked by magic bytes (not just extension), limited to 25 MB and 200 pages, and parsed by a well-maintained PDF library; encrypted PDFs are rejected rather than guessed at.
• Every API input is schema-validated. Security headers (HSTS, a strict Content Security Policy, X-Content-Type-Options, Referrer-Policy) are set on every response. The app's CSP allows connections only to our own hosts and Supabase.
• Signing and verification endpoints are idempotent and rate-limited. Completion runs once per document even if the last signer submits twice.
• Dependencies are pinned and reviewed; the PDF engine is tested with property-based tests for coordinate mapping, hashing and certificate contents.
• Logs contain no document content and no personal data beyond what is needed to debug a failed request; they are retained for 30 days.

Responsible disclosure

If you believe you have found a security vulnerability in AiresDocs, please email security@airesdocs.com with enough detail for us to reproduce it. We will acknowledge within two working days, keep you informed, and credit you if you wish once a fix is live. Please do not access other people's documents, run denial-of-service tests or use social engineering; test only against accounts you own. We will not take legal action against good-faith research that follows these rules. The same information is published at /.well-known/security.txt.