Security at Korvix
How we protect the data you trust us with
The short version: customers are separated by the database itself, sensitive values are encrypted one at a time, every route is limited and tested on every change, and the activity log shows tampering instead of hiding it. The long version is below, in plain words, for whoever has to sign off on us.
- Encrypted in transit (TLS 1.2 and 1.3) and at rest
- Hosted in Cape Town, af-south-1
- Two-factor sign-in with backup codes
- Every read of a patient record logged
01
Keeping customers apart
Enforced by the database, not by a filter we remember to add
Every table that holds a customer's data has row-level security: the database decides which rows a request may see from the organisation the request is for. A query that does not say who it is for returns nothing.
Tested on every change
The test suite connects as the application's own restricted database user and tries to read across organisations. A change that weakens the separation fails before it can be released.
Our own staff cannot read clinical records
The connection Korvix support uses is granted nothing at all on the clinical tables, not even read access. It is the database enforcing that, not a policy promising it.
02
Encryption
In transit
Every connection uses TLS 1.2 or 1.3. Browsers are told to use nothing but HTTPS for two years (HSTS), so a hostile network cannot quietly downgrade the connection.
At rest
The database and its backups are stored encrypted, and uploaded files are encrypted before they reach storage.
One value at a time
Names, dates of birth, bank details and clinical notes are each encrypted separately with keys held in AWS Key Management Service, bound to what the value is and whose it is. A clinic can bring its own key and revoke it.
03
Signing in and staying signed in
Two-factor sign-in
Authenticator-app codes with single-use backup codes. Removing a second factor, or regenerating backup codes, asks for the password again first.
Passwords and lockout
Passwords are hashed with Argon2 and must be at least twelve characters. Ten wrong attempts lock the account for fifteen minutes, whichever address they came from.
Sessions that end when they should
Access tokens last minutes, not days. Signing out, or an administrator suspending an account, stops existing tokens within thirty seconds. A refresh token used twice is treated as stolen, and the whole session chain is ended.
Limits on every route
Sign-in, codes, password resets, webhooks and API keys each have their own rate limits, keyed by address, account or key as fits. A test reads every route in the API and fails the build if one that can be reached without signing in has no limit.
04
Records you can stand behind
An activity log that shows tampering
Each entry is linked to the one before it by a hash, so altering or deleting an entry breaks the chain, and a scheduled check verifies it.
Reads are recorded, including refused ones
In Korvix Health every opening of a patient record is logged with who, when and from where, and an attempt that was refused is logged too. The report can be exported for an investigation or a regulator.
Payments that cannot be faked
A payment notice is accepted only from the provider this deployment charges through, only with that provider's valid signature, and only for a charge started through it. A notice whose amount or currency differs from what was asked for is held for a person rather than credited.
05
In the browser
A strict content security policy
Our web apps load scripts only from themselves, send data only to themselves and the Korvix API, run no eval in production and cannot be put inside another site's frame. Camera, microphone and location are switched off for every page.
No tokens in browser storage
The access token lives in memory only, and the refresh token in an HttpOnly, Secure, SameSite=Strict cookie that page scripts cannot read.
06
How we build
Security tests run on every change
More than two thousand automated tests run before anything is released, including the ones that try to cross between customers, forge tokens, skip rate limits or loosen the browser policy.
Dependencies are checked against published advisories
Third-party packages are audited for known vulnerabilities, and a high or critical one is fixed rather than accepted.
Hosted in Cape Town
Everything runs in AWS af-south-1, close to the people using it. Where a customer's law treats that as a transfer out of the country, the transfer is documented with them during onboarding.
Certifications
We do not hold SOC 2 or ISO 27001 certification yet. Until we do, this page and a direct conversation with our engineers are how we answer a security questionnaire, and we are glad to do both.
Report a vulnerability
If you think you have found a security problem in Korvix, please tell us before anyone else. We read every report and reply to the person who sent it.
- 1Email a description of the problem, the steps to reproduce it and what you think the impact is.
- 2Use only accounts and data that are yours, and stop as soon as you can show the problem exists.
- 3Give us a reasonable time to fix it before you share it with anybody else.