Security
You keep your customers' data in inSpace CRM, so you are owed a straight answer about what protects it. This page states only what the system does today, checked against the code: the short version first, then the technical detail for whoever needs it.
- Who can see my company's data?
- The people on your team you give access to, with the role you choose. Every workspace is separate from the others: another company using inSpace CRM cannot see your contacts.
- Do inSpace staff get into my account?
- Only when it is needed to support you or fix a fault, and every time it is recorded who went in, when, and when they left.
- What if someone tries to guess my password?
- After five failed attempts in fifteen minutes, that email stops accepting passwords until the time has passed. And your password is not stored as typed: it is stored in a form nobody can read, us included.
- Is my information protected in transit?
- Yes. The site only works over an encrypted connection, and anyone arriving without one is sent to the encrypted version before seeing anything.
- Who sends my emails and takes my payments?
- Your own accounts. Email and SMS go out through the services you connect, never through an account shared with other companies. Payments happen on Stripe's page, so card details never pass through our server.
1. Separation between companies
All companies share one database, and every record carries the identifier of the workspace it belongs to. That is the usual model for a cloud service; what matters is that the separation holds on every request, and this is how it does:
- Before serving a request, the system works out which company the address
belongs to,
yourcompany.inspacecrm.com. A session started in another company is not honoured: it is closed and you are asked to sign in again. - Queries on tables holding customer data filter by workspace. Asking for another company's record answers exactly like asking for one that does not exist, so it does not even confirm that it exists.
- The session cookie belongs only to your company's address, and the browser does not send it to anyone else's.
How we check it
- An automated review reads the code and flags any query on a customer-data table that does not say which company it is for. The few exceptions — the admin console, signing in — are written down with their reason.
- Tests against the server create a second workspace. With an API key from that workspace they try to read, edit and delete a contact in the first; with a session, to edit, move and delete one of its opportunities. Every attempt has to be refused.
2. Passwords and access
| What | How |
|---|---|
| Passwords | Stored as bcrypt hashes, never in the clear. Nobody can recover one, only reset it. |
| Sign-in attempts | After five failed attempts for the same email in fifteen minutes, further attempts are refused. Every failed attempt is recorded with its IP address. |
| Session | Signing in creates a new session identifier, and the previous one stops working. |
| Password reset links and invitations | Only their hash is stored. The one readable copy is in the email you receive. |
| Roles and permissions | Everyone signs in as themselves, with a role. The permission is checked on the server on every request: hiding a menu item is not what protects anything. |
3. Connection and browser
| What | How |
|---|---|
| Connection | HTTPS only. A request over HTTP is redirected to HTTPS, and the server
sends Strict-Transport-Security so the browser does not try
without encryption again. |
| Session cookie | Secure, HttpOnly and SameSite=Lax,
with no shared domain: it never travels unencrypted, JavaScript cannot
read it, and it is not sent to another subdomain. The server refuses
session identifiers it did not create itself. |
| Request forgery | Every action that changes data inside the account requires a CSRF token tied to your session. |
| Headers | X-Content-Type-Options: nosniff,
X-Frame-Options: SAMEORIGIN — the CRM cannot be embedded in
another site; the one exception is public forms, which are made to sit on
your own page and show nothing from the account —,
Referrer-Policy: strict-origin-when-cross-origin
and a Permissions-Policy with no access to location,
microphone or camera. |
4. API
- A key is shown once, when it is created. After that we keep only its SHA-256 hash and a prefix so you can tell your keys apart.
- Every key belongs to one workspace and reaches only that workspace.
- Keys are revoked from Settings, and stop working as soon as the company or the workspace is suspended.
- Requests are rate limited.
5. Connected services and payments
- Email. Each company sends through its own account, Mailgun or an SMTP server. If it has not connected one, the email does not go out: there is no shared fallback account mixing your sending reputation with other companies'.
- SMS. The same, through each company's own Twilio account.
- Payments. Each workspace uses its own Stripe key, and your customer pays on Stripe Checkout: card details are captured by Stripe and never pass through our server. The key is never shown in full again, only its last four characters.
- Incoming messages. An inbound email or SMS is accepted only with the provider's valid signature; for email, the signature must also be less than fifteen minutes old.
- Unsubscribe links. They are signed, so nobody can forge one to unsubscribe someone else.
6. Our staff's access
Authorised inSpace staff can enter a customer's account to provide support or fix a fault. This is how it works:
- Only a platform administrator can do it, and it cannot be used to enter as another platform administrator.
- Access goes through a single-use link that expires after sixty seconds.
- It is written to the audit log when requested, on entering and on leaving, with who did it.
- For as long as it lasts, the staff member's screen shows a fixed notice that they are inside someone else's account.
7. If something goes wrong
No system is infallible. If a breach materially affected your data, we would tell you without delay, as the Privacy Notice sets out.
This page changes when what the system does changes. The date at the top is its last review.