Security
SwiftFS treats everything in a request as untrusted: bucket names, object keys, headers, sizes, checksums and claimed identities.
Protections
| Concern | How SwiftFS handles it |
|---|---|
| Forged or replayed requests | Signature Version 4 on every request, a 15-minute clock window, expiring presigned URLs |
| One tenant reading another's data | Every request is authorized against the bucket's account, the key's scope and the bucket's policy |
| Leaked access keys | Keys are scoped and can expire; revoking one takes effect within 15 seconds; secrets are encrypted at rest (AES-256-GCM) and never shown twice |
| Path traversal through object keys | Keys never become file paths: data is stored under server-generated names |
| Corrupted or tampered uploads | Checksums verified before anything is stored; a failed check stores nothing |
| Bit rot and lost files | Stored data is re-read continuously and compared with its checksums |
| Partial writes | Data is synced to disk and its metadata committed before success is reported |
| Floods and runaway growth | Rate limits per key and per IP; quotas per account |
| Features quietly ignored | Encryption, Object Lock and other unsupported requests are refused, never accepted and dropped |
In SwiftFS Cloud
- Passwords are hashed with Argon2id. Sessions are random tokens of which only a hash is stored; they can be ended at once, and a password reset ends them all.
- The console sends requests only from its own origin, with cookies that
are
HttpOnly,SecureandSameSite. - Card details go straight to the card processor and never reach SwiftFS.
- The activity log records sign-ins, membership changes, access keys and deletions, and never contains secrets.
Running SwiftFS securely
- Terminate TLS in front of SwiftFS. Unsigned payloads rely on TLS for their integrity.
- Keep the ops port (health and metrics) on a private interface.
- Provide the encryption key, database credentials and any bootstrap credentials through a secrets manager, never source control.
- Prefer one scoped key per application, with an expiry, over broad credentials.
- Back up PostgreSQL, then the data directory, as described in running SwiftFS, and the encryption key separately.
Reporting a vulnerability
Please report security issues to S&S Labs privately, not in public issues. A dedicated reporting address is published with the source release.