What actually protects your book.

Sign-in and sessions

Passwords are hashed with Argon2 and never stored or logged in the clear. Signing in creates a server-side session row; the browser only ever holds an opaque session identifier.

That identifier is set as HttpOnly; Secure; SameSite=Lax with a seven day rolling window that extends on use. HttpOnly means no JavaScript on the page can read it, so a script injected into the page cannot walk off with a session. Secure means it never travels over plain HTTP. SameSite=Lax blocks the ordinary cross-site request forgery path.

Every request that reads or writes verifies the session against the database and confirms the user is still active before it touches a row. Deactivating a user in the admin page ends their access on their next request, not at their next login.

Encryption

All traffic is HTTPS. Certificates are issued and renewed automatically, and the site sits behind a CDN that terminates TLS at the edge and forwards over an encrypted link. The database connection from the application uses TLS as well.

Property photos and deal documents are stored in Amazon S3 and served through CloudFront. Uploads use an instance role rather than a long-lived access key, so there is no AWS key sitting in a config file to leak.

Links you send to the outside world

Three things in this product are deliberately reachable without a login, because they have to be: a public offering memorandum, a deal room, and an owner report. Each one is addressed by a long opaque token rather than a guessable identifier, each one is scoped to exactly one deal, and each open is logged against that deal so you can see who has been looking.

A deal room adds a confidentiality agreement before anything downloads, records the name, company and email of whoever accepted it, and hands out download links that expire. These pages are excluded from search engines in robots.txt and carry a noindex header; treat the link itself as the credential and send it to the person you mean.

The public read API

One key-protected endpoint feeds current listings to the public marketing website. It is locked down in several independent ways rather than one: a server-to-server API key that never reaches a browser, an origin allowlist for CORS, a hand-written field allowlist on every response so there is no SELECT * and no contact or financial fields, a row allowlist that only returns listings explicitly marked public, hard caps on page size, a rate limit at the edge and a second one in the application, and an audit row for every call including the rejected ones.

The audit log

Changes are recorded by database triggers rather than by application code, so a write that skips the app still lands in the log. The log is append-only and each row carries a SHA-256 hash chained to the row before it. Quietly editing history breaks the chain, which is the point. Administrators can read it in the app.

Spam and abuse on the public forms

The request-access form and the listing inquiry form carry a hidden honeypot field, a per-address rate limit, a repeat-submission window, and length caps on every field. Nothing on a public form writes anything a signed-in user would see as trusted.

What we do not do

• No third-party analytics, advertising pixels or session-replay tools run on this site or in the app.
• Your brokerage data is not used to train a model. The assistant sends only what a question needs to the model provider you choose, and nothing is contributed to training.
• We have not completed a SOC 2 audit or a penetration test by an outside firm. When that changes this page will say so, with a date.

Reporting something

If you find a security problem, tell us before you tell anyone else. Use the request form on the home page and say it is a security report; it reaches a human the same day.