Security

For data handling, read the Privacy policy and data processing addendum. Use Contact to request a security review.

Accounts and sessions

• Passwords are hashed with bcrypt at cost factor 12. The plaintext is never stored and never written to a log.
• Every password must be at least 8 characters and contain at least one symbol, punctuation mark or space — enforced wherever a password is set, not only at signup. A workspace can raise the minimum length and additionally require mixed character types.
• Sign-in attempts are rate-limited with an atomic, database-backed counter, so a credential-stuffing run gets slowed down rather than a free retry loop.
• Sessions are signed JWT cookies with a 7-day lifetime, rotated daily while in use. Signing out clears the cookie.
• Post-login redirects only ever go to same-origin paths, which closes the open-redirect trick phishing kits rely on.

Role isolation, enforced where it counts

A client portal user can never receive a bill rate, a cost rate, or a margin. That rule lives in the database query layer: the queries that serve the portal are structurally unable to select those columns, so there is no UI bug that could leak them. A dedicated test suite (23 assertions) tries to reach the money columns as every non-admin role and fails the build if any path opens up.

Staff roles are scoped too: members see the projects they are assigned to, and admin-only areas are enforced in the request proxy before a page ever renders.

The application layer

• Every response carries a Content-Security-Policy with a fresh per-request nonce and strict-dynamic, so an injected inline script does not execute. Frames are refused outright (frame-ancestors none), which is the clickjacking defence.
• All traffic is HTTPS; the host redirects plain HTTP and serves HSTS.
• API keys are shown once at creation, stored only as SHA-256 hashes, verified with constant-time comparison, and scoped read or write. The API authenticates by bearer token only, never by session cookie, so a signed-in browser cannot be tricked into driving it (the classic CSRF shape).
• Security-sensitive routes validate their inputs before database work. A malformed id is handled as a not-found response rather than a stack trace.
• Material commercial changes are recorded in the audit log. The control inventory and its test owner are maintained with the release runbook.

Infrastructure

• Application hosting and attachment storage: Vercel. The active Postgres database runs on our Hostinger server in Boston, United States. Application database connections require TLS with client certificates. Primary database disk encryption has not been verified.
• Secrets live in the deployment environment, never in the repository. Database credentials are rotated when anyone with access changes.
• Public marketing and sign-in pages are reachable without a session. Workspace pages require an authorized account and are marked noindex. Sign-in pages are also marked noindex.

Backups you can believe

Daily database and attachment recovery archives are encrypted before upload to Google Drive, then downloaded and checked by checksum. The decryption key is stored separately. Independent restore drills verify the archived database and attachments in an isolated environment. These daily backups can leave a recovery gap of about 24 hours plus the time taken to complete the backup. There is no automatic failover or continuous point-in-time recovery. The separate application snapshot job and Vercel attachment storage remain in use.

Account email

Verification and recovery use signed, expiring links. Password changes revoke earlier sessions. Pending email content is encrypted and removed from the delivery queue after acceptance or a terminal outcome. Signed provider events distinguish mail-server delivery from provider acceptance. Open and click tracking are disabled on the sending domain. Optional email preferences do not disable essential account notices.

What we do not have yet

Being straight about the gaps is part of the point of this page:

• No SOC 2 report. Billable8 is a small product. The engineering controls above are real; the audit paperwork does not exist yet.
• No two-factor authentication yet. Sign-in is email and password, Google, or Microsoft. New customers can create a workspace from the signup page with these options. Existing accounts follow the provider-linking and verification checks shown during sign-in. Client portal access requires an invitation; social signup does not grant access to a client’s workspace. TOTP is on the roadmap, and this line gets deleted when it ships.
• One active database server. The database runs in Boston, United States. Recovery archives are stored separately; there is no multi-region database failover.
• Primary disk encryption is unverified. Encrypted recovery archives and TLS connections do not establish encryption of the live database disk.

If any of those is a hard requirement for you, we would rather you know before you sign up than after.

Reporting a vulnerability

Found something? Email zach@opsautomators.com with enough detail to reproduce it. You will get a human reply within 3 business days, usually faster.

• Good-faith research is welcome and we will not take legal action over it.
• Please do not access data that is not yours, degrade the service, or test against other customers’ workspaces. If you need a test account to poke at, ask and we will set one up.
• Give us reasonable time to fix an issue before publishing it. We are happy to credit you when it is resolved.