# Security Policy

**Please do not report security vulnerabilities through public issues, pull requests or the wiki.**
A public report tips off attackers before a fix is available.

Report privately, using the contact route in the organisation's security policy:

**[RunicGateway/docs → SECURITY.md](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/SECURITY.md)**

That document is the single copy for all ten repositories, and it carries the address, what to
include in a report and what to expect back.

## Why this file is a pointer rather than a copy

Every other repository in the organisation states the reporting address inline. This one does not,
and the reason is a decision of record rather than an oversight: **D13** (`PLAN.md` §5) confines the
published contact address to `brand.json`, a bind-mounted file, so that changing it is a file copy
and a container restart rather than a commit. `scripts/checkFacts.mjs` fails the build if an address
appears anywhere in `src/` or `scripts/`, and this file honours the same rule voluntarily — a
hard-coded address in the repository root would be one more place to forget when the address moves.

## What is worth reporting here

This site holds one thing of value and has one writing endpoint.

- **The closed-beta signup** (`/beta`, `PLAN.md` §8) is the only route that writes. It stores an
  email address, a consent record and a **salted hash of the IP address** — never the address
  itself. Anything that lets a caller read rows, bypass the rate limit or the total cap, forge the
  signed form token, or recover an IP from a hash is in scope and worth reporting.
- **The branding mount** (`GET /brand/*`, §7) reads files from a directory an operator controls.
  Path traversal out of that directory, or reaching a file type outside the route's allowlist, is in
  scope.
- **The Content-Security-Policy** is a real response header written by `scripts/serve.mjs`. A page
  that is served no policy, or another page's policy, is a defect worth reporting — that exact bug
  has happened here once already (`PLAN.md` D48).

The site has **no authenticated surface at all**, by design: the tester list is managed from a shell
against the bind mount, not from an admin page. There is no session, no cookie and no login to
attack.

Vulnerabilities in the **platform itself** — the website, the sidecar, the shard plugin, the
installer or the Android app — belong in the organisation's policy linked above, not here. This
repository only describes them.