Security
WorkWiz is built with security at every layer — from encryption and rate limiting to immutable audit logs and session management. Here is an overview of how we protect your data and your account.
Passwords are hashed with bcryptjs and never stored in plain text. A minimum of 10 characters is enforced at account creation and on every password change.
JWT sessions expire after 1 hour and are automatically rotated on active requests. Changing your password immediately invalidates all sessions on all devices.
Login attempts are limited to 5 per 15-minute window per email address. AI requests are throttled per plan using token buckets with a rolling window.
OAuth tokens and sensitive credentials are encrypted at rest using AES-256-GCM. The database stores only encrypted blobs — keys never touch the database.
All database queries are scoped to the authenticated user and workspace, preventing IDOR attacks. Admin routes are gated by the isAdmin flag and verified server-side on every request.
Task history and admin actions are captured in immutable audit logs. Every field change is recorded with the actor and timestamp — these logs cannot be deleted or modified.
Authentication
Password requirements
All WorkWiz accounts are protected by a password. Passwords must meet the following requirements:
- Minimum 10 characters in length (no maximum limit).
- Stored as a bcryptjs hash with a cost factor designed to resist brute-force attacks. Plain-text passwords are never written to disk or database.
- Required at account creation, on every password change, and when accessing sensitive settings such as account deletion.
Email verification
New accounts must verify their email address before they can log in or access any workspace features. A verification link is sent automatically at sign-up. If the link expires, a new one can be requested from the login page. Unverified accounts cannot accept workspace invitations.
JWT sessions
After a successful login, WorkWiz issues a signed JSON Web Token (JWT) with a 1-hour lifetime. On each authenticated request the token's expiry is checked server-side. If the token is still valid and the session is active, it is automatically rotated (a fresh token is issued) so that users making regular use of the app stay signed in without interruption. Idle sessions that exceed the 1-hour window require the user to sign in again.
Session invalidation on password change
When you change your password, a server-side session version counter is incremented. All existing tokens reference the previous version and are immediately rejected, signing you out of every active session across all devices and browsers. You will need to log in again using your new password.
Rate limiting
WorkWiz enforces rate limits to protect against brute-force attacks and API abuse. The limits are applied server-side and cannot be bypassed from the client.
| Action | Limit | Window | Scope |
|---|---|---|---|
| Login attempts | 5 attempts | 15 minutes | Per email address |
| AI requests | Per-plan weekly token quota | 5-hour rolling window | Per workspace / plan |
When the login rate limit is reached, all further attempts from that email address are blocked until the 15-minute window resets. A lockout message is displayed to the user. If you believe your account is being targeted, change your password immediately after regaining access.
AI token limits are calculated as a weekly budget allocated by plan tier, with a shorter 5-hour sub-window to prevent burst abuse. Requests that exceed the limit receive an error message with an indication of when the quota resets.
Data encryption
OAuth tokens obtained from third-party integrations (such as calendar or communication services) are encrypted before being written to the database using AES-256-GCM authenticated encryption.
Encryption key
The encryption key is provided via the ENCRYPTION_KEY environment variable as a base64-encoded 32-byte (256-bit) string. This key is loaded at runtime and is never stored in the database or version control. Rotating the key requires re-encrypting all stored tokens — contact your platform administrator for key rotation procedures.
Storage format
Each encrypted value is stored as a single colon-delimited hex string in the format:
iv:authTag:ciphertext
Where iv is the 12-byte initialisation vector (unique per encryption operation), authTag is the 16-byte GCM authentication tag used to verify integrity, and ciphertext is the encrypted payload. The database stores only this opaque blob — it is meaningless without the key.
Access control
WorkWiz enforces access control at the database query layer, not only at the UI level, ensuring that data cannot be accessed by crafting direct API requests.
- Workspace scoping: Every data query includes the authenticated user's workspace ID as a filter condition. A user in Workspace A cannot retrieve data that belongs to Workspace B, even if they know the record's ID.
- IDOR prevention: Resource IDs are never trusted without re-verifying ownership. All reads and writes confirm that the requested record belongs to the authenticated user's workspace before returning or modifying data.
- Admin gate: All routes under
/adminverify theisAdminflag server-side on every request. The flag is not inferred from the session token alone — it is checked against the database at request time. - Banned user redirect: Users whose accounts have been banned are redirected to
/bannedon their next authenticated request. Active sessions are checked against the ban status in real time.
Audit trail
WorkWiz maintains two separate immutable audit logs that together provide a complete history of significant actions within the platform.
Task history
Every change to a task — including field-level updates to title, status, priority, assignee, due date, and description — is recorded in the task history log. Each entry captures:
- The field that changed
- The previous value and the new value
- The actor (user who made the change)
- The exact timestamp (UTC)
Task history entries are visible to workspace members who have read access to the task. They cannot be edited or deleted by any user, including workspace Owners.
Admin audit log
All actions performed in the admin panel are captured in a separate admin audit log. This log records every administrative action — banning users, changing plans, toggling feature flags, updating AI configuration — along with the acting admin, target, action type, and a structured details payload. Admin audit log entries cannot be deleted even by platform administrators.
Infrastructure security
CSRF protection
Cross-Site Request Forgery (CSRF) protection is built into WorkWiz's authentication layer via NextAuth. All state-changing requests require a valid session token that is bound to the authenticated origin — forged cross-site requests are rejected automatically.
XSS protection
Cross-Site Scripting (XSS) is mitigated through React's built-in output sanitization, which escapes dynamic content by default, combined with a Content Security Policy (CSP) header that restricts which scripts, styles, and resources may be loaded by the browser. User-supplied content is never rendered as raw HTML.
SQL injection prevention
WorkWiz uses Prisma as its database ORM. All database interactions use Prisma's parameterized query builder — user input is always passed as a typed parameter, never interpolated directly into a query string. This eliminates the SQL injection attack surface at the framework level.