Security architecture
This page describes the technical security measures in Revizo. The information is intended for IT managers, security teams, and compliance staff who need insight into the platform’s security profile.
Security layers
Revizo is built with defence in depth — several independent security layers that each provide protection:
┌──────────────────────────────────────────────────────┐
│ 1. Code and development │
│ Automated tests, type checking, code analysis │
├──────────────────────────────────────────────────────┤
│ 2. Transport │
│ TLS 1.2+, HSTS, security headers │
├──────────────────────────────────────────────────────┤
│ 3. Authentication │
│ Clerk (SSO, MFA, sessions) │
├──────────────────────────────────────────────────────┤
│ 4. Authorisation │
│ RBAC (administrator, member, viewer) │
├──────────────────────────────────────────────────────┤
│ 5. API security │
│ Input validation (Zod), rate limiting, CORS │
├──────────────────────────────────────────────────────┤
│ 6. Data isolation │
│ Tenant scoping, Row Level Security │
├──────────────────────────────────────────────────────┤
│ 7. Encryption │
│ AES-256 (storage), AES-256-GCM (application) │
├──────────────────────────────────────────────────────┤
│ 8. Monitoring │
│ Sentry, structured logging, audit log │
└──────────────────────────────────────────────────────┘
HTTP security headers
All responses from Revizo include the following security headers:
| Header | Value | Purpose |
|---|---|---|
Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | Forces HTTPS, prevents downgrade |
X-Frame-Options | DENY | Prevents clickjacking (embedding in an iframe) |
X-Content-Type-Options | nosniff | Prevents MIME-type sniffing |
Referrer-Policy | strict-origin-when-cross-origin | Limits leakage of URL information |
Permissions-Policy | Restrictive | Disables camera, microphone, geolocation |
Content-Security-Policy | Detailed policy | Restricts sources for scripts, styles, and connections |
Content Security Policy (CSP)
The CSP header restricts which sources the browser is allowed to load resources from. Only known and verified domains are allowlisted, including Clerk (authentication), Supabase (data), and Sentry (error monitoring).
Input validation
All data received from clients is validated server-side with structured schemas (Zod) before it is processed:
- Type validation — Strings, numbers, UUIDs, email addresses, etc.
- Boundary values — Max length, allowed values, valid formats
- Sanitisation — Filenames are sanitised; HTML content is removed where it is not expected
- File upload — MIME type is verified, file size is limited (max 20 MB), filenames are sanitised
Validation fails early with clear error messages. Internal error details (stack traces, database errors) are never exposed to the client.
Rate limiting
Revizo enforces rate limiting on all API endpoints to prevent abuse:
| Type | Limit | Purpose |
|---|---|---|
| General (read) | 100 requests/hour per organisation | Normal use |
| Write operations | Stricter limits | Prevent abuse |
| Sensitive endpoints | 3 requests/hour | Authentication, invitations |
When exceeded, HTTP 429 (Too Many Requests) is returned with a Retry-After header indicating when the next request is allowed.
Cache and session handling
API caching
All API responses include appropriate Cache-Control headers:
- Read operations:
private, no-cache— data may be cached locally by the browser, but is revalidated on every request - Write operations:
private, no-store— data is never cached
Sessions
- Session tokens have a short lifetime and are rotated automatically by Clerk
- Inactive sessions expire automatically
- Session information is not stored in Revizo’s database — all session administration happens at Clerk
Webhook security
Revizo receives webhooks from third-party services. All webhooks are verified with cryptographic signatures:
| Source | Verification method |
|---|---|
| Clerk | Svix signature verification (ed25519) with timestamp check |
| Tripletex | HMAC signature verification with tenant-specific secret |
| Visma NXT | Signature verification with shared secret |
Webhooks that fail signature verification are rejected immediately.
Development security
Code checks (CI/CD)
All code changes go through automatic checks before they reach production:
| Check | Tool | Purpose |
|---|---|---|
| Static code analysis | ESLint | Finds potential bugs and security issues |
| SAST (codebase) | GitHub CodeQL | Semantic security analysis on JavaScript/TypeScript |
| Type safety | TypeScript (strict mode) | Eliminates an entire class of errors at compile time |
| Unit tests | Vitest | Verifies correct behaviour |
| End-to-end tests | Playwright | Tests complete user flows in the browser |
| Build validation | Next.js build | Ensures the application builds without errors |
| Dependency updates | Dependabot (npm + GitHub Actions) | Alerts about new versions and known vulnerabilities |
Branch protection
The main branches (main and develop) are protected with server-side rules:
- Force-push is blocked
- Deletion is blocked
- All CI checks must pass before merge
Dependency security
- Dependabot proposes weekly updates for npm and GitHub Actions
- Regular
npm auditon upgrades and in security reviews - Dependencies are assessed for security, maintenance status, and bundle size before installation
Error monitoring
Sentry is used for real-time error monitoring with the following security measures:
- PII filtering: Request data is automatically removed before submission to Sentry
- Session replay: Enabled only on errors, with input masking
- Correlation ID: Each request is assigned a unique ID that makes it possible to trace an event through the entire system without exposing user data
Infrastructure security
| Component | Provider | Security measures |
|---|---|---|
| Hosting | Vercel | SOC 2 Type II, automatic scaling, DDoS protection |
| Database | Supabase (AWS) | SOC 2, encrypted storage, network isolation, automatic backup |
| DNS/CDN | Cloudflare | ISO 27001, DDoS mitigation, WAF |
| Authentication | Clerk | SOC 2 Type II, GDPR-compliant |
| Payment | Stripe | PCI DSS Level 1, SOC 2 |
All infrastructure components operate in the EU region.
Last updated: April 2026