Trust and security

• The listing brokerage owns its listings. Only that brokerage can change them, through its own API keys or its signed-in people.
• Every request is checked against the organization it comes from. Asking for another brokerage's listing answers “not found”, so nobody can probe for listings that are not theirs.
• A members only listing (the seller's choice) never leaves through the public feed. When another member reads one, the copy is marked for that member, so a leaked copy can be traced back.
• Seller names are never sent to home search sites or data feeds; only the listing brokerage sees them.
• Every change to a listing is written to an append only history, and each line carries a fingerprint of the line before it, so an edited history shows.

• All traffic is HTTPS. Browsers are told to use HTTPS only (HSTS), and every page carries a content security policy that limits what it may load.
• The database is only reachable by our own server code. Every table has row level security on with no public access, so the public database key can read nothing.
• API keys are shown once and stored only as a one way hash. Each key has scopes and a per minute limit, can be revoked at once, and can be rotated with 24 hours of overlap so integrations switch without downtime.
• Sign in is by a single use emailed link that works for 15 minutes; links and session cookies are stored only as hashes. Sessions end on sign out or when someone is removed from their organization.
• Two-step sign-in with an authenticator app is available to everyone and required for admins before they can invite people, manage keys or export. The app secrets are encrypted with a key kept outside the database; recovery codes are stored as hashes and work once.
• Photos sit in private storage. Each upload is re-encoded, which strips location and all other metadata, and served only through signed links that expire.
• Outgoing webhooks are signed (HMAC SHA-256) and are never sent to private or internal network addresses. Incoming connector events must carry a valid signature.
• Every input is checked against an explicit list of allowed fields, types and lengths; unknown fields are refused. Database queries are parameterized.
• Secrets live in the hosting environment, never in the code or the logs. Error messages carry no listing data.

The database is backed up daily by Supabase and each backup is kept for 7 days. Point in time recovery is not turned on yet, so in the worst case up to a day of changes could be lost. We run a restore drill that rebuilds the listings from a fresh copy in a separate database and checks every row count and every history fingerprint. Photo files are stored separately from the database and are not in these backups.

No listing data is sold or shared with advertisers. There are no third party advertising or analytics trackers on the site.

• Every change is reviewed against a written security checklist before it ships, and fixes are logged.
• Dependencies are watched by automated alerts and audited for known vulnerabilities.
• A written incident response plan sets roles, severity levels and how fast affected customers are told.
• The website, API v1, the RESO Web API, webhook delivery, the sign-in email provider and the scheduled jobs (MLS sync, webhook sender, Coming Soon go-live) are checked every 5 minutes. Current status, 90 day uptime and incident updates are public on the status page.
• Access to production systems is limited to the people who run them; a written checklist sets how that access is reviewed.
• People and organizations can be deleted: an operator admin removes a person and their access, and an organization's admin can ask for all of its data to be deleted.

Not done yet. Listed so you know where we are going, not as claims.

• SOC 2 Type I, then SOC 2 Type II. No audit has started; we hold no certification today.
• An independent penetration test before production use by brokerages.
• Point in time recovery for the database, and backups of photo files.
• Encrypting webhook signing secrets at rest, and a stricter content security policy without inline scripts.

Email security@listonce.io with what you found, how to reproduce it and what it could expose. Please give us time to fix it before telling anyone else, and do not access data that is not yours or degrade the service. We aim to reply within two business days and will tell you when it is fixed. Our security.txt has the same details.