Reporting a vulnerability
Email security@saiberlab.com. Tell us what you found and how to reproduce it. We will acknowledge within 3 working days and keep you updated until it is resolved.
We will not pursue legal action against anyone acting in good faith: testing only against your own account, not accessing or modifying other people’s data, not degrading the service, and giving us a reasonable chance to fix the issue before publishing. We do not currently run a paid bounty programme, and we would rather say so than imply one.
Authentication
- Passwords are hashed with argon2id. We never store the password itself and cannot recover it — a reset is the only route back in.
- New passwords are checked against known-breached password corpora, and weak or reused credentials are rejected at the point of choosing them rather than complained about later.
- Two-factor authentication (TOTP) is available on every account and can be required across a whole workspace.
- Sessions are server-side records. The cookie carries only a session identifier, validated against the database on every request, so revoking a session takes effect immediately rather than whenever a token happens to expire.
Authorisation
Every request for workspace data is authorised on the server against the caller’s role, in the service layer — not in the interface. Hiding a button is never the only thing standing between someone and data they should not see, and subscription state is never trusted from the client.
Seven roles across thirty-two permissions, with meaningful separation: a designer can restyle a code but cannot repoint a live one; an analyst can export but cannot modify; a client-portal user can only ever see records scoped to that client.
Data protection
- Sensitive fields — two-factor secrets, integration credentials, API keys — are encrypted at rest with AES-256-GCM. API keys are additionally stored only as a hash, so a leaked key can be revoked but never read back.
- Data in transit is TLS throughout, with HSTS on our own domains.
- Databases are never exposed to the internet; they are reachable only on a private network alongside the application.
- Logs redact passwords, tokens, secrets, authorisation headers and cookies. We do not log the IP addresses of people who scan codes at all.
Protecting people who scan
A printed code cannot be recalled, which makes the redirect service a target. Destinations are validated when set: addresses resolving to private or link-local network ranges are rejected outright, and redirect chains are followed to their end rather than trusting the first hop. A code found pointing at phishing or malware may be suspended immediately and without notice — we would rather do that than let something we serve harm the person who scanned it.
What we have not done
We hold no third-party security certification — no SOC 2, no ISO 27001 — and we have not commissioned an external penetration test. Saying so plainly matters more than the reassurance of omitting it. If your procurement requires either, talk to us about enterprise terms before you commit.
Incidents
If we discover a breach affecting your data we will notify you and the relevant supervisory authority within the periods the law requires, with what we know at the time rather than waiting for a complete picture. Our privacy policy covers what data exists to be affected.