Security

Security without server-side invoice storage

There is no server database of your invoices to breach — so our security work concentrates on the thing that actually matters here: the integrity of the code delivered to your browser, and of the data on your device.

The architecture

  • Your data is stored on your device by default (IndexedDB in your browser). No operator application server receives it — there is no server-side database of invoices to breach.
  • The risk that remains is deployment integrity: compromised code delivered to your browser could read what's on your device. That is exactly where the controls below aim.

Code integrity

  • Strict Content Security Policy: the site tells your browser to load code only from this domain. The single external exception is Google's sign-in and Drive endpoints, used only for the opt-in Drive backup and loaded only after you press Connect.
  • Optional cloud backup currently uses Google Drive. Google's sign-in library and Drive API are contacted only after you select Connect. Access is limited to the backup files the app creates or files you explicitly open with it (Google's drive.file scope).
  • No analytics or trackers of ours, anywhere. Our host's own auto-injected analytics is disabled at the account level; the Content Security Policy also blocks it from loading as a second layer of defense, so it can't run even if that setting were ever flipped back on. Fonts and assets are self-hosted.
  • Security headers are set on every response and audited against the OWASP HTTP Headers Cheat Sheet (last audited 20 July 2026): Content-Security-Policy (above), Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and Cross-Origin-Opener-Policy. COOP runs in a slightly relaxed mode (same-origin-allow-popups) so the Google sign-in popup used by opt-in Drive backup can complete — the one intentional deviation from the strictest OWASP setting.
  • Pinned dependencies and a production dependency audit before each release — last run 20 July 2026, zero known vulnerabilities.

Data integrity on your device

  • Sent proofs: when you mark an invoice sent, the app freezes a PDF of its current state with a SHA-256 checksum — a clear, integrity-verified record of what you marked sent and when. If you edited the invoice after actually sending it through a separate channel, this won't necessarily match the exact bytes that left your device.
  • Validated restores: every backup import is deeply validated before it changes anything, and a safety export is offered first. Malformed or contradictory records are rejected, not repaired silently.
  • Conflict protection: stale saves are detected and never silently overwrite newer work — including across browser tabs.

What we can't protect

Your device, your browser profile, and the backup files you download are under your control, not ours. Anyone with access to your device has access to what's on it — the same as any local file. Use your device's own security (login, disk encryption) and treat backup files like the business records they are.

Reporting a vulnerability

Found something? Please tell us: [email protected]. A machine-readable contact is published at /.well-known/security.txt. We read reports, act on what's real, and will credit you if you'd like. Please don't test against other people's data — with this architecture you can test against your own.

Page last reviewed 20 July 2026.