Security audit

Why we tested

Slate holds a business's sensitive records: invoices, customer details, business numbers and amounts. Data like that does not rest on assumptions. We tested the system in practice, from the outside and from the inside.

The audit had two parts: an examination of the live system as an attacker sees it from outside, and a review of the code from within, against an ordered checklist of dozens of known attack scenarios.

What was tested

Separation between businesses

That every business sees only its own data, and that no path lets one account reach another account’s records.

Login and identity

That account access is protected, that the one-time code is safe, and that it cannot be guessed or bypassed.

Permissions and actions

That every action is checked against the user’s permissions, including calls made straight to the API past the interface.

Encryption and transport

That all traffic runs over an encrypted channel, and that sensitive values are stored encrypted as well.

Documents and files

That uploads are safe, and that an issued document stays fixed and cannot be altered.

Resistance to attack

The common attempts: injections, link abuse, and flooding the system with requests.

What was found

The core defences held in every scenario tested. No route was found to take over the system, reach another business's data, or bypass authentication. Tenant separation held on every path attempted, and the login flow did not reveal which email addresses are registered.

The controls behind that result

The defence is built in two layers. The first prevents unauthorised access. The second makes sure that an attempt which gets past it still cannot pull data out.

Blocking a break-in

Server-side authorisation

Every read and write is checked against the caller’s identity on the server, including direct calls to the service layer. That is the defence against horizontal access to another user’s resources (IDOR / BOLA).

Passwordless authentication

A one-time code drawn from a cryptographic random source, time limited, stored as a digest rather than text, with an atomic attempt quota. The session token is signed and locked to a single algorithm, and carries a version that revokes every token at once when a permission changes.

Rate limiting

On the login endpoints, code verification and the public routes. The limit keys off a client identifier the caller cannot choose, even behind a content delivery network.

Injection resistance

No raw queries; all database access goes through a parameterised layer. Output is encoded to prevent script execution (XSS), and a strict content policy (CSP) blocks embedded external code.

Server-side request forgery (SSRF)

No user-controlled destination reaches an outbound request from the server.

Preventing a leak

Multi-tenant isolation

Every query is filtered by account id at the data layer, not only in the view. No route returns another tenant’s record.

Encryption in transit

All traffic is TLS encrypted, with HTTPS enforced and unencrypted connections redirected.

Encryption at rest

Secret values are stored encrypted with AES-256, and the encryption keys are managed outside the code.

Allow-listed output

The API returns a predefined set of fields only. That prevents internal fields from leaking, and also blocks writes to sensitive fields through the input (mass assignment).

Minimal external surface

No environment files, source code, secrets or infrastructure details are exposed. Response headers are hardened against framing on a foreign site and content-type sniffing.

Infrastructure and network

Edge protection

All traffic passes through Cloudflare, which provides denial-of-service (DDoS) protection and filters malicious requests at the edge, before they reach the server.

Enforced encryption (HSTS)

The browser is required to reach the system over an encrypted connection only, subdomains included, so there is no window for an insecure connection.

Secrets kept out of the code

Keys and secrets are managed outside the codebase, and the process runs with minimal privileges to limit the damage from any single fault.

Backup and recovery

Data is backed up continuously, so it remains recoverable even through an infrastructure failure.

What this means for you

Your business data is isolated, and no other user can see it. Information is encrypted in transit, and sensitive values are encrypted in storage too. An issued invoice is kept exactly as it was produced and cannot be changed after the fact, as the law requires. The full detail on the digital signature and on document verification is on the security page.

What comes next

One audit is not the end of it. We re-examine the system with every significant change and update the defences as needed.