Security

Last updated: September 19, 2026

This page is the technical companion to the Privacy Policy - that page covers what we collect and your legal rights; this one covers how the system is actually built to protect it. Every claim below describes something real in the running code, not an aspiration.

Most tools never touch a server at all

The strongest security property a file can have is never being transmitted in the first place. Every tool marked "runs entirely in your browser" - compressing, merging, splitting, converting, rotating - reads, processes, and rebuilds your file using your own browser's engine. There is no upload step, no server-side code path that receives it, and nothing to intercept in transit, because nothing is ever sent.

Secure Share and Secure Note: encrypted so we can't read them, not just so we say we won't

These two tools do use a server, because their whole point is handing something to someone else. The file (or note) is encrypted in your browser, with a key generated in your browser, before anything is uploaded. That key is never transmitted to Filevolo - it travels to whoever you share the link with entirely inside the URL itself, after the # character, a part of a URL browsers never send to a server. The practical result: Filevolo's database holds encrypted bytes it cannot decrypt, not because of an access-control rule that could be misconfigured, but because the key was never in its possession at any point. Full retention detail on the Privacy Policy.

Sign & Send: encrypted at rest, with a narrower guarantee stated plainly

Sign & Send needs more than one person to open the same document, which is a genuinely different requirement from Secure Share's - Filevolo's own systems have to be able to read the document to render it to each signer and assemble the final signed copy. What we do provide: everything stored for a signing request - the document, signer details, and completed signatures - is encrypted at rest (AES-256) on the server, a real layer of protection against anyone who might get raw access to storage itself (a stolen backup, a compromised disk), on top of normal access controls. This is deliberately not described as "zero-knowledge" the way Secure Share is, because it isn't - stating the narrower, accurate guarantee is the point of this page.

Account security

• Passwords are hashed with scrypt (Node's built-in implementation of a memory-hard, deliberately slow key-derivation function), never stored in plain text and never logged.
• Login sessions are HMAC-signed tokens, not opaque database lookups an attacker could forge by guessing an ID - a tampered token fails verification outright.
• Changing or resetting your password immediately invalidates every other session - every device you were logged into elsewhere is signed out the moment it happens, and you get an email notification so you'd know if it wasn't actually you.
• Login attempts are rate-limited two ways: per IP address (stops one attacker hammering many accounts) and per account email (stops a distributed attempt against one specific account from many addresses), the second capped tightly enough to block realistic brute-forcing while never locking out a real user making a few honest typos.
• Password-reset requests are rate-limited the same way, specifically to stop the request itself being used to flood someone's inbox with reset emails from rotating IP addresses.
• Login and signup responses are deliberately generic ("wrong email or password," not "that email isn't registered") so the response itself can't be used to check which emails have an account.

Payments

Filevolo never sees your card number. Checkout happens entirely on Stripe's own PCI-compliant hosted page - Filevolo's server only ever receives a payment confirmation and the email address tied to it, nothing else.

What every page sends your browser

• A strict, enforcing Content-Security-Policy - not a report-only placeholder - naming every specific origin allowed to load a script or receive a connection, blocking arbitrary third-party script injection outright.
• Framing is denied entirely (X-Frame-Options: DENY, plus frame-ancestors 'none' in the CSP) - Filevolo can never be embedded in another site's iframe, closing off clickjacking attacks like a disguised overlay tricking a click into starting a purchase.
• HTTP Strict Transport Security - your browser is told to only ever use HTTPS for filevolo.com going forward, on top of Cloudflare's own edge TLS termination in front of the site.
• X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that denies microphone and location access entirely (Filevolo has no use for either) and restricts camera access to filevolo.com itself, never an embedded third party - PDF Scanner is the one tool that genuinely needs it, to capture a document photo directly in your browser.

Infrastructure

Filevolo runs behind Cloudflare, which terminates TLS at the edge and absorbs denial-of-service traffic before it reaches the application server. The application and its database run on infrastructure with access restricted to what is needed to operate the Service - full third-party list (Stripe, Google AdSense, Cloudflare, jsDelivr) is on the Privacy Policy.

Reporting a security issue

If you find a genuine security vulnerability, please email [email protected] with enough detail to reproduce it. We'll respond, and we ask that you give us a reasonable chance to fix a real issue before disclosing it publicly.