Authentication
Local passwords are protected with Argon2id. Accounts can add TOTP or email-based two-factor authentication, with recovery codes kept for the day a second factor is unavailable.
Optional OIDC lets an operator connect an existing identity provider instead of creating another isolated identity system. Local access remains useful for smaller installations and recovery planning.
Login lockouts slow repeated credential attempts, while IP allowlisting can narrow access to an expected network range where that model fits.
Permissions and tokens
Users should see only the spaces and actions granted to them. Administrative access is separate from routine file access, and share links are limited to the selected resource and configured behavior.
API and client access uses scoped tokens. Give each token only the permissions it needs, name it for the device or automation using it, and revoke it when that use ends.
File safety
File paths are hardened to keep requests inside configured storage roots. This is especially important wherever user-controlled names meet operating-system paths.
FileYard uses atomic-write patterns so a replacement becomes visible as a complete operation rather than exposing a partially written destination. Atomic writes reduce one class of corruption; they do not replace filesystem health checks, redundant storage, or backups.
Administrative controls
Audit logs record important authentication, sharing, and administrative events. Operators can use them to investigate unexpected access and to understand who changed a sensitive setting.
Security still depends on the surrounding host:
- Keep the operating system and reverse proxy patched.
- Use TLS for traffic outside a trusted loopback connection.
- Run FileYard as a dedicated, unprivileged account.
- Grant filesystem access only to intended storage paths.
- Store secrets outside the repository and rotate them after exposure.
- Back up data and test recovery on another machine.
What has not been claimed
FileYard has not claimed an independent security audit. Implemented controls are not the same as a formal assessment, and early software deserves a conservative threat model.
If the service is reachable from the public internet, use defense in depth: a maintained proxy, narrow network policy, strong account authentication, and prompt updates.
Reporting
A dedicated security contact will be published with the source repository. Until then, do not post exploitable details in a public issue tracker. Preserve the affected version, a minimal reproduction, and relevant logs with secrets removed.
The project will add a SECURITY.md with the preferred private reporting channel before public releases are presented as production-ready.