Security

RoverDrop holds project records: the files your crews deliver, the custody history behind them, and the deliverables you share with clients. This page describes how the service protects that data today. Questions and security reports go to support@roverdrop.com.

Signing in

• Passwords are stored only as salted bcrypt hashes. The policy follows current NIST guidance: a minimum length and a common-password blocklist, with no forced rotation.
• Passkeys are supported as a phishing-resistant alternative. Authentication happens on your device; RoverDrop stores only a public key, so there is no shared secret to steal, and any biometric never leaves the device.
• Google sign-in is available. It only signs in users your firm has already added, matched by verified email.
• Sessions use 256-bit random tokens that are stored only as SHA-256 hashes, so a database read never yields a usable session. Cookies are HttpOnly. Sessions expire after 14 days of inactivity and after 30 days regardless.
• Sign-in attempts are throttled per network address and per account, and the password check takes the same time whether or not the account exists, so failed attempts reveal nothing about which emails have accounts.
• Password reset links are single-use, stored hashed, and expire in one hour. Completing a reset signs the account out of every session and removes its enrolled passkeys, so a reset always produces a clean slate.

The client portal

Client portal accounts have no passwords at all. Clients sign in with an emailed single-use link that expires in 15 minutes, or with a passkey. Portal sessions are a separate system from staff sessions, a client can sign out of every device at once, and every portal action is recorded by name in the space's activity log. Removing a member cuts off their access immediately, including uploads already in progress.

Keeping firms separate

Every record in RoverDrop belongs to exactly one firm, and every query is scoped to the firm of the signed-in user, with uniqueness and ownership also enforced by database constraints. Users in one firm cannot see that another firm's data exists. Within a firm, roles are enforced on the server: field accounts default to seeing and downloading only their own submissions, and an administrator chooses how much wider to open that.

Files: integrity first

• Uploads go directly from the browser to object storage over TLS, using short-lived signed URLs that also bind the exact byte size, so a stolen upload URL cannot be used to store arbitrary data.
• Every file gets a SHA-256 fingerprint, computed on the device during upload and independently re-verified by the server against the stored bytes. The record notes whether a fingerprint was server-verified, so a claimed checksum is never presented as a proven one.
• Every submitted file is copied to a write-once archive. In production the archive bucket carries a storage-level lock: archived objects cannot be overwritten or deleted, by users, administrators, or us, for the configured retention period. Corrections are new files; the original is always still there.
• Downloads use signed URLs that expire in minutes, and each download is recorded in the packet's audit trail.
• Files from outside senders (through file-request links) are stored with a conservative content type that browsers treat as a download, so an anonymous uploader cannot plant active content.
• Photo evidence is preserved. Capture time, camera identity, and any GPS coordinates embedded by the camera are extracted and kept with the file, because they are part of the record.

Share links and passcodes

• Every share, file-request, and space link token is 256 bits of randomness, and only its SHA-256 hash is stored. Nothing in the database is a working link.
• Links expire on a schedule your firm picks and can be revoked at any time. A revoked or expired link stops serving immediately.
• Optional passcodes are stored as salted bcrypt hashes. Unlock attempts are limited both per network address and per link, so a passcode cannot be brute-forced from a pool of addresses.
• Share links re-check on every request that the underlying packet is still in a shareable state, and every open and download through a link is logged to the audit trail.

The audit trail

The audit trail is the product, so it is built to be trustworthy. Every event names who did it and when, and is written in the same database transaction as the change it records, so there is no moment where a custody change exists without its record. No code path in the application updates or deletes an audit event; history is never rewritten. Automated fetchers are kept out of the record: link-preview bots from chat apps are excluded so a machine preview never reads as "the recipient opened it," and speculative browser prefetches of download URLs are refused outright.

Retention and legal holds

Retention rules tidy working copies of filed packets on your firm's schedule; the write-once archive copy is never touched by them. A legal hold on a packet, a job, or a client space suspends retention and trash purges entirely until the hold is released, and the hold itself is stamped into the audit trail of every record it covers.

Integrations

• Outbound webhooks are signed with HMAC-SHA256 using a per-firm secret so your systems can verify each delivery. Deliveries only ever go to public internet hosts: the destination is resolved and validated first, the connection is pinned to the validated address, and redirects are not followed, which closes the standard tricks for reaching internal services.
• Billing webhooks from our payment provider are signature-verified and deduplicated before they touch any account state.
• Push notifications use the browsers' standard Web Push with keys we hold; no third-party push service sees your data, and every notification is only ever a second copy of an email.

Application and network

• All traffic is TLS. Strict-Transport-Security is set for two years with preload.
• The app cannot be embedded in frames, MIME sniffing is disabled, referrer information is restricted, and camera, microphone, and location access are limited to the app itself.
• Error monitoring scrubs link tokens and sign-in URLs from reports before they leave the server, and collects errors only: no session replay, no performance tracing of user activity.
• Third-party analytics runs only on this marketing site. The signed-in application loads no third-party scripts at all.

Operations

• RoverDrop is hosted in the United States.
• The production database is backed up daily, with copies kept separately from the primary server.
• Production access is limited to a small number of operations staff and is not used to browse customer content.
• The public demo runs in throwaway firms that are purged after 24 hours. Demo data can never email real addresses, call outbound webhooks, or write to the locked archive.
• If we learn of a breach affecting your data, we will notify affected firms without undue delay.

Compliance

RoverDrop does not currently hold a SOC 2 or ISO 27001 certification. This page documents the controls in place today. If your firm or your client needs a security questionnaire completed, or has questions this page does not answer, write to support@roverdrop.com and we will answer directly.

Reporting a vulnerability

If you believe you have found a security issue, email support@roverdrop.com with enough detail to reproduce it. Good-faith reports are welcome and we will respond quickly. Please do not access data that is not yours or test against firms other than your own; the public demo is the right place for testing.