Security

• At rest. Every uploaded document is encrypted with AES-256-GCM before it is written to storage, using an authenticated envelope format with a versioned header. GCM is authenticated encryption, so a modified ciphertext fails to decrypt rather than decrypting to something wrong.
• In transit. All traffic uses TLS. HTTP is redirected to HTTPS, and HSTS is set.
• Keys. The document encryption key is supplied through the environment, is held only in process memory, and is never written to the database or stored alongside the data it protects. Losing it makes stored documents unrecoverable, which is the intended property.
• Database. Encrypted at rest by our managed database provider, and reachable only over TLS.

• Passwords are hashed with bcrypt at cost factor 12 and are never stored, logged or emailed in plain text. Password strength is checked at signup.
• Sessions use opaque 256-bit random tokens. The server stores only a SHA-256 hash, so a database disclosure does not yield usable sessions.
• Session cookies are HttpOnly, SameSite=Lax and Secure in production, so page JavaScript cannot read them and they are not sent cross-site.
• Sessions can be revoked individually or all at once. Changing a password signs out every other device.
• Password reset and email verification use single-use, time-limited tokens, stored as hashes and invalidated on use.
• Optional single sign-on with Google, GitHub and Microsoft uses OAuth 2.0 with CSRF protection through a state parameter bound to a short-lived HttpOnly cookie and verified on return.

• Workspaces carry owner, admin, member and viewer roles.
• Permission is enforced server-side on every route and server action, not in the interface. Hiding a button is not a control, so we do not treat it as one.
• Every document is scoped to the workspace that owns it, and every query is filtered by that scope.
• Signing links are single-purpose: they grant access to one document, for one recipient, for one signing turn, and nothing else in the account.

The audit trail is append-only and hash-chained. Each entry hashes its own contents together with the hash of the entry before it, so removing, inserting or editing any event invalidates every hash that follows.

• The chain is recomputed and verified whenever a document is viewed and whenever a certificate of completion is generated.
• The original and completed files are hashed with SHA-256, and both hashes appear on the certificate.
• Completed PDFs are flattened, so filled fields become part of the page rather than editable form fields, and each page is stamped with the document identifier.
• There is no application path that edits or deletes an audit entry. Deleting a document anonymises the personal identifiers in its entries and leaves the chain intact, because breaking it would destroy the integrity guarantee for every other document too.

• Uploads are size-limited and the limit is enforced server-side.
• File types are checked by content, not by trusting the file extension or the browser-supplied content type.
• Files are virus-scanned before anything is written to storage. A file that fails is rejected, not quarantined and served.
• PDFs are parsed and re-rendered rather than passed through untouched, and rendering happens in the browser in a sandboxed worker.

• Sign-in, signup, password reset, magic link, upload, send, reminder and signing endpoints are each rate limited independently.
• Signing links expire, are single-use, and are revoked the moment a recipient finishes signing, a document is cancelled, or it expires. Revocation clears the stored token hash, so the link cannot be resurrected.
• Expiry is enforced when a link is used, not only by the scheduled sweep, so an expired document cannot be signed even if the sweep has not run yet.
• Authentication responses do not reveal whether an email address is registered.

DropTheDoc runs on managed cloud infrastructure. We do not operate physical servers, and physical and environmental security is inherited from our providers, each of which is listed with its certifications at subprocessors.

• Application and database credentials are held as environment secrets, are not in source control, and are scoped per environment.
• Production, preview and development environments are separated and do not share databases or storage.
• Administrative access to providers is limited to named individuals with multi-factor authentication.
• A health endpoint reports configuration problems without disclosing any secret value.

• The codebase is TypeScript in strict mode, and every request payload is validated against a schema at the boundary before it reaches business logic.
• Server-only modules are marked as such so that cryptography and password hashing cannot be pulled into a browser bundle.
• Database access goes through a query builder with parameterised queries, so string-concatenated SQL is not a path that exists.
• React escapes rendered output by default, and we do not inject raw HTML from user input.
• Changes go through review, and typechecking, linting and an automated test suite run before deployment.
• Dependencies are pinned and updated, and advisories are monitored.

• The database is backed up by our managed provider with point-in-time recovery.
• Document storage is redundant across availability zones at the provider level.
• Deployments are atomic and can be rolled back to a previous build.
• Scheduled maintenance handles reminders, expiry and the purging of dead sessions and spent tokens.

If we detect or are told of a security incident we triage immediately, contain it, assess what data was involved, remediate, and then notify.

• CERT-In. Within 6 hours of becoming aware, for incidents falling within the categories in the CERT-In directions of 28 April 2022.
• Data Protection Board of India and affected Data Principals. As required by section 8(6) of the DPDP Act, 2023 and the rules under it.
• EEA and UK supervisory authorities. Within 72 hours under GDPR Article 33, and affected individuals without undue delay where the risk is high under Article 34.
• Affected customers. Without undue delay where we act as processor, with the information they need to meet their own obligations.

We also keep logs necessary for investigation, and Indian law requires us to retain certain ICT system logs for 180 days.

If you find a security issue, tell us at security@dropthedoc.xyz before disclosing it publicly. Include what you found, how to reproduce it, and what you think the impact is.

We will acknowledge within 3 business days, keep you updated while we fix it, and credit you if you would like. We do not currently pay bounties.

Rule 8 of the SPDI Rules, 2011 treats a documented, implemented information security programme containing managerial, technical, operational and physical controls commensurate with the data held as reasonable security practice, and names IS/ISO/IEC 27001 as one way to demonstrate it. This page is our documented programme. Our infrastructure providers do hold third-party certifications, and those are listed with each provider at subprocessors.

Security is shared. The parts only you can do:

• Use a strong, unique password, and protect the email account your documents and signing links are delivered to. Anyone with access to that inbox can act on your documents.
• Remove workspace members promptly when they leave, and give people the lowest role that lets them do their job.
• Check recipient email addresses before sending. We deliver to the address you type, including the wrong one.
• Set expiry dates on sensitive documents so that outstanding links do not stay live indefinitely.
• Download and store completed documents and certificates in your own records.
• Decide what belongs in a document. We encrypt whatever you upload, but we cannot decide for you whether it should have been uploaded.