Security

BuildPad DaaS uses a defence-in-depth approach with security enforced at three layers.

Security Layers

Layer	Mechanism
Database	PostgreSQL Row-Level Security (RLS) policies
API	Permission rule enforcement per route
Application	JWT validation, session management, input validation

Authentication Methods

Method	RLS Protection	Best For
Cookie/Session	✅ Database-level	Web UI
JWT Bearer Token	✅ Database-level	Secure API clients
Static Token	⚠️ App-layer only	Automation, CI/CD

Static tokens use the Supabase service role internally, which bypasses database RLS. Application-layer permissions still apply. Use JWT tokens where database-level isolation is critical.

Row-Level Security

RLS policies are applied to all core system tables. Enable RLS on your custom tables using the generic RLS helper function:


-- Enable RLS on a custom table
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
 
-- Apply the generic read policy (requires auth)
CREATE POLICY "authenticated_read" ON your_table
  FOR SELECT USING (auth.uid() IS NOT NULL);

For the full generic RLS setup that automatically applies policies to new tables, run the corresponding migration in supabase/migrations/.

Audit Logging

Every create, update, and delete operation is logged to daas_activity via 36 database triggers (12 tables × INSERT/UPDATE/DELETE). Query the audit log via:


GET /api/revisions        — paginated activity log (admin only)
GET /api/revisions/:id    — single activity entry

Production Checklist

✅ Set CORS_ORIGINS to explicit allowed domains (never *)
✅ Use HTTPS in production (via TLS termination at load balancer or nginx)
✅ Set NEXT_TELEMETRY_DISABLED=1
✅ Restrict the EC2 security group: only ports 80/443 public, 22 restricted
✅ Rotate the SUPABASE_SERVICE_ROLE_KEY if compromised
✅ Use IAM roles for EC2 instead of static AWS credentials
⬜ Configure rate limiting (not built-in — use nginx limit_req or an API gateway)