Security Model
Security rests on organization isolation via RLS, hash-only API keys, encrypted integration and WordPress credentials, a server-only service-role key, and HMAC-signed webhooks.
#Purpose
#Architecture
Tenant isolation is enforced by PostgreSQL RLS on organization-scoped tables. Privileged server operations use the service-role key, which bypasses RLS and is never exposed to the browser.
Secrets are protected: API keys are stored as SHA-256 hashes (shown once), integration secrets and WordPress application passwords are encrypted at rest (pgcrypto / a server-side passphrase), and webhook payloads are HMAC-signed.
#How it works
Isolate
Authorize
Protect secrets
Sign & verify
#Reference
#Secret handling
| Secret | Protection |
|---|---|
| API keys | SHA-256 hash only; plaintext shown once |
| Integration secrets | Encrypted at rest (server-side passphrase) |
| WordPress credentials | Encrypted with pgcrypto (server-side key) |
| Service-role key | Server-only; bypasses RLS |
| Webhook payloads | HMAC-SHA256 signed |
#Implementation notes
- RLS policies reference a current-user-role helper and the organization.
- Self-approval is blocked in sensitive flows.
- Rate limiting and request logging protect the public API.
#Limitations
Known limitations
- Password policy, session timeout, and org-wide 2FA are platform-managed, not org-configurable.
- Isolation is between organizations; within an org, role assignment controls access.
#Security considerations
Security
- Never expose the service-role key or AI/integration secrets to the client.
- Verify all inbound signatures.
- Apply least privilege for roles and API-key scopes.
#Best practices
- Add RLS to every tenant table.
- Rotate keys and secrets periodically.
- Keep privileged accounts few and audited.
#Related documentation
Still need help?
Can’t find what you’re looking for? The DevSphere OS team is happy to help.