The short version
- Zome and the app are served over HTTPS, and our host sends an HSTS header.
- Passwords are stored as salted scrypt hashes, and sign-in sessions are stored only as hashes.
- Owners can turn on two-step sign-in with an emailed code or an authenticator app, and Zome staff must use it.
- If you find a security problem, tell us through the contact page; we don't run a bug bounty.
- This page describes what we do today and is not an audit report or a certification.
A plain-language summary, for convenience. The full text below is what applies.
This page describes the security measures Zome runs today, so you can judge them for yourself. It covers zome.io and the Zome app at app.zome.io. It is not an audit report or a certification, and no system is completely secure. If you want to know about something this page doesn't mention, please ask.
Connections
- zome.io and the app are served over HTTPS. Our host sends an HTTP Strict Transport Security (HSTS) header, which tells browsers to use HTTPS only.
- The app sends a Content Security Policy in report-only mode. It is not enforced yet, so it does not block anything.
- The session cookie cannot be read by scripts in the page and is sent only over HTTPS.
Sign-in and passwords
- Passwords. Passwords are never stored as typed. They are hashed with scrypt and a random salt, and compared in a way that does not leak how close a guess was.
- Sessions. Each session has its own random token. We store only a hash of it, so a copy of the database does not contain a token that can be used.
- Password resets. A reset link is random, stored only as a hash, works once and expires after an hour.
- Sign-in links. An account that uses two-step sign-in has no sign-in link. It logs in with its password and a code.
Two-step sign-in
- Two ways. An owner can turn on a second step, either a six-digit code we email or an authenticator app with ten single-use recovery codes.
- Authenticator app. Every tenth wrong code in a row pauses sign-in for that account for 15 minutes, and the thirtieth locks it until it is unlocked. The key is encrypted before it is stored, and recovery codes are stored only as keyed hashes.
- Emailed codes. Each emailed code can be tried five times and then ends. An account can make at most 50 code tries a day.
- Zome staff. Staff accounts must pass the second step. A staff session ends 12 hours after it starts and does not renew, and a staff browser is never remembered.
Your information
- Stored secrets. The access Google gives Zome to a connected Business Profile, and authenticator keys, are encrypted before they are stored. A copy of the database alone cannot use them.
- Photos. Uploaded pictures are checked for type and size, then re-encoded, which removes location and camera details such as the GPS position a phone adds. A picture that cannot be re-encoded is refused rather than stored as it came.
- Support access. An owner can let the Zome team open their dashboard for 24 hours, and can end it at any time. Each view lasts at most 60 minutes, and each one is listed for the owner in Settings. It is off unless the owner turns it on.
- Providers. The companies that process information for us are listed on the subprocessors page.
Protecting the service
- Our scanner. The free report's website check visits public websites only. It refuses private and internal network addresses, checks each redirect, and reads a limited amount of each page.
- Webhooks. Messages sent to Zome by Stripe, Twilio and ElevenLabs are accepted only when their signature checks out.
- Abuse limits. Public forms, the free report and sign-in steps have limits on how often they can be used from one connection or account. The free report also has daily caps on the paid services it calls.
Report a vulnerability
If you think you have found a security problem in zome.io, the Zome app or a website we host, please tell us. Send a message through our contact page and mention security in your message. Our security.txt file is at /.well-known/security.txt.
Your message goes to our team's inbox and chat, so say what the problem is and where you found it, and leave out full proof-of-concept details and anyone's personal information. We'll ask for more when we need it. The address or screen involved, what you did, what you expected and what happened, and the browser or device you used all help.
Please:
- test only with your own account and your own data
- stop as soon as you have shown the problem, and don't open, change or delete anyone else's information
- don't run denial-of-service tests, send spam, trick our staff or customers, or attack anything physical
- give us a reasonable chance to fix the problem before you tell anyone else about it
What we do. We'll look into what you send us and use it only to investigate and fix the problem. We read research that follows the points above as an honest attempt to help. We don't run a bug bounty or pay for reports. If you'd like to be credited once a fix is live, tell us.
Out of scope. Problems in services we use but don't run, such as Google, Stripe or Twilio, should go to those companies. Reports of automated-scanner output with no demonstrated effect are unlikely to lead to a change.
What we do not claim
- No certification such as SOC 2 or ISO 27001, and no independent audit or penetration test.
- No security email address, and no public status page, yet.
- No promise that nothing will go wrong.
Contact
For anything else about this page, please use our contact page.
What changed
- First published.
Questions about this page?
Send us a message. A real person reads every message and replies by email.



