Security

Security

Warracker holds your purchase history, receipts, and documents, so a few habits matter more here than in a typical self-hosted app. This page collects them in one place.

Contents

• Keep Warracker updated
• Use HTTPS in production
• Set a real SECRET_KEY
• Close registration when your users are in
• Use strong, unique passwords
• Think before enabling Global View
• Keep a second admin, and back up
• What Warracker already does
• Reporting a vulnerability

Keep Warracker updated

Security fixes ship in regular releases — for example, the 1.0.3 release fixed an authorization flaw in file downloads and a stored cross-site scripting issue, and 1.0.4 added access control for Paperless-ngx documents. Update promptly when a release mentions security, and read the release notes first. See Updating.

Use HTTPS in production

Serve Warracker over HTTPS via a reverse proxy (see Reverse Proxy). Over plain HTTP, login credentials and session tokens travel unencrypted. Never expose the plain http://server:8005 address to the internet.

Set a real SECRET_KEY

SECRET_KEY signs login tokens and sessions. Generate one and put it in .env:

openssl rand -hex 32

If you leave it empty, the app generates a key inside the container that is lost on recreate (sessions invalidate, data is unaffected) — and if the key is ever guessable, login tokens can be forged. Also set strong, unique database passwords in .env. See Configuration.

Close registration when your users are in

Once everyone who needs an account has one, turn Registration Enabled off in Settings (Admin → Site Settings). An open registration page on a public instance is an invitation to strangers. The first account on a fresh install is always creatable, so this only affects later sign-ups.

Use strong, unique passwords

Warracker stores passwords hashed with bcrypt and enforces a password policy, but a weak password is still the easiest way in. Use a password manager, and give every user their own account — never share one login across a household or team, because accountability and access control depend on it.

Think before enabling Global View

Global View lets every user see every warranty, including downloading other users' invoices, manuals, and photos. That is intentional for family and team instances — but only enable it when you actually want that sharing. If only admins should see everything, use Global View Admin Only instead. Claim documents and "other documents" are never shared through the global view, even when it is on. See Authentication.

Keep a second admin, and back up

A second admin account is your recovery path if the first admin is locked out (password reset needs working SMTP — see FAQ). And back up regularly: a backup is what turns a compromised or broken instance from a disaster into an afternoon. See Backup and Restore.

What Warracker already does

• Login tokens expire after 24 hours; sessions time out after 1 hour of inactivity.
• Uploaded files are never served publicly — every file download checks that you are logged in and allowed to see that file (owner or admin, plus global-view rules for shared document types).
• Database queries are parameterized throughout, and user input is escaped in the interface, so the usual injection and scripting paths are closed.
• The About page checks GitHub for newer releases — that is the app's only outbound call; your warranty data never leaves your server.

Reporting a vulnerability

If you find a security issue, do not open a public issue. Use GitHub's private vulnerability reporting on the repository so it can be fixed before details are public. Past advisories are published on the repository's Security tab, and reporters are credited in the release notes.