Security best practices

All frontend code can be inspected and modified by users. Never store secrets or make security decisions in the browser.

// ❌ Wrong - secrets visible to anyone
const API_KEY = "sk-1234567890abcdef";

// ✅ Right - store secrets in Cloud → Secrets
// and access them only from edge functions.

Frontend validation improves UX but provides zero security guarantees. Always validate and sanitize all inputs server-side in edge functions.

Edge functions run in an isolated server-side environment. Any logic that affects security, data integrity, or external services should live here.

• Verify authentication and authorization on every request.
• Validate and sanitize all incoming data.
• Handle business logic (payments, state transitions, approvals).
• Call third-party APIs; keep credentials out of the browser.
• Process sensitive data and log security events.

Row-level security controls who can read or modify each row. It is your last line of defense, enforcing access even if frontend or backend logic fails.

Common patterns
Personal data (users access only their own), team-based access (team members share team data), public with ownership (anyone reads, only owners write), organization-scoped access.

• Validate sessions and tokens in edge functions; never rely on localStorage checks.
• Check roles and permissions server-side.
• Use built-in session management for secure token handling.
• Redirect on expired sessions, but always re-validate on the server.
• Use frontend auth state only for UI rendering, never for access control.

• No secrets in frontend code.
• All validation and critical logic runs in edge functions.
• RLS policies configured and tested on every sensitive table.
• Authentication enforced server-side.
• The pre-publish security scan comes back clean, or High findings are understood.
• External API calls happen server-side only.