Trust

Security you can actually check.

Your business runs on this data: contracts, client details, payments. Here is exactly how we protect it, in plain language, and an honest note on what we have not yet claimed.

Infrastructure Application Accounts Payments Your data What we don't claim Report an issue

Infrastructure

Servora runs entirely on Cloudflare's global network. There is no legacy server for an attacker to find.

Encryption in transitEvery connection is HTTPS/TLS. Plain HTTP is redirected and HSTS is enforced.
Encryption at restYour database (Cloudflare D1) and file storage (Cloudflare R2) are encrypted at rest by the platform.
Isolated runtimeApp code runs in Cloudflare's sandboxed Workers runtime, not a shared server you could pivot from.
DDoS and edge protectionRequests pass through Cloudflare's network-level protection before they ever reach the app.

Application security

  • Tenant isolation. Every database query is scoped to your workspace. One business can never read or write another's data.
  • Role-based access. Five roles (owner, team member, client, subcontractor, platform) each see only what their role allows, enforced centrally at the gate on every request, not page by page.
  • Hardened response headers. A strict Content-Security-Policy, X-Frame-Options DENY, X-Content-Type-Options nosniff, a locked-down Permissions-Policy, and HSTS are set on every response.
  • Signed payment webhooks. Every Stripe webhook is cryptographically signature-verified and de-duplicated before it can change an account.
  • Secrets stay out of the code. API keys and signing secrets live in Cloudflare's encrypted secret store, never in the source and never shipped to the browser.
  • Input validation and size limits on request bodies, with a honeypot and throttling on public forms.

Account security

  • Passwords are never stored. We keep only a bcrypt hash (work factor 12) combined with a server-side secret, so a database copy cannot reveal a password.
  • Secure sessions. Session cookies are HttpOnly, Secure, and SameSite, with a limited lifetime (shorter for contractors than clients) and each session records its IP and device.
  • Brute-force protection. Repeated failed logins are rate-limited and then locked out, and login attempts are recorded.
  • Password reset uses single-use, time-limited tokens.
  • Read-only support view. If you ever ask us to look at your account, that access is read-only by design and every mutation is refused.

Payments

  • Card data never touches our servers. Payments run on Stripe's hosted checkout, so full card numbers and CVV go directly to Stripe, not to Servora.
  • PCI handled by Stripe. Stripe is a PCI Level 1 service provider; our integration is built so card data is never stored or transmitted by us.
  • Your money goes to you. When your clients pay, funds settle to your own connected Stripe account. Servora never holds your customers' money.

Your data

  • Automatic database backups via Cloudflare D1's point-in-time recovery.
  • Immutable audit log. Sensitive actions (signatures, payments, permission changes, subscription events) are written to an append-only trail.
  • You own it, and you can leave with it. Export your data while active; after cancellation your workspace stays available to export, and we do not automatically delete it. Ask us to delete it whenever you want.
  • No AI training on your data. Servora's core platform does not send your workspace data to any AI model, and does not use it to train one.

What we don't claim (yet)

We would rather be trusted than sound impressive, so we will not use security theater. As of now, Servora is not SOC 2, HIPAA, or PCI certified, and we do not use phrases like "bank-level" or "military-grade" security. Those are claims that require independent audits we have not completed.

What is written above is what we actually do today. As the company grows we intend to pursue independent assurance (starting with SOC 2 readiness) and will update this page when that status changes. Additional account protections such as multi-factor authentication are on our near-term roadmap.

Report a security issue

If you believe you have found a vulnerability, we want to hear from you. Please reach us through the contact page and mark your message as a security report. Give us enough detail to reproduce the issue, and please give us a reasonable chance to fix it before disclosing it publicly. We do not pursue good-faith researchers who follow responsible disclosure.

Last reviewed July 27, 2026. This overview describes current practices and is provided for transparency; it is not a warranty or a contract.