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

## Scope

Runic Gateway is a self-hosted platform made up of several components:

| Component | Repo | Network exposure |
|---|---|---|
| Website core (site + admin + API) | `RunicGateway/website` | Internet-facing (behind a reverse proxy) |
| **module-uo** (this repo) | `RunicGateway/Module-uo` | No listener of its own — runs inside the website process |
| uo-link sidecar | `RunicGateway/link` | The only network-facing part of the game bridge |
| ServUO plugin | `RunicGateway/servuo-plugins` | Loopback only — dials the sidecar on `127.0.0.1` |
| Installer | `RunicGateway/installer` | Not a service — an operator-run deployment tool |
| Documentation | `RunicGateway/docs` | Content only |

Because instances are self-hosted, the security of any given deployment also
depends on how it is configured and operated — strong secrets (`JWT_SECRET`,
`SECRET_ENC_KEY`, database and admin passwords), a correctly configured reverse
proxy and `TRUST_PROXY`, and keeping the shard itself unreachable from the
internet (only the sidecar should be exposed). See each repo's README for the
security model.

### Module-specific notes

Three things follow from what a module *is*, and they are policy rather than
oversight:

- **The module boundary is not a security boundary.** A module runs in the same
  Node process as core with the same privileges, and its schema fragment runs
  against the same database. It is a code-organisation and distribution boundary.
  Installing a module is the same trust decision as installing the site itself —
  which is appropriate for a self-hosted operator choosing their own software, and
  is why module installation is admin-only. "A module can reach core internals" is
  therefore not a vulnerability report; "an unprivileged user can install or
  enable a module" very much is.
- **Access control lives in core, not in the module and never in the sidecar.**
  Route protection is core's `requireAuth` / `requireRole` middleware, and what a
  visitor is allowed to see of live shard state is the website's admin-toggleable
  visibility framework. A module route that reaches shard data without going
  through those is a security bug worth reporting.
- **This module handles the uo-link auth token.** It is encrypted at rest with
  core's `secretBox` and is **write-only** in the API — never returned to any
  client, in any shape. Anything that would echo it back, log it, or expose it to
  the browser is a security issue.

## Supported versions

This project is developed continuously and does not maintain long-term release
branches. Security fixes land on `main`; please run a recent build.