Dieses Dokument liegt auf Englisch und Spanisch vor. Maßgeblich ist die englische Fassung.
How Idovio Commerce protects accounts, workspaces and the credentials of the stores and services a merchant connects. Each line describes a control that is built into the service; where something is not finished, it says so.
Passwords are stored only as salted scrypt hashes. A password must have at least 12 characters with upper and lower case, a digit and a special character, cannot contain the person's name or e-mail and cannot be a common password.
Two-step verification with an authenticator app (TOTP) and single-use recovery codes. It is required for owners, administrators and anyone who connects a store or changes the team.
Sessions are opaque random tokens stored hashed; in a browser they travel in an HttpOnly, Secure cookie with SameSite protection and a second token against cross-site request forgery. A session ends after 30 days without use and at most 180 days after it starts. Each device can be signed out from the account.
Sign-in attempts are limited per network and per account, and errors do not reveal whether an address is registered.
Every record belongs to one workspace. The workspace is taken from the session, never from the request; membership is checked on every request; and the database enforces the separation itself with row-level security on every table that holds workspace data, so a mistake in application code cannot return another workspace's rows.
Roles decide what each member can do (owner, administrator, operator, catalogue manager, order manager, support, finance, analyst, viewer). The number of members is limited by the plan and enforced by the server.
Access tokens and API keys are encrypted with AES-256-GCM under a key that belongs to the workspace, itself protected by a master key held outside the database (envelope encryption). The encryption is bound to the workspace and the name of the credential, so a ciphertext moved to another place does not decrypt.
A stored credential can be replaced or deleted but never read back, not by the browser and not by the person who entered it. On the web, requests to a provider are made by the server, which adds the credential there; the first use binds a credential to that provider's addresses and it is refused for any other.
Connections ask each platform only for the permissions the functions need. Disconnecting deletes the credential.
All traffic uses TLS; plain HTTP is redirected and browsers are told to use HTTPS only (HSTS). The database and file storage are encrypted at rest by their providers. The database is in Frankfurt, Germany.
Database queries are parameterised. Request bodies are validated against strict schemas and unknown fields are rejected. Responses carry a restrictive Content-Security-Policy, no-sniff, frame denial and a strict referrer policy. Request size is limited.
Sign-in through an identity provider uses single-use state, a nonce and PKCE, and only returns to addresses of the service. Webhooks from payment and commerce platforms are accepted only with a valid signature inside a short time window, and each event is processed once.
Automation runs inside limits the merchant sets (minimum margin, largest order, largest price change, permissions per action), can require approval, and can be stopped at once.
A log of security-relevant actions is kept per workspace and shown to its owner: sign-ins, role changes, invitations, connections, key changes. Service logs carry a request identifier and replace passwords, tokens, cookies and keys before they are written. Network addresses are stored shortened. There is no advertising or behavioural tracking.
The web app is always the current version. The service announces the oldest version of the desktop and mobile apps it still syncs with; an older app is asked to update and keeps its data on the device.
There is a written incident response procedure: identify, contain (revoking sessions and credentials), preserve evidence, fix, recover, notify. If an incident affects personal data, the affected customers are told without undue delay, and the platforms and authorities whose rules require it. Report a suspected incident to security@idovio.com.
Write to security@idovio.com with what you found and how to reproduce it. We confirm receipt within two working days, keep you informed, and do not take legal action against research done in good faith that avoids harm to other people's data and to the service. Please give us a reasonable time to fix a problem before making it public. The same information is published at /.well-known/security.txt.
No independent security audit or penetration test of the service has been completed, and Idovio Labs Ltd holds no security certification (such as ISO 27001 or SOC 2). Deletion of provider-derived data is done on request; an automatic purge by age is not yet implemented for every kind of record. This page will say so when that changes.
