How We Protect
Your Documents

Because your password is the key, a normal "forgot password" reset can't work the way it does on other sites — resetting the password without your original one would permanently lock your own documents. Instead, at setup you're shown a 24-word recovery phrase once. It's a second, independent way to unlock the same key, and it's the only way back in if you forget your password. We never see it, and we cannot show it to you again. If it's lost along with your password, your documents are permanently unrecoverable — including by us. Our support team can help with account-level things (billing, your login email, closing the account), but there is no mechanism, manual or otherwise, that lets anyone recover an encrypted vault without either the password or this phrase. That's not a policy choice we could override if we wanted to — it's what "we cannot open your documents" actually means.

When you generate a share link, the decryption key is appended to the URL after a # — a part of the address browsers never transmit to any server. The link itself, stored in our database, is useless without that fragment. Whoever holds the full link holds the key; we only ever hold the token. This means the full link is functionally the document — treat it that way. It can end up in your browser history, in whatever chat app carried it, in a synced clipboard, or in a password manager that auto-saved it. Prefer a one-time link for anything sensitive, and revoke a link once it's served its purpose instead of leaving it live indefinitely.

Your password is never stored, and never transmitted anywhere — see "Zero-Knowledge Encryption" above. What IDVault actually stores is bcrypt(cost factor 12) of a one-way login secret derived from your password, not the password itself. bcrypt's cost factor makes each guess against a stolen database expensive on its own — but the honest framing is that cost factor buys time, not safety: a weak or previously-breached password can still fall in minutes regardless of the hash, which is why we check new passwords against known-breach data before accepting them (below). A byproduct of the login secret being a fixed-length derived value: bcrypt's own 72-byte input limit, which matters if a raw password were ever long, no longer applies here at all.

After you log in, IDVault issues a JSON Web Token (JWT) signed with HMAC-SHA256, valid for 30 minutes. While you're active, the app silently renews it in the background every 20 minutes, so you don't notice the short lifetime day-to-day — but a token that leaks (a browser history entry on a shared machine, a misconfigured log) is only useful for a narrow window instead of a full week. Changing your password, or enabling or disabling two-factor authentication, immediately invalidates every token issued before that moment — including one an attacker might be holding — even though a JWT is normally impossible to revoke early.

Because your password is also your encryption key, a weak or previously-breached one isn't just a login risk — it's a cryptographic weakness. At signup, password change, and password reset, IDVault checks your chosen password against Have I Been Pwned's breach corpus using its k-anonymity range API: only the first 5 characters of a SHA-1 hash of the password ever leave your browser, never the password, and never anything derived from your actual vault key. A password that's appeared in known breaches is rejected before an account is ever created around it.

Your files are encrypted in your browser — with a key derived from your password — before they're ever uploaded. What reaches Amazon S3 is already unreadable ciphertext; S3's own Server-Side Encryption (SSE-S3) then wraps it a second time as an additional layer of defense-in-depth. To be precise about what that second layer is for: AWS holds the SSE-S3 key, not us — it protects against physical media loss or mishandling of raw disks inside AWS, not against AWS itself. The layer that matters against everyone, including AWS and including us, is the first one: your browser's encryption, using a key that only exists on your device.

All communication between your browser and IDVault servers uses Transport Layer Security (TLS). HTTP connections are rejected or redirected to HTTPS, and an HTTP Strict Transport Security header (max-age=63072000; includeSubDomains) tells browsers to remember that and refuse to fall back to plain HTTP for two years, across every subdomain — closing the window a network-level attacker would otherwise get on your very first visit. See "Security Headers" below for what the Content-Security-Policy actually restricts.

Every uploaded file is inspected at the binary level before it's accepted — in your browser, before encryption. IDVault reads the first bytes of the file — known as magic bytes — to confirm the file is actually what it claims to be. A renamed .exe disguised as a PDF is detected and rejected immediately, regardless of what the filename says. Only PDFs, JPEGs, and PNGs are accepted as input — SVG, which can embed executable script, is never an accepted file type in the first place. Photos (JPEGs/PNGs) are re-rendered through an in-browser canvas before they're turned into a PDF page, which strips all EXIF metadata as a side effect — including GPS coordinates and device identifiers that a passport or license photo taken on a phone typically carries. Because the server only ever receives ciphertext, none of this can happen server-side — no server-side malware scanning is possible by design, which is also exactly why these checks have to run here, on your device, before anything is ever encrypted.

PDFs can embed executable JavaScript, automatic actions (OpenAction), and event handlers (AA) that execute code when a file is opened. Before your PDF is encrypted, IDVault parses it — client-side, on your device — and removes all of these active-content entries from the PDF catalog and Names dictionary. The sanitized file is then re-serialized with a clean object stream and only that version is ever encrypted and uploaded.

Share link tokens are generated using Node's crypto.randomBytes(32), producing 256 bits of cryptographically secure randomness. This makes the token computationally impossible to guess or enumerate, so it's a reliable way to look up and authorize which share record a request is for. To be precise about what it protects: the token is not the decryption key — that's the fragment described above, which the server never sees. The token stops a stranger from finding or brute-forcing your way to someone else's share record; the fragment is what actually opens the document once you're there.

