HangarKeepHangarKeep

Security

How HangarKeep protects your data

Tenant Isolation

Every organization gets its own SQLite database file. Your records are not rows in a shared table filtered by an account column — they live in a separate file, opened through a separate connection. A missing WHERE account_id = ? cannot leak another organization's data, because the query never reaches their database.

Account context is derived from your authenticated session on the server. Account identifiers supplied by a client — in a URL, form field, or header — are never trusted as authoritative.

Authentication

  • Passwords are hashed with bcrypt and checked against a common-password list at signup.
  • Two-factor authentication (TOTP) is available on every account; secrets are encrypted at rest.
  • Passkeys (WebAuthn) are supported for passwordless sign-in.
  • Recovery codes are stored hashed and are single-use.
  • Sessions are server-side; the cookie carries an opaque identifier, not your data.
  • Administrative actions in the operator portal require a step-up re-authentication.

Transport and Browser Hardening

All traffic is served over HTTPS with automatic certificate management. Responses carry:

  • HSTS with a two-year max-age, includeSubDomains, and preload
  • A Content Security Policy with script-src 'self' — no inline scripts, no third-party script origins, no CDNs
  • X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, and a restrictive Referrer-Policy
  • Permissions-Policy denying camera, microphone, and geolocation
  • Cache-Control: no-store on every HTML page response

All fonts, stylesheets, and scripts are self-hosted and embedded in the application binary. HangarKeep loads nothing from a CDN, and it contains no analytics, advertising, or tracking code.

Every form submission is protected against cross-site request forgery, and authentication endpoints are rate limited.

File Storage

Receipts, attachments, and exports are stored in a private cloud bucket with no public access. Files are served through short-lived, signed URLs generated only for authenticated requests that pass an authorization check for that specific record.

Audit Logging

Every create, update, delete, void, lock, and status change is written to an audit log with the acting user, the affected record, and the before and after values. Administrative actions taken by an operator are logged separately and survive user deletion.

Server access logs have session cookies and authorization headers stripped before they are written to disk, and are retained for 30 days.

Backups and Recovery

  • Databases are replicated continuously to Amazon S3 with a 30-day retention window.
  • Stored files are mirrored to S3 on a short interval, with versioning enabled so a deleted file stays recoverable for 30 days.
  • The host runs daily snapshots.
  • A nightly job performs a real restore from backup, runs an integrity check, and verifies row counts — an unverified backup is not a backup.

Backups are encrypted at rest. Administrators can also download a full account backup at any time from Settings, and we recommend doing so for records you rely on.

Development Practices

Secrets are never committed to source control — they are injected at runtime from a secrets manager. Continuous integration runs the test suite, go vet, static analysis, a vulnerability scan of dependencies, and a secret scan on every change.

What We Don't Claim

HangarKeep is operated by a small team. We are not SOC 2 certified, we do not hold ISO 27001, and we do not offer an uptime SLA. We would rather tell you that plainly than imply an assurance we haven't earned. What we do offer is described above and is honestly stated.

Reporting a Vulnerability

If you believe you've found a security issue, email security@hangarkeep.com with enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before disclosing it publicly.

We don't run a paid bug bounty, but we will acknowledge your report, keep you updated, and credit you if you'd like. We won't pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and only interact with accounts they own or have permission to test.