Quorum is built with security as a core principle. This document outlines the security features, practices, and how to report vulnerabilities.

• Email Domain Restriction: Configurable domain-based access control (e.g., only @yourcompany.com emails)
• OAuth Integration: Google OAuth support with optional Google Workspace domain hints
• Session Management: Secure JWT token handling via Supabase Auth
• Domain Validation: Enforced at both authentication and team invitation levels

• Row-Level Security (RLS): All 8 database tables protected with 37+ RLS policies
• Team-Based Access Control: Users can only access data for teams they belong to
• Role-Based Permissions: Admin and member roles with distinct capabilities
• Security Definer Functions: Helper functions with SET search_path to prevent attacks

• Peer Review Enforcement: Users cannot approve or reject their own changes
• Approval Quotas: Configurable number of approvals required per team
• Atomic Operations: Race condition prevention through database-level locking
• Complete Audit Trail: All changes tracked in query_history table

• Minimum Length: 8 characters
• Complexity Requirements: At least one uppercase letter, one lowercase letter, one number, and one special character
• Common Password Blocklist: Top 100 most common passwords rejected at registration

• Content-Security-Policy: Enforced in both production and development (dev CSP allows HMR/localhost)
• Strict-Transport-Security: HSTS enabled in production
• Rate Limiting: Per-route rate limits on all endpoints via @fastify/rate-limit
• Metrics Authentication: Auth tokens accepted only via Authorization header (never query strings)
• CSRF Protection: Double-submit cookie pattern for state-changing requests
• Non-Root Docker: Container runs as node user, not root

• Parameterized Queries: All database operations use parameterized queries (prevents SQL injection)
• Email Validation: Format and domain validation for all email inputs, case-insensitive via citext
• SQL Content Limits: 100KB maximum query size
• XSS Protection: React JSX automatic escaping for all dynamic content

• No Sensitive Logging: Passwords, tokens, and sensitive data never logged to console
• Secure Storage: Authentication tokens managed by Supabase
• Team Isolation: Strict RLS policies prevent cross-team data access
• Email Tracking: All modifications tracked with user email for accountability

1. Client-Side Validation (UX): UI shows/hides based on permissions
2. Database Constraints (Type Safety): CHECK constraints prevent invalid data
3. RLS Policies (Authorization): Server-side access control
4. Security Definer Functions (Privilege Management): Controlled permission elevation

All security-critical operations use database functions with proper security:

• user_teams(user_id) - Returns teams a user belongs to
• user_admin_teams(user_id) - Returns teams where user is admin
• user_can_access_team(user_id, team_id) - Verifies team access
• user_is_team_admin(user_id, team_id) - Verifies admin status
• submit_query_for_approval() - Atomic submission with race condition prevention
• approve_query_with_quota() - Enforces peer review and approval quotas
• reject_query_with_authorization() - Enforces peer review for rejections

All functions use:

• SECURITY DEFINER with proper privilege handling
• SET search_path = public to prevent search path attacks

• Test Accounts: Development mode includes test accounts (admin@test.local, member@test.local) that bypass domain validation
• Auto-Confirm Email: Email confirmation may be disabled in development for faster testing
• Important: Ensure NODE_ENV=production in production deployments

• Domain restrictions require proper configuration via VITE_ALLOWED_EMAIL_DOMAIN
• Without configuration, defaults to @example.com (no access in production)
• Google Workspace domain hints are optional and don't enforce authentication

• RLS policies protect data access but don't prevent logical application bugs
• Policies should be reviewed when adding new features or tables
• Use supabase db lint to check for common RLS misconfigurations

1. Set Email Domain: Configure VITE_ALLOWED_EMAIL_DOMAIN for your organization
2. Supabase Setup: Create a new Supabase project with RLS enabled
3. Environment Variables: Use .env.example as template, never commit .env
4. Google OAuth: Configure OAuth credentials with proper redirect URLs

• Email domain configured correctly
• Auto-confirm email disabled (unless using magic links)
• Google OAuth credentials configured
• Redirect URLs properly set in Supabase
• RLS enabled on all tables (verify with supabase db lint)
• Test accounts disabled (NODE_ENV=production)
• .env file excluded from version control
• Approval quotas configured per team requirements

1. Auth Settings:

   • Enable Email provider
   • Enable Google OAuth (if needed)
   • Configure Site URL to your domain
   • Add redirect URLs for all deployment environments

2. Database:

   • Run all migrations in supabase/migrations/
   • Verify RLS policies with supabase db lint
   • Review supabase/schema.sql for table structure

3. API Keys:

   • Use anon key for client-side (already public)
   • Protect service_role key (never expose to client)

If you discover a security vulnerability, please report it responsibly:

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Use GitHub Security Advisories: Report via the repository's Security tab
3. Or Email: Contact the maintainers directly
4. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

• Acknowledgment: Within 48 hours
• Assessment: Initial assessment within 5 business days
• Resolution: Timeline depends on severity (critical issues prioritized)
• Credit: Security researchers credited (if desired)

• Dependencies: Regularly update packages with pnpm audit
• Supabase: Monitor Supabase changelog for security updates
• React: Keep React and related libraries updated
• Migrations: Review new migrations for security implications

Monitor these sources for security updates:

• Supabase Security Advisories
• React Security Updates
• npm Security Advisories (pnpm audit)
• This repository's security advisories (if public)

• User Data: Email addresses and profile information stored
• Query Content: SQL queries stored in database (may contain sensitive data)
• Audit Trail: All changes tracked with user email
• Data Retention: No automatic deletion (implement as needed)
• Consent & Notices: See docs/privacy-consent.md for deployment requirements

If deploying in regulated environments:

• Implement data retention policies
• Add user data export functionality
• Add user account deletion functionality
• Update privacy policy accordingly (see docs/privacy-consent.md)

• 2026-02-07: Comprehensive issue sweep
  • Password policy strengthened with complexity requirements and common password blocklist (#101)
  • Content-Security-Policy added to development mode (#100)
  • Metrics auth token restricted to Authorization header only (#98)
  • Dockerfile updated to run as non-root node user (#105)
  • fast-xml-parser upgraded to 5.3.4 to fix DoS vulnerability (Dependabot #7)
  • Migration system unified to single canonical path (#90) and squashed to clean baseline (#94)
  • Accessible button elements replace clickable divs (#104)
• 2025-10-27: Comprehensive security review conducted
  • Race condition in auto-approval fixed
  • Email domain validation added
  • Role management verified secure
  • Result: Zero high/medium/low severity vulnerabilities

• Supabase Security Best Practices
• OWASP Top 10
• React Security Best Practices

This security policy is part of the Quorum project and follows the same MIT License.