Security

Security at BuildingHQ

Last updated: 2026-06-06. This page summarises the security posture we run BuildingHQ with. It's deliberately plain — security decisions matter to non-engineers too, and obscuring them behind jargon doesn't help anyone.

The short version

• Encryption. TLS 1.2+ in transit; AES-256 at rest on storage and backups.
• Tenant isolation. Every database query that touches building data filters by tenant in the data-access layer — not just in the UI.
• Least privilege. Service accounts and people get the narrowest scope that lets them do their job.

Authentication and authorisation

Sign-in uses Auth0 (which supports social SSO, magic-link, and enterprise SAML/OIDC) or a managed username + password flow with Argon2id hashing. Sessions are kept in HTTP-only, Secure, SameSite=Lax cookies — never in localStorage.

Every API request answers five questions before any side effect happens: which user, which building, which resource, which action, is it allowed. The three roles (Admin, Contributor, Read-only) plus per-capability grants are checked server-side on every request; the client-side UI is purely cosmetic.

We rate-limit sensitive endpoints (login, password reset, invite acceptance, ingestion). Vendor "one-time link" flows carry no ambient authority beyond the scoped action.

Multi-tenancy and data isolation

Every table that holds tenant data carries a building_id column, and every query that touches it filters on that column. The filter is enforced in a base repository layer so individual handlers can't accidentally leak across tenants. We don't rely on URL paths or memory-only checks to do this work.

Encryption

Data in transit is protected with TLS 1.2 or higher (TLS 1.3 where browsers support it). HSTS is enabled on all production hostnames. Data at rest is encrypted with AES-256 using AWS- managed KMS keys. Backups inherit the same encryption.

Secrets

All secrets are read from a secret manager at process startup; none are baked into container images or written to source. Pre-commit and CI scanners catch accidental check-ins. Production secrets are rotated when there is reason to.

Logging, monitoring, and incident response

Application logs are structured JSON with a correlation ID that threads across services. Logs are retained for at least 30 days. We monitor request rates, error rates, latency, queue depth, and auth failures, and we page on symptoms (e.g. error-rate threshold crossings) rather than causes.

If a security incident affects customer data, we will notify affected customers in writing once we have a meaningful picture of what happened. We aim to tell you what we know, what we don't yet know, and what we're doing about it.

Backups

Production databases are backed up continuously with point-in-time recovery within the retention window.

File uploads and inbound email

Uploads are size- and content-type-limited at the edge, validated by inspecting the first bytes (not just the Content-Type header), stored under server-generated keys, and served with restrictive content disposition. Inbound email goes through SPF / DKIM / DMARC checks and an explicit allow-list before it reaches your inbox.

Desktop app

The desktop app ships as code-signed binaries and verifies an Ed25519 signature on every auto-update before applying it.

Responsible disclosure

If you find a security issue, please report it to support@buildinghq.app. We'll acknowledge within two business days, work with you on reproduction and triage, and credit you in any public write-up if you'd like. Don't publicly disclose an unpatched issue before we've had a reasonable chance to fix it. We don't pursue researchers who follow this policy.

What we ask of you

Strong, unique passwords (or SSO). Don't share credentials. Keep your phone and computer up to date. If something looks wrong — an unexpected sign-in alert, an unfamiliar device — sign out everywhere from your account settings and email support@buildinghq.app right away.