Security

Cloudillo is built for people who want to own their data. Security and data ownership were design goals from the start, not features added later. This page gives an overview of how Cloudillo protects your data and what to expect as an operator.

Your data stays yours

• You choose where your data lives. Run Cloudillo yourself, or use a host you trust. Your identity is your own domain name, so you can move without losing it.
• No telemetry. Neither the server nor the web app contains analytics or crash-reporting services.
• Fine-grained visibility. Attribute-based access control decides who can see what, from public down to direct recipients only. When a visibility setting is missing or unknown, the most restrictive one applies. Each profile section can have its own visibility.
• Share links can’t escalate. A share link or scoped token never grants more than it was given, and it can’t create new shares.

Cloudillo doesn’t use end-to-end encryption, and that is a deliberate choice. Your data is held by your own server, run by you or by a host you chose. Because the server can read your data, it can offer search, real-time collaborative editing and federation with other servers. Your trust rests on who controls the server, not on hiding data from it.

More: ABAC permissions

Accounts and sign-in

• Passkeys (WebAuthn) and TOTP two-factor authentication. Each instance can make two-factor authentication optional or required.
• Passwords are hashed with bcrypt.
• QR-code login lets you sign in on a desktop by approving it from a phone that is already signed in.
• API keys can be limited to specific scopes and are stored only as hashes.
• Session tokens are sent in the Authorization header, not as cookies, so classic cross-site request forgery (CSRF) attacks don’t apply.
• Security alerts: you get an e-mail about events such as repeated failed logins or a two-factor reset, and you can view your own audit log.

More: Authentication guide

Trust between servers

• Every profile has its own P-384 key pair. Each federated action is a signed token (ES384), and the receiving server checks it against the sender’s public key, fetched over TLS from the sender’s own domain.
• Identities are DNS-based, and the server resolves DNS records itself rather than relying on an outside resolver.
• Administrators can allow or deny specific peer servers.
• Connection requests require a small proof-of-work to deter spam.

More: Federation security, Verification, DNS-based identity

Apps and the browser

• Third-party apps run sandboxed. Each one runs in an isolated iframe on a separate origin, with no access to the Cloudillo interface or your session. The server enforces the same sandbox, so it still holds when an app is opened directly.
• Strict security headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), nosniff and a strict referrer policy. Uploaded SVG images are served in a sandbox.
• Your session token is encrypted (AES-GCM) in the browser’s storage.
• Automatic TLS certificates from Let’s Encrypt, using the memory-safe rustls TLS library throughout.

More: Network & security, Microfrontends

Abuse resistance

• Layered rate limiting by IP address and by network, with automatic temporary bans after repeated failed logins.
• Size limits on requests, uploads and WebSocket messages.
• Image decoding and archive extraction run within resource caps. PDF text extraction runs in a separate, resource-limited process.

How it’s built and shipped

• Memory-safe by construction: the server is written in Rust, and unsafe code is forbidden across the whole codebase. Lint rules forbid shortcuts that can crash the server (unwrap, panic).
• Access-matrix tests: an integration suite of more than 10,000 cases sends real API requests as many kinds of caller to many kinds of object. The callers include owners, connections, followers, strangers, anonymous visitors, holders of share links and scoped tokens, and deliberately forged tokens. The objects are files and actions at every visibility level and lifecycle state. Each response is checked against an independent description of the access policy that never calls the server’s own access-control code. It runs in CI, and every release publishes the resulting access-matrix report next to its test-coverage summary.
• Dependency checks: cargo deny checks security advisories, licences and package sources daily and on every dependency change. cargo vet runs in CI, and pnpm audit covers the frontend. CI workflows pin every action to an exact commit and run with read-only permissions.
• Signed releases: container images are signed with cosign and carry a CycloneDX software bill of materials (SBOM) as a signed attestation. Release checksums are signed too.
• Minimal image: the container is built from scratch with no base operating system and runs as a non-root user.
• Verified backups: daily backups include a checksum manifest that is checked before a restore.

For operators

When you run your own instance, these are your responsibility:

• Encrypt your disks. Cloudillo stores data unencrypted on the server’s disk.
• Keep off-site copies of the daily backups.
• Consider requiring two-factor authentication by setting auth.mfa to required.
• Restrict federation with the federation.peers allow/deny list if your instance should talk only to known servers.
• Watch the security alert e-mails and the audit log. Administrators can export the audit log as CSV.

Current limitations

• Cloudillo is alpha software, and only the latest release is supported.
• Data is not encrypted at rest. Use full-disk encryption on the host.
• There has been no independent third-party security audit or penetration test yet.
• There is no bug bounty program.

Reporting a vulnerability

E-mail security@cloudillo.org or use GitHub’s private vulnerability reporting. Good-faith security research is covered by a safe harbour. We use coordinated disclosure: please keep details private for up to 90 days, until a fix is published as a GitHub security advisory. Issues of medium severity or higher get a CVE ID.

For response times and full details, see SECURITY.md.