# Security Policy

Uchiyomi holds accounts, sessions and API tokens for everyone in a household, so a bug here can expose more
than a broken page. Reports are welcome and taken seriously.

## Reporting a vulnerability

**Please do not open a public issue for a security bug.**

Use GitHub's private reporting instead: **[Report a vulnerability](https://github.com/AngeloSha/uchiyomi/security/advisories/new)**.
It is private between you and the maintainer until a fix ships.

Helpful things to include, roughly in order of usefulness:

- what an attacker gains, stated plainly (read another user's library, escalate to admin, read files off the host)
- the smallest set of steps that reproduces it, ideally against a fresh `deploy/docker-compose.yml` install
- the version — `docker inspect ghcr.io/angelosha/uchiyomi:latest` or the tag you pulled
- whether it needs an existing account, and at what permission level

You will get a first reply within **72 hours**. If a report is valid, expect a fix in the next release; if the
issue is being actively exploited or needs no account at all, expect an out-of-band patch release instead.

You are credited in the release notes and the advisory unless you would rather not be.

## Supported versions

This is a young project with a single maintainer. Fixes land on **the latest release only** — there are no
backports to older tags. Running `:latest`, or watching releases and updating, is the supported posture.

## Scope

**In scope** — anything in this repository:

- authentication and session handling (argon2id hashing, JWT access tokens, rotating refresh cookies, login
  lockout, TOTP enrolment and verification)
- authorisation: one user reaching another user's data, or a non-admin reaching `/api/admin/*`
- API token scoping (`read` / `write` / `admin`) failing to restrict what it claims to
- OIDC/SSO login: assertion handling, account linking, admin-group mapping
- the image proxy and `/img/*` cookie authorisation
- SSRF, path traversal or command injection via a user-supplied source URL, an uploaded backup, or a library file
- anything that lets a page in a CBZ or a response from a source site run script in the app's origin

**Out of scope:**

- vulnerabilities in the third-party sites you point Uchiyomi at, or in extensions you install — Uchiyomi
  ships no sources and no default extension repository; what you add is yours to vet
- Suwayomi, FlareSolverr, Postgres and other upstream images — report those to their projects, though do tell
  us if Uchiyomi's default configuration of one of them is what creates the risk
- an instance the operator has deliberately exposed to the internet without HTTPS or a reverse proxy
- missing hardening headers on a deployment where a proxy in front is stripping them
- reports generated by a scanner with no demonstrated impact

## What Uchiyomi already does

Useful context so you can aim at the gaps rather than the parts that are covered:

- passwords are hashed with **argon2id**; access tokens are short-lived JWTs and refresh cookies rotate on use
- **TOTP two-factor** is available per account, with an audit log and session/device management
- the database publishes **no host port**, and your existing library is mounted **read-only**
- API tokens are **scoped** and can only ever restrict — an `admin`-scoped token on a non-admin account still
  cannot reach the admin API
- first run has no default credentials: the admin account is created interactively