Network and security architecture

Use the controls to enlarge the diagram. Pan horizontally and vertically when zoomed.

Trust boundaries

Boundary	Primary controls
Internet to static application	HTTPS, Cloudflare edge delivery, baseline DDoS mitigation, and configured edge rules
Browser to managed backend	TLS, publishable client identity, signed user session, request validation, grants, and row-level policies
Managed gateway to data	Database roles, object permissions, row-level policies, constraints, and restricted trusted operations
Serverless workflow to external provider	Server-side credentials, provider authentication, input minimisation, timeouts, callback verification, and auditable status
Application to monitoring	Configured diagnostic context, source-map handling, masking, sampling, retention, and access controls

Segmentation model

The static delivery plane is separated from the stateful backend. Ordinary browsers do not receive database passwords or privileged service credentials. Application data access is mediated by the managed gateway and database authorization. Trusted serverless operations are an elevated boundary. Selected operations revalidate the caller, tenant, role, target, and input; complete operation coverage is not available.

Allowed communication paths

Source	Destination	Protocol and identity	Permitted purpose	Default failure behavior
User browser	Cloudflare edge	HTTPS with certificate validation	Load the approved static release	Refuse insecure transport and expose no backend credential
Browser application	Supabase gateway	TLS, publishable client context, and signed user session	Authentication, policy-controlled data, object, realtime, and approved function requests	Deny protected access without a valid session or policy result
Trusted function	PostgreSQL or object storage	Provider-internal service context and scoped server credential	Privileged transaction, scheduled work, or object processing	Abort on failed actor, tenant, role, input, or ownership validation
Trusted function	Approved provider	TLS and provider-specific credential	Messaging, payment, quote, credit, call, or reporting workflow	Record an explicit provider failure or indeterminate state; do not assume completion
Approved provider	Trusted callback	HTTPS plus signature, shared secret, or equivalent authenticity proof	Deliver a correlated event or final provider state	Reject unverifiable or replayed requests before business mutation
Browser and backend	Monitoring	TLS with project-scoped ingestion context	Errors, traces, release, and selected diagnostic telemetry	Application correctness does not depend on monitoring availability

Network threat treatment

Threat	Architectural treatment
Direct database exposure	Application traffic enters through managed APIs and policies; no application-owned public database listener is part of the topology
Browser tampering	Browser state and route visibility are non-authoritative; protected operations re-evaluate identity and authorization at the backend
Cross-tenant access	Signed identity, tenant membership, hierarchy, ownership, and row policy reduce every ordinary request to the permitted record set
Credential disclosure	Public clients receive only publishable configuration; provider and privileged credentials remain in trusted configuration
Callback forgery	Provider callbacks are treated as untrusted until authenticity, correlation, freshness, and idempotency checks pass
Data exfiltration through integrations	Destinations are approved by purpose; payloads are minimized and server-mediated where credentials or sensitive business state are involved
Denial of service and abuse	Provider baselines address network availability; application rate limits and business-flow controls address account-level abuse

Limitations

This document intentionally omits domains, IP addresses, account identifiers, provider endpoints, internal object names, and secrets. It does not prove current DNS, WAF, network restriction, TLS-policy, or egress-allowlist configuration; those require account-level evidence.