Security overview

For security reviewers evaluating a self-hosted Artavolo instance. Version 5.0.

Architecture

• Single application container (Apache 2.4, PHP 8.1, websocket server, cron) plus MariaDB, behind a reverse proxy (Caddy in the reference stack) that terminates TLS.
• Two databases: the application schema, and a data database holding one plain InnoDB table per user table. Uploaded files live on a volume.
• No outbound connections are required. The application does not phone home; licence verification is an offline Ed25519 signature check. Optional integrations (Slack, Twilio, Mailchimp, OpenAI or Mistral AI, Google Drive, Dropbox, OneDrive, Pusher) are off until an administrator configures them. AI can also go to a model inside your own network (AI_COMPATIBLE_URL in includes/config.php), so no prompt leaves it.

Authentication

• Passwords: Argon2id (bcrypt fallback), unique salts, transparent upgrade of older hashes.
• Brute-force protection: 5 failures per account or 20 per IP within 15 minutes lock the identity for 15 minutes; applies to passwords, 2FA codes, API credentials and guest passwords.
• Two-factor authentication: TOTP with recovery codes.
• Sessions: HttpOnly, SameSite=Lax, Secure cookies; new session id at login; optional idle timeout that also revokes "remember me" tokens; strict session mode.
• API: Basic auth with the account password or a revocable API token, or the browser's per-session token; accounts with two-factor authentication must use an API token. Stored password hashes are never accepted as credentials and never leave the server. Uploaded files are served through a permission check that follows sheet visibility: read-only members and guests only receive files a sheet they may view references.
• Enterprise: OpenID Connect single sign-on (Entra ID, Keycloak, Okta), optional enforcement, just-in-time provisioning.

Authorization

• Roles per workspace and per base: owner, contributor, read-only. Base-level rules for who may create, edit and delete records.
• Public sharing is opt-in per table: read-only guest views and submit forms, each with an optional password that is hashed and verified server-side. A published form never exposes existing rows.
• Uploaded files are served through a permission-checked route; time-limited signed links exist for e-mail and webhooks.
• Row rules (base permissions, "Who sees which records"): a table can show people only their own records (a person field holding them, who added the record, or a text field holding their e-mail) or only records with one value, for everyone but owners or for read-only members only. It is enforced on the server on every path that hands records out: the table as it opens, queries and search, the v2 API, AI chat, files attached to records, the trash, live updates and guests of a published table. A restricted person's new records are filled in to match, they cannot change the field the rule is about, and they cannot empty the table.
  • Live updates of a table with a row rule reach only the people who see every record; the others see changes when they next open it.
  • On an instance that encrypts cell values, a rule on any field but "created by" cannot be applied inside a database query. The table still opens filtered; queries and search return nothing to a restricted person there, and the v2 API and AI chat refuse with an explanation.
  • Not covered: automations that e-mail or message records go to whoever the automation names, and a kanban table's activity history names the tasks moved in it.

Data protection

• Recommended at-rest protection: encrypted disks or volumes for MariaDB and uploads (the application-level cell encryption is optional and ships without default keys).
• data/ (dumps, logs), includes/ (configuration) and libs/ are not web-readable.
• Encrypted backups of both databases and the uploads folder: one archive per run, AES-256-CTR with a random IV and an HMAC-SHA256 tag over the whole file (keys derived from BACKUP_ENCRYPTION_KEY, which never leaves the instance); integrity is verified before anything is decrypted. Available from the shell in every edition (utilities/backup.php, utilities/restore.php); Enterprise adds the daily schedule, retention, the S3-compatible off-site copy (AWS Signature V4 over TLS) and failure alerts to administrators.
• Erasure (GDPR Art. 17): members delete their own account from their profile (typed e-mail plus password; SSO-authenticated sessions confirm with the typed e-mail); administrators can erase any member. The routine removes the member record, external identities, API tokens, sessions, permissions, invitations, history, notes, discussion posts and the avatar, clears the author references in data tables and records member.erased in the audit log. Sole owners of shared workspaces must hand them over first. Workspace deletion removes its uploads.

Auditing (Enterprise)

Append-only audit log of logins, record changes, permission changes, exports, backups and settings changes with actor, IP, user agent and before/after values; filterable in the UI and exportable as CSV/JSON; retention configurable.

Operations

• Signed releases: SHA-256 checksums for tarballs, versioned Docker images.
• GET /status health endpoint (version, database reachability, licence state; no secrets).
• Migrations run in-process under a database lock; maintenance scripts require an administrator or a deployment token.
• Supported: the current major version and the previous minor; security fixes are announced in the release notes.

Vulnerability handling

Report to the security address in your licence e-mail. Acknowledgement within 2 business days; fixes for confirmed high-severity issues are released as point versions.