·Technical detail

How the platform is engineered to protect your data.

This is a reference for security and IT reviewers. It describes the controls and the standard mechanisms behind them at a level useful for due diligence, without exposing implementation detail that would help an attacker. For a full security questionnaire or a review under NDA, get in touch.

Transport & network

All traffic is served over HTTPS/TLS; plaintext requests are redirected. TLS is terminated at our edge and proxied to the application over an isolated internal network.
Session cookies are flagged HttpOnly, Secure, and SameSite=Lax, so they can't be read by client-side scripts and aren't sent on cross-site requests.
Cross-origin requests are restricted to our own application origins.

Authentication & sessions

Sign-in issues a short-lived access token (around an hour) and a longer-lived refresh token. Access tokens are cryptographically signed (HMAC-SHA256) and verified on every request.
Each refresh token maps to a server-side session record. Sessions are re-validated on every request and can be revoked at any time, so a revoked or expired session stops working immediately.
Refreshing a session rotates its tokens.

Credentials

Passwords are stored only as salted one-way hashes using bcrypt (work factor 12). We never store or log passwords in plaintext.
We enforce a minimum length and character-class policy on passwords.
Account setup and password reset use single-use, time-limited links rather than transmitting credentials.

Tenant isolation

Every customer organisation is logically separated. Sign-in is bound to the organisation's own address, so credentials valid for one organisation cannot be used to reach another.
A server-side authorization check compares the acting user's organisation against the target record on every create, update, and delete, any cross-organisation operation is blocked before it runs.

Authorization & access control

Access is role-based and evaluated on the server, per request, against the user's role and the action requested.
Any temporary elevation of access is time-bound and re-checked on each request.
Guest and share links are read-only and scoped to specific data.

Application security

All API input is validated against strict schemas; unexpected fields are rejected.
Database access uses parameterised queries throughout, protecting against SQL injection.
Authentication tokens live in HttpOnly cookies rather than browser-accessible storage, reducing the impact of cross-site scripting.

Links & one-time tokens

Invitation, password-reset, and share links use 256-bit cryptographically-random tokens.
Only a one-way (SHA-256) hash of each token is stored, the usable value exists only in the link itself.
These tokens are single-use and expire after a limited time.

Abuse prevention

Requests are rate-limited per client, per user, and per action type, with stricter limits on sensitive operations.
Abnormal request volumes are throttled, and denials are recorded.

Logging & auditability

Security-relevant events, sign-ins, permission and role changes, exports, and data changes, are written to an audit log capturing who acted, what they did, the outcome, the source, and when.
Audit data is retained for a defined period to support investigation and compliance.

Need more detail for a procurement or security review?

This overview intentionally omits proprietary implementation detail. We're happy to complete a security questionnaire, share a penetration-test summary, or walk your team through specifics under NDA.

[email protected]Report a vulnerability