Every share link carries a server-enforced expiry timestamp. After the deadline, the link returns HTTP 410 Gone — the document is no longer accessible. One-time links are burned on first access: the usedAt field is set atomically, preventing replay access. Links can also be revoked at any time before expiry.

When a shared document is opened, IDVault can apply diagonal watermarks across every page of the PDF, along with a short reference code unique to that share link. Because the server only ever holds ciphertext, watermarking now happens in the recipient's browser — right after their key decrypts the file, and before it's rendered — so the server never needs, or gets, a readable copy just to stamp it. Downloads can also be blocked for sensitive documents. Neither of these is a cryptographic guarantee, and we'd rather say so than let them sound like one: once a recipient's browser has decrypted a file to display it, a determined recipient can always retain a copy — a screenshot, a browser devtools export, print-to-PDF. What watermarking and download-blocking actually do is raise friction and make casual, low-effort redistribution traceable back to a specific link.

Every sensitive action — document upload, deletion, share creation, password change, 2FA enable/disable, billing update, account export — is recorded in an append-only audit log with a UTC timestamp and full metadata. We call this "append-only" rather than "immutable" deliberately: it's a database table the application only ever writes new rows to and never edits or deletes from, which is meaningfully different from cryptographic immutability (e.g. hash-chained entries where tampering with one row would be detectable). This trail is used for internal security monitoring and, if requested, can be included in your data export for your own records.

Every HTTP response from IDVault includes a hardened set of security headers enforced by Helmet.js and Next.js configuration: X-Frame-Options: DENY to prevent clickjacking; X-Content-Type-Options: nosniff; and a Permissions-Policy that restricts microphone and geolocation access to none. The actual Content-Security-Policy, published here verbatim rather than described in the abstract:
default-src 'self'; script-src 'self' 'unsafe-eval' https://js.stripe.com; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-src blob: https://js.stripe.com https://hooks.stripe.com; …
It blocks injected <script> tags — the main XSS delivery mechanism — and restricts where scripts, frames, and connections can come from at all. It is not a zero-unsafe-directives policy: 'unsafe-eval' is required because the PDF rendering library we use (pdf.js) calls eval() internally, and 'unsafe-inline' is needed for styles. Removing those without breaking document viewing needs either a different PDF rendering approach or a sandboxed rendering context — real work we haven't done yet, not a header we forgot to set. We'd rather publish the actual gap than a claim that papers over it.

A global rate limiter caps all API traffic at 200 requests per minute per IP address, with stricter per-route limits on authentication and upload endpoints. But an IP-based limit alone doesn't stop a slow, distributed credential-stuffing attempt spread across many source addresses — so login attempts are tracked per account as well: after repeated failed attempts, that specific account is temporarily locked, regardless of how many different IPs the attempts came from. Both limits reset automatically after their window passes.

IDVault's API uses a strict CORS allowlist — only requests originating from the official myidvault.io domain get to read a response. No wildcard (*) origins are permitted. To be precise about what actually stops cross-site request forgery, since CORS on its own isn't it — CORS restricts who can read a response, not who can send a request: IDVault authenticates every request with a token your own JavaScript explicitly attaches to an Authorization header, rather than a cookie the browser attaches automatically. A malicious page has no way to make your browser attach that header on its behalf, so it can't forge an authenticated request in the first place — CORS then additionally stops it from reading any response even to an unauthenticated one.

You can export a copy of everything IDVault stores about you at any time from the Settings page — a structured JSON file with your profile information, account metadata, share link history, and a complete activity log. Being precise about what this does not yet include: your actual document files. Today's export lists each document's metadata, not its decrypted contents — a genuine gap for a product whose promise is that your documents survive anything. A client-side bulk export that decrypts your documents locally and packages the real files is planned; until it ships, use the per-document download inside the app to get an individual file.

Account registration requires email verification via a cryptographically random 256-bit token sent to your address, valid for 24 hours. Email address changes follow the same pattern — a confirmation link is sent to both the old and new address, and the change is only applied after the new address is confirmed. This prevents account takeover via email-change attacks.

Documents are stored as ciphertext in Amazon S3, with versioning enabled — if a file is ever overwritten or deleted, whether by a bug, an accidental action, or anything else, the previous version is recoverable rather than gone. Old versions are permanently purged after 30 days via an automatic lifecycle rule, matching the deletion window described below rather than accumulating indefinitely. Any backup or recovered version is ciphertext only — nothing readable exists in a backup that doesn't already exist in the primary copy. We do not currently run cross-region replication; everything lives in a single AWS region (US East, Ohio).

If a breach affecting your account is confirmed, we commit to notifying affected users within 72 hours of confirmation — the same window required under GDPR, adopted here as our standard regardless of where you're located. After you delete your account, your data (including audit log entries referencing your account) is retained for up to 30 days before permanent deletion, to allow recovery from an accidental deletion request.