Security by mechanism
We describe security by what the system does, never by an adjective. Each mechanism below is in the system, and each guard ships with a test.
- Two-factor login for staff
- Mandatory for staff accounts, with trusted devices that can be revoked, one by one or all at once.
- Permissions on the server, on every request
- Roles with default permissions plus a per-user switchboard; every change is audited.
- Deactivation on the next request
- A deactivated account is refused on its next request; its API keys go inert with it and never need reissuing.
- One instance per company
- Each hosted company is a full separate instance: its own database, files and domain. Isolation is structural, not a query filter.
- Rate limiting and lockouts
- Login and code checks are rate-limited; accounts lock after repeated failures; passwords are hashed with bcrypt or argon2.
- Guarded outbound calls
- Every URL the server fetches is checked against private and internal addresses, at save time and again at send time; redirects are never followed.
- Validated uploads
- The size is asked before the bytes are read; files are validated by type and size; user text is escaped at the boundary of every document it enters.
- Append-only records
- Financial and audit records are never edited; corrections are reversing entries.
- Encrypted credentials and backups
- Gateway, two-factor and partner credentials are stored encrypted; backups of the database and files are encrypted off-site to a public key, with tested restores.
- Firewall and TLS
- Only the web ports are open; TLS everywhere; the application runs as a non-root user with a least-privilege database account.
- A test behind every guard
- A review programme in which every guard ships with a test that fails when the guard is removed.
Want to see the system on cases from your own work?
Write to us on WhatsApp or by email and we will arrange a walkthrough on examples from your operation.