Security & Privacy

This page summarises the main security and privacy controls built into Workable. It is intended to help admins understand how the product protects organisation data in practice.

Important

This guide describes the protections implemented in the application and API. It is a practical product overview, not a formal legal, compliance, or certification statement.

1. Secure Transport

Workable is designed to protect data in transit with encrypted connections and common browser hardening controls:

• HTTPS / SSL / TLS is used between your browser and the application
• Database connections can be configured with SSL, and the current managed PostgreSQL hosting setup provides encryption in transit and encryption at rest
• HTTP Strict Transport Security (HSTS) is applied
• The app also sends standard hardening headers including:
  • Content-Security-Policy
  • X-Frame-Options: DENY
  • X-Content-Type-Options: nosniff
  • Referrer-Policy
  • Permissions-Policy

Together, these controls help reduce interception risks, clickjacking, unsafe embedding, MIME sniffing problems, and other browser-layer attacks.

2. Authentication and Account Protection

Workable uses passwordless authentication rather than storing user passwords in the application.

The main controls include:

• Email verification during sign-up before an account is activated
• Magic link sign-in with a one-time verification code
• Short-lived authentication links and codes
• Secure random token generation for authentication flows
• Constant-time verification for login code checks
• JWT-based API authentication with token expiry
• Account enumeration protection on login requests

Sensitive authentication endpoints are also rate limited to reduce brute-force and abuse attempts.

3. Authorisation and Organisation Data Boundaries

Workable is a multi-tenant application, so keeping data separated between organisations is a core security requirement.

The application enforces this in multiple layers:

• Role-based access control defines what a Viewer, Contributor, Org Admin, and Billing Manager can do
• API permission checks verify authentication and required permission level
• Organisation membership checks ensure a user can only act within organisations they belong to
• Server-side enforcement means permissions are not trusted from the client alone
• PostgreSQL Row-Level Security is enabled on organisation-scoped tables
• Forced RLS is enabled on key multi-tenant tables

In practice, Workable uses both application-level authorisation and database-level isolation to prevent cross-organisation data access.

4. Input Validation and Abuse Mitigation

Workable includes several controls to reduce the chance that malicious or malformed input reaches sensitive logic:

• Schema validation with Zod is used for many API payloads and stored JSON structures
• Request size limits are applied on larger endpoints such as scheduler requests
• Safe JSON parsing includes checks for dangerous keys associated with prototype pollution
• String sanitisation and HTML escaping are used to reduce XSS and injection risks
• Server-side feature enforcement prevents clients from enabling restricted features simply by manipulating frontend requests
• Input constraints such as maximum lengths, array limits, UUID checks, and numeric bounds are used throughout the planning data model

These protections are intended to help the API fail safely when requests are invalid, unexpected, or intentionally abusive.

5. Logging, Monitoring, and Traceability

Workable records important events that support security review and incident investigation.

Examples include:

• Authentication events such as magic link requests and successful verification
• Invitation and membership changes
• Role changes and access-management actions
• Billing manager transfers and other administrative actions

Authorised administrators can review organisation audit logs, which provides traceability for sensitive changes.

6. Data Protection and Privacy Practices

Workable is designed to minimise unnecessary exposure of sensitive data:

• Organisation data is segregated so users only access organisations they belong to
• Least-privilege access is applied through roles
• No password database is required for normal sign-in
• Payment details are handled through Stripe-hosted flows rather than raw card collection inside Workable
• Data exports and destructive actions are restricted to authorised roles

7. Shared Responsibility

Workable includes technical safeguards, but secure operation also depends on organisation administrators using the product carefully.

Recommended practices:

• Keep the number of Org Admins limited to trusted users
• Review member roles regularly and remove access that is no longer needed
• Transfer Billing Manager only when necessary and to the correct admin
• Treat exported data files as sensitive
• Use verified email accounts and secure mailbox access

Summary

Workable protects data with a layered approach:

• Encrypted transport
• Provider-backed encryption at rest
• Passwordless authentication with short-lived tokens
• Role and organisation-based access control
• Database row-level isolation
• Validation, sanitisation, and rate limiting
• Audit logging for sensitive actions

Together, these controls are intended to protect user and organisation data, preserve tenant boundaries, and reduce the risk of misuse or unauthorised access.