# Security Policy

## Reporting a vulnerability

**Please do not put vulnerability details in a public issue.**

This project has no private disclosure channel yet. Until it does, open an
issue on the repository that says only that you have a security report — no
reproduction steps, no affected endpoint, no payload — and a maintainer will
reply with a private contact to send the details to.

That is a deliberately awkward first step, and it exists because the
alternative is worse: an issue tracker is public the moment it is written to,
and every self-hosted instance stays vulnerable until its operator has had a
chance to update.

Please include, once you have a private channel:

- what an attacker can do, and what access they need to start
- the version or commit you tested
- reproduction steps

## Scope — what this software actually handles

FabledCurator is self-hosted and holds things worth stating plainly, because
they shape what counts as a serious bug here:

- **Platform credentials.** The app captures and stores session cookies for
  third-party subscription sites (Patreon, SubscribeStar, Pixiv) so it can
  download on the operator's behalf. These are live credentials for accounts
  that usually carry a payment method. Anything that discloses them, decrypts
  them, or lets one user of a shared instance read another's is high severity.
- **An extension API key.** The Firefox extension authenticates to the backend
  with a shared key. Anything that leaks it or lets it be bypassed is a way in.
- **A multi-user sharing ACL.** Instances can be shared. A bug that lets one
  account see content another has not shared is an access-control failure, not
  a cosmetic one.
- **Arbitrary media from the internet.** Downloaded files are decoded, hashed,
  thumbnailed and fed to ML models. Anything that turns a hostile file into
  code execution is in scope.

## Deployment posture — read this before reporting

FabledCurator is designed to run **inside a private network, over plain HTTP**.
It does not terminate TLS, redirect to HTTPS, or set HSTS; if you want
transport security, terminate it at your reverse proxy. This is a documented
design decision, not an oversight.

Reports that reduce to "the application is served over HTTP" or "there is no
HSTS header" describe that decision rather than a vulnerability. Reports that
an authenticated operator can cause the software to do something destructive
are usually also by design — the operator is the administrator of their own
instance.

What remains in scope is everything that crosses a boundary the software is
supposed to hold: between one user and another, between an unauthenticated
visitor and any of it, and between untrusted downloaded content and the host.

## Supported versions

Fixes land on the `main` branch and reach the `:latest` image. There are no
maintained release branches — the supported version is the current one, and
the remedy for a security issue is to update.