Security Overview

1. Passwords and sign-in

Passwords are never stored in readable form. Each password is hashed with a slow, memory-hard function and a unique random salt per account, so that two identical passwords produce different stored values and a stolen database cannot be reversed with precomputed tables.

You can also sign in with Google, Microsoft or Facebook. In that case no password exists for us to store at all. Signing in this way proves your identity to us and nothing more — it grants us no access to your mail, files or contacts at those providers.

2. Sessions

A session is a signed reference to a record on our servers, held in a cookie that scripts in the browser cannot read and that is transmitted only over HTTPS in production.

Sessions last 30 days. You can see the active sessions on your account — device, browser and last activity — and end any of them immediately from your security settings. Ending a session revokes it on the server, not just in that browser.

3. Tokens for connected platforms

The access tokens for your connected advertising and social accounts are the most sensitive data we hold, because they act on your behalf on another platform. They are treated accordingly.

Tokens are encrypted before storage using AES-256-GCM — an authenticated cipher, so a modified ciphertext fails to decrypt rather than yielding altered data — with a fresh random initialisation vector for every value, and a key identifier stored alongside so keys can be rotated.

When you disconnect a platform the stored token is deleted, not marked inactive. When you close your account, tokens are deleted first, which ends our ability to reach those platforms.

4. Access control

Every request is authorised on the server against the signed-in user and the organisation the requested data belongs to. Data is scoped to the organisation at the point of query, so a request that names another organisation's record returns nothing.

Platform staff, customer organisations, developers and affiliate partners are separated into distinct areas with distinct requirements. Belonging to one does not grant access to another, and platform staff do not have customer workspace access by virtue of their role.

5. Securing the connection flow

Connecting an external account is the moment an attacker would target, so it is protected on both sides. Each authorisation carries a single-use random value tied to a cookie that scripts cannot read, which is what prevents a forged authorisation from being accepted.

Where the provider supports it we use PKCE, so that an authorisation code intercepted in transit cannot be exchanged for a token by anyone who does not hold the verifier — and the verifier never leaves our server.

Provider secrets are held only on the server. No client secret is ever sent to the browser.

6. Payments

Card details are entered with our payment provider and are never transmitted to or stored on SAIMA's systems. We hold the outcome of a payment and the invoice record, not the instrument.

7. Data in transit

All traffic between your browser and the platform, and between the platform and every provider we call, is encrypted in transit over TLS. Cookies that carry authentication or tokens are marked secure in production and are not accessible to scripts.

8. What we have not built yet

We would rather tell you this than have you assume it. Multi-factor authentication is not yet available, and a customer-facing audit log of actions taken inside a workspace is not yet available. Both are planned.

If either is a requirement for your organisation, ask us for the current position before contracting rather than relying on this page, which we update as the platform changes.

9. Reporting a vulnerability

If you believe you have found a security issue, write to security@saimahub.ai with enough detail to reproduce it. We investigate every report and will not pursue anyone who reports in good faith and does not access other users' data or degrade the service.