FabledCurator/SECURITY.md

# 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) 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.
- **No authentication of its own.** This is the most important thing on this
  page. FabledCurator has no login, no user accounts and no permission model —
  there is no `User` table and no session auth anywhere in the backend. Every
  HTTP client that can reach the port is the administrator, with full read and
  write access to everything above, including the stored platform credentials.
  Access control is entirely the operator's job, done at the network layer.
  Reports that an unauthenticated caller can reach an endpoint are therefore
  describing the design; reports that something *crosses the network boundary
  the operator drew* — an SSRF, a request forgery that rides a browser the
  operator already has open, a path that leaks state to an origin the operator
  did not authorise — are in scope and are serious.
- **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,
reachable only by its operator**. It does not terminate TLS, redirect to
HTTPS, or set HSTS; if you want transport security, terminate it at your
reverse proxy. It also does not authenticate anyone — see above. These are
documented design decisions, not oversights.

Putting this on the public internet, with or without TLS, hands whoever finds
it your Patreon and SubscribeStar sessions. A reverse proxy that adds
TLS but not an authentication layer does not change that.

Reports that reduce to "the application is served over HTTP", "there is no
HSTS header", or "the API needs no credentials" describe those decisions
rather than vulnerabilities. Reports that the 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
actually supposed to hold: between untrusted downloaded content and the host,
between a third-party origin and an operator's open browser session, and
between the credentials at rest and anything that is not the operator.

## 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.