Security

Last reviewed: September 4, 2026

Every office site we publish, and the admin behind it, runs on one platform we operate. That is the point of the product, and it is also what lets us hold a security posture that an office maintaining its own site rarely can. This page is what we do today — not a roadmap.

How the sites are served

Every site is HTTPS only, with HSTS set to a year including subdomains, so a browser refuses to talk to it in the clear. We send X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a Permissions-Policy that turns off camera, microphone, geolocation and topics — features these sites never use, and so should never be able to ask for.

Clickjacking is blocked with a Content-Security-Policy frame-ancestors allowlist on the public sites, and the admin additionally refuses framing outright. Hosting is Vercel: TLS, a global edge network and its DDoS protection come with it, and there is no origin server of ours for an attacker to find.

Who can get in

Two-factor authentication is required of every admin — corporate, office and loan originator alike. It is not a setting somebody can forget to turn on: an account with no authenticator is sent to set one up at first sign-in and cannot reach any admin screen until it is verified. A leaked password is not enough to see an office, its leads or its content.

Accounts are provisioned, never self-served: signing in with an address nobody added grants nothing. Access is scoped by role — corporate admins see the network, office admins their own office, loan originators their own pages. When an admin views the product as somebody else, the permission check runs on every request rather than trusting a cookie, the impersonated role is the one enforced, and the session is written to an impersonation log.

Data handling

Leads are validated and deduplicated on arrival and stored in Postgres (Supabase), encrypted at rest and in transit. Every office is scoped in the application layer, and Row Level Security is enabled on the public schema so the browser-facing API keys can read nothing on their own — the application connects with its own credential and performs the scoping itself.

Actions that matter — a lead arriving, an impersonation starting — are written to an audit log. Where a lead is delivered onward to a CRM, that connection is configured per office and can be turned off in the admin.

Your visitors

Analytics and marketing scripts stay off until a visitor accepts them: the consent banner ships on every office site, and declining is as easy as accepting. NMLS identifiers, Equal Housing and state disclaimers render automatically where they apply, and the privacy and terms pages cannot be unpublished by an office admin.

The AI assistant

Where Paige is enabled, it identifies itself as AI in its first message. Social Security and card numbers are stripped from a visitor's message before the model receives it and before anything is stored, so a number typed into the chat by mistake is not retained. Paige answers only from the office's own published content, never quotes rates or promises approval, and hands off to a licensed loan officer. Details are on How we use AI.

Subprocessors

Vercel (hosting and edge network), Supabase (database and authentication), Resend (transactional email), Anthropic (the AI assistant, where enabled), and Google Analytics (only after a visitor consents).

What we do not have yet

We are not SOC 2 certified and do not claim to be. We have not commissioned a third-party penetration test. Single sign-on (SAML) and IP allowlisting for the admin are not built. If your security review requires any of these, tell us before you buy rather than after — we would rather lose the deal than have you discover it in an audit.

Reporting a vulnerability

Email support@branchpage.com with what you found and how to reproduce it. We will confirm receipt and tell you what we are doing about it. We will not threaten legal action against anyone who reports a flaw in good faith and gives us a reasonable chance to fix it first.