Security & Trust

• Your browser encrypts locally.
• Our server stores only ciphertext.
• The private key stays inside your link.
• After the first successful read, the record is deleted.
• The code is publicly verifiable.
• We document our limitations openly.

• AES-GCM-256 via the browser-native WebCrypto API; no third-party crypto library on the wire. secrets.js:211-217
• X25519 key agreement combined with HKDF-SHA256 derivation, all done in the browser using WebCrypto. secrets.js:256-269, secrets.js:425-453
• 12-byte random nonce per ciphertext (96-bit GCM IV), 22-character URL-safe random tokens (128 bits of entropy). SecretService.php:24, SecretService.php:36-38
• Optional password protection: PBKDF2-SHA256 with 1,200,000 iterations per OWASP 2024 guidance, salt + iteration count travel in the URL fragment so older links keep working. SecretService.php:52, secrets.js:271-293

• Hard-delete on the first successful read, atomic DELETE...RETURNING. No soft-delete table, no application-level backup of ciphertext rows. Database-level WAL retention applies until rotation. SecretService.php:55-79
• Per-IP rate limit of 10 create and 20 retrieve calls per minute, plus a global ceiling of 200 writes and 500 reads per minute to protect availability. Create.php:82 , Retrieve.php:42
• TTL is server-enforced between 1 minute and 7 days. The web UI offers 1-hour, 24-hour and 7-day presets; API clients may pick any value in that range. SecretsValidators.php:43-52
• 1 MB maximum ciphertext payload, enforced in the validator and the service layer. SecretService.php:28, SecretService.php:300-306

• Live status page exposes the deployed commit SHA and environment so you can pin the running build. /status
• RFC 9116 security.txt with contact, policy and acknowledgements. /.well-known/security.txt
• Backend service and browser crypto are published under the AGPL-3.0 license on a public mirror. LICENSE

• Like every web-based crypto tool, the protection only holds while the JavaScript we deliver is the one we intend to ship. A compromise of the server (or a successful TLS man-in-the-middle with a trusted certificate) could swap in a malicious bundle that exfiltrates plaintext before encryption. There is no Subresource Integrity hash for the main bundle today.
• No third-party cryptographic audit has been published yet. Until that exists, "trust" rests on the open source mirror plus your own review.

The plaintext stays in your browser, but the server still observes a few things by virtue of running the service at all.

• Optional labels travel base64-encoded in the URL fragment so the sender can preview them. Treat them as URL metadata, not as encrypted content; do not put secret information into the label field.
• Ciphertext length is stored as-is, so the byte size of a secret is observable to anyone with database access.
• Application logs record per-IP request hashes (sha256-truncated, not raw IPs) and route patterns. Token segments are redacted before logging via the SecretLogger redaction filter.
• A network observer between you and our server can see request size and timing patterns. Padding the ciphertext to a fixed length is on the roadmap; today the size is whatever you typed plus a 16-byte GCM tag.

• Pick the shortest TTL you can live with. Default to one hour for ad-hoc secrets and only stretch to seven days when the recipient is offline.
• Add a password to the secret. The recipient needs both the link and the password, so a leaked link alone is useless. The password derives an extra key via PBKDF2-SHA256 with 1.2M iterations.
• Leave the label empty if the secret context is itself sensitive. Labels travel in the URL fragment for the sender preview, but they are not encrypted content.
• Send the link over one channel and the password over a different one. A single-channel compromise then leaks neither half.
• Before pasting a secret, verify the URL bar reads exactly vault.erseni.com or your self-hosted domain. A look-alike domain hosting a malicious bundle is the strongest practical attack against this design.

If you are a journalist, activist, or otherwise expect a well-resourced adversary, browser-delivered crypto is not the strongest tool you can pick. Treat Vault as a convenience layer with a documented threat model, not as a substitute for the practices below.

• Run your own instance against your own domain. You then trust your own JavaScript build instead of ours.
• For long-lived secrets prefer an offline tool: age, GPG, or a hardware-token-backed flow. They are auditable without a running server.
• Read the secrets.js source before relying on a vault.erseni.com deployment. The bundle is short enough to review on one screen.
• For seed phrases, key material, or anything that funds an account or revokes access, prefer end-to-end-encrypted email with PGP or an in-person handoff.

Source mirror: gitlab.erseni.net/open-source/secrets-component

Deployed build: status page

security.txt: /.well-known/security.txt

You do not need to take our word for which JavaScript you are running. Here is the concrete chain you can walk.

1. Open the build manifest. It lists the application commit, component commit, mirror commit and the SHA-256 of every asset delivered to the browser. /build-manifest.json
2. Click the mirror commit. It opens the exact source on the public mirror that was published with this deploy.
3. Open DevTools, copy the secrets script URL, fetch and hash it. The result must match the manifest browserJs.sha256. curl -s '<script src from DevTools>' | sha256sum
4. Read the file on the mirror. The browser crypto fits on one screen and uses native WebCrypto only.

Why no Subresource Integrity (SRI) attribute on the script tag? SRI would have the browser refuse a tampered bundle automatically, but it requires recomputing and re-deploying integrity hashes on every change and is hostile to A/B variants. The manifest hash does not provide the same automatic browser enforcement as SRI. It gives reviewers and self-hosters a concrete SHA-256 value to compare against the served browser bundle.