Module-Rust/SECURITY.md

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-Rust (this repo)	RunicGateway/Module-Rust	No listener of its own — runs inside the website process
rust-link sidecar	RunicGateway/Rust-Link	The only network-facing part of the game bridge
Oxide bridge plugin	RunicGateway/Rust-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 game server 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 game state is this module's own visibility layer. A module route that reaches game data without going through those is a security bug worth reporting.
• This module handles every server's sidecar auth token. Each 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.