Security fixes are made on the current development branch until tagged release support rules are published.

The implemented security boundary covers the file/version server, its HTTP API and Web UI, the Windows client's connection handling, and its automatic upload/download and confirmed remote-file deletion engine. Complete offline, local-delete, rename, and multi-device reconciliation are not yet implemented or supported security surfaces.

Do not open a public issue for a suspected vulnerability. Use the repository host's private security-reporting feature when available, or contact the maintainers privately through the project-host account.

Include:

• affected commit/version and operating system;
• a minimal reproduction and expected impact;
• whether the issue requires local library access, a valid account/session, or only network access;
• relevant request IDs and sanitized logs.

Do not include real passwords, device/session tokens, private keys, personal filenames, or file contents. Replace them with test values before sending a report.

• One trusted service account exclusively owns the managed library.
• Passwords are hashed with a unique salt and PBKDF2-HMAC-SHA256. Failed login attempts are rate limited by normalized username and source address.
• API session tokens are random, expire after an idle lifetime, remain in server/client memory, and are never placed in URLs.
• Persistent device tokens are random and revocable. The server stores only a token hash; the Windows client stores the token in Credential Manager under the current user. Passwords, device tokens, and session tokens never enter the client INI. Compromise of that Windows user can expose the device token.
• Password changes, account disablement, and account deletion invalidate that user's sessions and devices. Permission changes apply to existing sessions.
• Stable server, account, and folder binding IDs prevent URL aliases or a nonempty local folder from silently changing identity.
• Web sessions use HttpOnly, SameSite=Strict cookies and CSRF validation. Reverse-proxy deployments set web_secure_cookie=1.
• Non-loopback traffic uses certificate-validated HTTPS.
• A reverse-proxy deployment keeps the Lazync HTTP listener on loopback.
• Server files are plaintext; disk/NAS encryption and physical security remain the operator's responsibility.
• Backups include files/ and .lazync/ in one consistent snapshot.

The root-managed administrator password intentionally remains in the private server INI. Deployments that make that file readable beyond root/the service, enable allow_insecure_http, share the library with external writers, or expose an untrusted reverse proxy are outside the supported security model.