Security and privacy

This page describes implemented mechanisms and operator responsibilities at the documented revision. It is not a security certification or a penetration-test result.

Accounts and sessions

Local passwords use Argon2 hashing. Access tokens are signed with the server's TCG_SECRET_KEY; keep it private and at least 32 random characters. Refresh tokens are opaque, stored as SHA-256 hashes, rotated and grouped into session families. Reuse detection outside the concurrency grace period revokes a family.

Authenticated requests check the user, disabled state, authentication version and live session family. Local password changes/resets and disabling accounts end previous sessions. Default token lifetimes are configurable.

Web cookies are HttpOnly and normally Secure with SameSite protections. Cookie-authenticated writes additionally require X-TCG-CSRF: 1. The production web client handles this; third-party cookie clients must do so explicitly.

Authentication limits

Defaults allow 10 failed password attempts per account and 50 per client address in a 900-second window; refresh/SSO request limits default to 60 per address/minute. Setting a limit to zero disables that limiter. Counters are in-process and reset on restart; they are not a distributed brute-force protection service.

Correct forwarded-header trust is essential for real client-address accounting. Trust only the intended reverse proxy network path.

OIDC

Authorization code + PKCE and signed ID-token validation protect the implemented SSO paths. Asymmetric algorithms only are accepted. Accounts use issuer/subject identity, never email auto-linking. Group allowlists and admin mappings are configured per provider.

Data boundaries

Each user accesses their own collection through the normal collection API. Catalog sources, images and arbitrations are shared. Administrators manage server users/jobs; host/database operators can technically read stored data. Backups require the same privacy controls as the running database.

Android stores session tokens and preferences in app-private DataStore. The reviewed code does not add a separate encrypted token-vault layer. Application backup is disabled, including extraction rules. Device security still matters.

Scanning and external data

OCR executes on the phone; recognized text and coordinates go to the Zukan server. The scan identification endpoint does not receive raw photos. The backend can contact external catalogs during missing-card lookup and can download images or metadata from configured sources. This is not a claim that no network communication leaves the server.

HTTP hardening

The backend adds anti-framing, content-type-sniffing and same-origin referrer headers. SVG icon responses use a restrictive content security policy. Request-body size limits apply before parsing, and CSV has its own smaller upload limit and spreadsheet-formula escaping.

HTTPS, certificate management, host access control and database network isolation remain deployment concerns. Do not expose PostgreSQL or image-import directories publicly.

Reporting problems

The repository includes an earlier security-audit document. Its historical findings must be evaluated against current code; neither that file nor this wiki proves all findings are resolved. For a suspected vulnerability, send a minimal redacted reproduction through the maintainer's appropriate private reporting channel if available. Do not post live tokens or exploitable production secrets in a public issue.

Implementation references

• backend/app/core/security.py
• backend/app/api/deps.py
• backend/app/core/middleware.py
• android/app/src/main/AndroidManifest.xml