# Security Policy

Thank you for helping keep Runic Gateway and its users safe.

## Reporting a vulnerability

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

Instead, report privately by email to:

**whitlocktech@gmail.com**

Please include as much of the following as you can:

- The repository and component affected.
- The type of issue (e.g. authentication bypass, injection, secret exposure,
  remote code execution, denial of service).
- Step-by-step instructions to reproduce, and a proof-of-concept if you have one.
- The impact — what an attacker could do with it.
- Any suggested remediation.

You will receive an acknowledgement of your report, typically within a few days. We
will keep you informed as we investigate and work toward a fix, and we are happy to
credit you in the release notes once the issue is resolved (let us know if you would
prefer to remain anonymous).

## What this repo is, for scoping purposes

This repo is **documentation plus a template module**. It runs nothing, listens on
nothing, and stores no data. Two kinds of report are still in scope here, and both
are worth sending:

- **The template teaches an insecure pattern.** It is meant to be copied, so a
  weakness in it propagates into every module written from it — an unparameterised
  query, a route missing an authorisation check, a secret handled in the clear, a
  permissive CORS or CSP suggestion. Treat the template as production code that has
  not been deployed yet.
- **A chapter teaches something dangerous.** Advice that would lead a reader to
  expose their game server to the internet, hold a secret unencrypted, bypass core's
  authorisation middleware, or weaken session handling is a security issue in this
  repo even though no code here does it.

A defect in core, a module or the sidecar itself belongs to that repo:
[`website`](https://gitea.whitlocktech.com/RunicGateway/website),
[`Module-uo`](https://gitea.whitlocktech.com/RunicGateway/Module-uo),
[`link`](https://gitea.whitlocktech.com/RunicGateway/link).

## Three things that are policy, not oversight

A module author reading this kit should know these up front, because they shape what
counts as a vulnerability anywhere in this project:

- **The module boundary is not a security boundary.** A module runs in the same Node
  process as core, with the same privileges, against the same database. It is a
  code-organisation and distribution boundary. Installing a module is the same trust
  decision as installing the site — which is why installation is admin-only. "A
  module could reach core's internals" is not a vulnerability report; "an
  unprivileged user can install or enable a module" very much is.
- **Access control lives in core.** Route protection is core's middleware, and what
  a visitor may see of live game state is the website's admin-toggleable visibility
  framework. A module route that reaches game data without going through those is a
  security bug. A sidecar that makes its own access-control decisions is a design
  error — it is a forwarder.
- **The website process never connects to a game server.** The game is not
  network-reachable; it dials out to a sidecar, and only the website's backend talks
  to that sidecar. This is a rule in the module contract
  ([`MODULE_API.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/MODULE_API.md)
  §2.7), and a chapter or template that leads someone to break it is the kind of
  report this repo most wants.

## Supported versions

This project is developed continuously and does not maintain long-term release
branches. Fixes land on `main`; please read a recent copy.