Security
Operational security practices inside Blanca's Builder.
This page describes the security controls we operate today inside Blanca's Builder. It reflects current practice, not certification claims.
Last updated: 2026-06-28
This page is maintained by Blanca's IT Professional SL to answer common security, privacy and trust questions about Blanca's Builder.
This page is app-owned editable content. It is not an independent audit or certification.
Security is a shared responsibility between Blanca's IT Professional SL, the platforms we run on (Cloudflare, Supabase) and you as the account owner.
Authentication
Blanca's Builder uses Supabase Auth with email + password and OAuth providers. Passwords are hashed by Supabase using bcrypt. We never see or store plaintext passwords.
Staff accounts are fully separated from customer accounts, gated behind a dedicated role table (`user_roles`) checked by a security-definer function, and require a separate login route.
Authorization
Every database table is protected by Row-Level Security (RLS). Access is granted through narrow policies that scope rows to `auth.uid()` or to an explicit role check. Service-role keys are used only by verified server functions.
Application security
We follow secure defaults: parameterized queries via the Supabase client, strict input validation with Zod, CSRF protection on state-changing requests, and a Content Security Policy on production.
AI provider API keys submitted in BYOK mode are encrypted at rest using a per-row secret. Decryption happens only inside server functions that the user explicitly invokes.
Logging and audit
Staff actions in the admin console are written to an audit log. Application errors are captured in a recovery event log we use to investigate user-reported issues without exposing personal data.
Backups
The Supabase project takes daily backups. Account deletions are propagated to backups within 90 days through standard rotation.
Canonical: https://blancasbuilder.com/trust/security · Blanca's Builder