Security Architecture

1. Security Overview

At Branzly, we take the security of your data seriously. This page outlines the specific security measures, architectural decisions, and practices we have implemented to protect our platform, your accounts, and your workspace data.

2. Authentication & Authorization

We rely on Supabase, an industry-leading backend-as-a-service provider, to manage our authentication layer. Passwords are encrypted by Supabase using robust cryptographic standards, and Branzly never stores or has access to your plaintext passwords.

Session management is handled securely via signed JWTs (JSON Web Tokens) that enforce short-lived access and proper validation on every authenticated request.

3. Database Security & Isolation

All relational data is stored in PostgreSQL databases hosted by Supabase. We enforce strict data isolation using PostgreSQL Row-Level Security (RLS).

• Row-Level Security (RLS): Every database query is evaluated against RLS policies at the database engine level. This ensures that users can only read, write, or modify data (such as saved brands or outreach history) that belongs strictly to their own user ID or their authorized workspace.
• Workspace Isolation: For team and agency accounts, data is logically isolated by `workspace_id`. A user must have an active `workspace_members` record verifying their access before the database will return any workspace-specific data.

4. Encryption in Transit and at Rest

In Transit: All communication between your browser and Branzly's servers, as well as between our servers and our database infrastructure, is encrypted using HTTPS/TLS. We do not support unencrypted HTTP connections.

At Rest: Our underlying database provider (Supabase) ensures that data volumes and backups are encrypted at rest using modern AES-256 encryption standards provided by the underlying cloud infrastructure.

5. Infrastructure & Application Security

Branzly is built using modern web frameworks (React, Vite) that inherently protect against common vulnerabilities like Cross-Site Scripting (XSS).

• No Secrets in Client: Sensitive API keys, database service-role keys, and operational credentials are never exposed to the browser. Only safe, public-facing identifiers are bundled into the client application.
• Externalized Research Architecture: Branzly itself does not run vulnerable web-scraping clusters or manage third-party API credentials (like Apify or TinyFish) in the web environment. Brand intelligence is ingested securely from a scheduled external workflow, reducing the attack surface of the main web application.

6. Security Limitations

As a developing startup project, we want to be transparent about our current security posture. We are not currently certified under compliance frameworks such as SOC 2, ISO 27001, or HIPAA. While we employ strong architectural practices like RLS and encryption, we do not guarantee absolute protection against all possible threats.

7. Responsible Disclosure

We value the work of security researchers and the community in helping keep our platform safe. If you believe you have discovered a security vulnerability in Branzly, we ask that you report it to us responsibly.

Please email reports to: support@branzly.dedyn.io

When reporting, please include:

• A detailed description of the vulnerability.
• Clear steps to reproduce the issue (including affected pages or functions).
• Screenshots or video recordings if applicable.

We kindly ask that you do not execute disruptive testing, such as Denial of Service (DoS) attacks, or access/modify data belonging to other users during your testing.