Every organization on TASQ-ONE is protected by PostgreSQL Row-Level Security (RLS) enforced at the database engine level, AES-256 encryption at rest, and TLS 1.3 in transit.
1. Data Isolation (Multi-Tenancy via RLS)
Every SQL query is evaluated against authenticated JWT claims. Even in the unlikely event of an application-layer logic defect, the database engine itself refuses to return or update another organization's records.
Tasks, profiles, attachments, activity logs, comments, and squads all enforce RLS.
Dynamically binds org_id and role into every authenticated session claim.
2. Encryption & Credential Protection
- In Transit: All data is encrypted via TLS 1.3 with HSTS (HTTP Strict Transport Security) enabled.
- At Rest: PostgreSQL database volumes and Cloudflare R2 object storage enforce AES-256 encryption.
- Password Storage: Salted bcrypt/Argon2 hashes via Supabase GoTrue engine (plaintext passwords are never logged or stored).
3. Authentication & DDoS Rate Limiting
- Distributed Token-Bucket Limits: Login, signup, and invite endpoints are protected by Upstash Redis (5 attempts per 5 minutes per IP).
- No Open Self-Registration: Employees and managers cannot self-register into existing organizations — single-use expiring invite tokens are strictly required.
- Strict 3-Way Role Confinement: Server-side middleware redirects unauthorized roles with HTTP 307.
4. Application Defense Practices
- SQL Injection: Parameterized queries exclusively via Supabase client SDK.
- XSS Mitigation: React automatic HTML escaping and strict Content Security Policies (CSP).
- SSRF Defense: Slack webhook URLs are validated against strict
https://hooks.slack.com/services/domain allowlists. - AI Prompt Injection: Ephemeral zero-retention processing with strict system delimiter boundaries on Groq Llama 3.3 70B.
5. Responsible Vulnerability Disclosure
If you believe you have found a security vulnerability in TASQ-ONE, please report it responsibly directly to our engineering desk: