Security at BranchPage

Tenant isolation

BranchPage is a shared-infrastructure, logically isolated multi-tenant application. Every customer-owned row carries a tenant id, and there is no code path that reads customer data without constraining on it.

Database-level default

Every table in the application schema has row level security enabled and denies by default. Nothing is readable through the database's public interface without an explicit policy.

Application access

The application reads through a dedicated role and scopes every query by tenant. Access control is enforced server-side on each request, not by hiding navigation — a user who types a URL for a record in another tenant, or in another office where their role does not reach, gets a 404.

API keys

Each key is bound to one tenant and grants only that tenant's data. Keys are stored as a SHA-256 hash and shown exactly once — we cannot recover the plaintext, including for you. Every API call is written to the workspace's audit log, successes and rejections alike. Each key is issued read-write or read-only, and rotating a key mints its replacement with a 24-hour grace window on the old one instead of an instant cutover, so swapping keys is not an outage.

API rate limits

Each key may make 120 requests per minute. Above that the API answers 429 with a Retry-After header — refused, never silently dropped, so a well-behaved integration loses nothing. Repeated breaches are alerted to our staff, because a key suddenly running at wire speed is how a leaked key looks.

Our own access

Our staff can open a customer workspace to investigate a problem or verify a change. Every one of those visits is recorded on our side — who went in, whose account they used, and when — and requires a second factor on an account that exists only for that purpose and belongs to no workspace. We say so here rather than leave it to be discovered, because support access that nobody admits to is the version that deserves to be a scandal.

Acting as another user

Owners and operations managers can view the product as a colleague in their own office, for support and training. Every such session is recorded and reported separately from real sign-ins, so an impersonated session can never be mistaken for the person's own login.

Authentication

Passwords

Managed by Supabase Auth. We never see or store a plaintext password.

Two-factor authentication

TOTP, compatible with any standard authenticator app. An account owner can require it across their whole company; anyone without a second factor is then stopped at their next page load. A session that has not cleared the second factor cannot reach any authenticated page, by URL or otherwise.

Sign-in throttling

Failed sign-ins are counted per address and per IP, and either counter trips the throttle. A throttled attempt reads exactly like a wrong password on purpose — the form never confirms whether an address exists.

Response headers

Content Security Policy

No external scripts, no framing, no plugins, and outbound connections restricted to this app and our auth provider. Written against what the product actually loads rather than a broad allow list.

Clickjacking

X-Frame-Options: DENY on every page. Every screen is authenticated and every screen has buttons that act, which is exactly what clickjacking targets.

MIME sniffing

X-Content-Type-Options: nosniff. A customer file the browser decided to run as script would be stored XSS with our domain on it.

Referrer leakage

Strict origin policy on cross-origin navigation — a contact record's URL naming who a workspace is talking to is never handed to a third-party link.

Data handling

In transit

TLS on every connection, including our outbound webhooks.

At rest

Encrypted by our infrastructure providers, listed below. We do not operate our own disks.

Region

Primary data is held in the United States. Region selection for customers with a residency requirement is possible but is not self-service — ask before signing.

Credentials you give us

API tokens for the systems you connect — Jira, and any prospecting account — are encrypted with AES-256-GCM before they are written, using a key held outside the database. They are shown masked afterwards and are never returned by the API. Where a provider supports it, we verify a credential against them before storing it, so a token that does not work is never kept.

Files you upload

Logos, photographs and video are stored in object storage under a path namespaced to your tenant. Deleting an asset removes the stored object, not just the row that points at it.

Documents your clients upload

Client documents live in a private bucket with no public address. Every upload is scanned for malware against the bytes that actually arrived — a file renamed to look like a PDF is caught by its content, not its name — and a file that fails the scan is deleted, not quarantined. Reading one signs a URL that expires in 60 seconds, issued only after checking the tenant, the contact's owner, and the scan verdict. If the scanner is unreachable, nothing is released: the system fails closed.

Outbound webhooks

Signed with HMAC-SHA256 over the timestamp and the body, in the X-BranchPage-Signature header, so your endpoint can verify a delivery came from us and reject a replayed one.

Send volume

Where a workspace has an agreed monthly email ceiling, reaching it holds further sends rather than erroring or bouncing — nothing looks broken, and nothing is delivered past the agreed volume.

Deletion

On termination, customer data is deleted within 30 days of the request. The deletion covers every table in the schema by name — a table nobody classified fails our own pre-deploy build, not just the deletion — and produces a certificate of what was removed and what was kept and why (billing and audit records, retained for tax and accounting law). Backups age out on their own schedule and are not selectively edited.

Subprocessors

The third parties that may process customer data on our behalf.

What we do not have yet

Stated here rather than left for you to discover, because you would.

• No SOC 2 report. We have not completed an audit. If a report is a condition of purchase, say so early — it changes the timeline, not the answer.
• No third-party penetration test on record. We will support a test you commission against a dedicated environment.
• No bug bounty programme. Reports are still welcome and answered — see below.
• No single sign-on today. Sign-in is Supabase Auth with TOTP two-factor, optionally required company-wide. SAML 2.0 against an identity provider — Okta, Entra ID, Google Workspace and others — is not built, but our auth provider supports it and we can build it by request for a customer who needs it. Ask early: it is a real scope item, not a settings toggle.
• Texting and calling do not send yet. Messages are recorded against the contact and held. This is listed under security rather than features because a system that appears to have sent something it did not is a records problem before it is a product one.