Operations
Security
How PurrOS protects sensitive data, what you are responsible for as the operator, and how to report a vulnerability.
PurrOS holds sensitive data: employee details, pay, cash, and business performance. This page covers how PurrOS protects it and what you should do as the operator.
Built in
| Area | Protection |
|---|---|
| Sign-in | Argon2id password hashing, optional or mandatory 2FA, rate limiting and lockout (passkeys and SSO planned). See Authentication. |
| Sessions | Server-side sessions, secure httpOnly cookies, idle and absolute timeouts, remote sign-out, origin checks against cross-site requests |
| Access control | Organization-defined roles, permissions with reach, escalation protection, checked on every API request |
| Features | Switched-off features are unreachable through the API, webhooks and jobs |
| Sensitive fields | Pay data needs its own permission (pay.read). (Planned: national IDs and bank details, encrypted at the column level and shown only with employees.sensitive.read.) |
| Secrets | Integration config secrets, webhook secrets and TOTP secrets are encrypted with keys derived from PURROS_SECRET. Backups can be encrypted with their own passphrase. |
| API keys | Stored only as hashes, shown once, scoped, can expire, and record when and from where they were last used |
| Webhooks | HMAC-SHA256 signatures with timestamps, to prevent spoofing and replay |
| Integrations | Run outside PurrOS, limited to declared scopes (including which webhook events they receive), labelled in the audit log. Keys can be rotated with a grace period, and only people can manage integrations. |
| Web | Origin checks against cross-site requests, strict Content Security Policy, security headers |
| Audit log | Append-only record of every change, sign-in, permission change and feature switch, with actor, time, IP and before/after values |
Your responsibilities as operator
- Serve over HTTPS only, with a valid certificate, and redirect HTTP to HTTPS.
- Protect
PURROS_SECRETand theconfig/directory. Don't commit them to version control. - Keep PurrOS updated. Security fixes ship as patch releases, and each release note says whether it contains security fixes.
- Don't expose PostgreSQL or Redis to the internet. Keep them on a private network.
- Restrict admin tooling at the proxy (and
/api/metricsonce metrics ship). - Back up and encrypt backups. They contain everything.
- Review access regularly: who has Owner and HR roles, active integrations and personal API keys.
purros users listshows each account's role, 2FA and last sign-in;purros integrations list(orGET /api/v1/integrations),purros api-keys listandGET /api/v1/webhook-endpointsshow integrations, keys and where webhooks go. - Consider requiring 2FA for roles with access to pay, sensitive data or cash.
Privacy and personal data
- Employees can export all their data as a ZIP from the Employee Area (
GET /api/v1/me/export). - PurrOS sends no data anywhere you haven't configured: there is no telemetry and no AI provider today.
- (Planned: anonymizing a former employee after your retention period while keeping totals for reporting; retention settings for kiosk photos, messages and audit details; an optional AI assistant that only sends data to a provider you configure; opt-in anonymous telemetry.)
PurrOS gives you tools to meet privacy obligations such as GDPR or CCPA, but you, as the data controller, are responsible for configuring and using them correctly.
Reporting a vulnerability
Please don't open a public issue. Use GitHub's private vulnerability reporting on the PurrOS repository (Security → Report a vulnerability). We aim to acknowledge reports within 3 working days.