Gamecave Bot
Log in Get started

Trust & Security

Security you can explain

How Gamecave protects customers day to day: ownership isolation, guild-bound channel and role ids, secrets that stay off the glass, encryption at rest, CSRF and browser headers — plus a hardened public edge (CDN, TLS, origin firewall) without publishing an attack map.

Platform · Trust

What protects your dashboard

A short walkthrough of how Gamecave handles ownership, secrets, writes, and the public edge. Illustrative mock — not a live session.

Why we built it this way

Public write-ups about Discord bots and dashboards keep repeating the same classes of failure: incomplete ownership checks on API writes, channel ids that let a bot post in another server, secrets that come back in responses or error logs, login return links that leave the site, forgotten internal tools with live credentials, and plan rules enforced only in the browser. Gamecave is shaped around those patterns — and this page only claims what the product actually does today. No product is immune to every future attack.

What you get in Gamecave today

  • Ownership isolation plus Manage Server checks. Each server configuration is stored under the Discord account that saved it. Dashboard reads stay on that owner’s rows. Saves, Pro-slot changes, whitelist key rotation, and bot jobs require that same account and that you still own the Discord or can Manage Server (or Administrator) there — knowing a guild id alone is not enough.
  • Guild-bound channels and roles. When you save, channel and role ids are checked against this Discord (when the bot can see the server). The bot also refuses to post or act in a channel that belongs to a different server — so a pasted id from elsewhere does not become a cross-server message path.
  • Custom bot tokens stay off the glass. Paste a Discord bot token once to connect or replace it. The dashboard API returns only whether a token is saved (connected / not connected) — never the secret itself. Shared platform credentials stay on the host, not in the browser. (Whitelist bridge keys are different: the owner can view or rotate them in the dashboard so game scripts can be configured.)
  • Secrets encrypted at rest. Custom bot tokens and whitelist bridge keys are stored encrypted in the database (AES-GCM with a host key). Custom bot tokens are decrypted for the bot process; bridge keys for the owning dashboard (copy/rotate) or a header-authenticated game bridge.
  • Private data is not website content. On Apache (production), data/, includes/, bot/, and related trees are blocked from HTTP. Local PHP built-in server must use the shipped router.php — bare static servers can leak files; we document that so operators do not ship secrets that way.
  • Separate secrets for separate jobs. The bot process and the website authenticate with a dedicated shared secret, separate from Discord OAuth. Game whitelist scripts use their own per-server bridge key — they never need your Discord bot token. Bridge material is not included in ordinary bot config responses.
  • Bridge keys require a header. Official game scripts send the server key as X-GameCave-Bridge-Token so it does not sit in a shareable page URL (where it is easier to copy into logs or history). Query-string ?token= is rejected.
  • CSRF on state-changing dashboard calls. POSTs that change settings require a session-bound CSRF token — SameSite cookies alone are not treated as enough.
  • Browser security headers. Responses ship a Content-Security-Policy, X-Frame-Options, referrer policy, nosniff, and related baselines. Strict-Transport-Security (HSTS) is set when the site is served over HTTPS.
  • Plan limits enforced on the server. Ticket categories, creator slots, Pro-only features, and reaction-role mappings are capped when you save. Pro-gated and plan-gated bot jobs (whitelist sync, creators, reaction-role posts, voice hub) are checked again when queued — not only by greying out buttons.
  • Reaction roles and security actions respect Discord hierarchy. The bot will not assign or remove a role above its own highest role, skips managed roles Discord owns, and skips kick/ban/timeout when Discord hierarchy says the member is not moderatable.
  • Rate limits on busy edges. Login, creator search, bot job calls, and whitelist bridge traffic are throttled so noisy requests are harder to abuse.
  • Sign-in that never asks for your Discord password. You authenticate with Discord OAuth. Login uses a one-time state check, the session id is rotated after a successful login, post-login return paths stay on this site, and session cookies are HttpOnly with SameSite protection (Secure when the site is served over HTTPS).
  • Durable SQLite with a backup path. The database runs in WAL mode for reliable concurrent use. A simple backup script ships with the product so you can keep a schedule you control.
  • Public edge and a filtered origin. The live site is served over HTTPS through a CDN edge (Cloudflare). The origin host uses a firewall that only admits the traffic needed for the website. Edge filtering helps absorb common volume abuse; it is not a promise that every attack fails. We intentionally do not publish port lists, firewall rule dumps, or hosting internals here.
  • Status you can check. A public status page shows whether the website API and Discord bot heartbeat look healthy — without exposing infrastructure detail.

Hosting & the public edge

Gamecave’s marketing site and dashboard run on our own managed host, with Cloudflare in front for TLS termination at the edge, caching of public assets where appropriate, and baseline abuse filtering. The origin is locked down so only expected web traffic reaches the application. Admin and operator access stay separate from the public product surface.

We describe outcomes (HTTPS, filtered origin, ownership checks) — not a blueprint of how to probe the network. If you need operational detail as a customer (for example after an incident), contact us through Support Discord.

How access works

You sign in with Discord OAuth only — we never see your Discord password. Your guild settings belong to the account that saved them, and changing them also requires Discord manage rights on that server. The bot and the website talk with a server-side secret, not your browser session. Game bridges use a key made for that server alone (header X-GameCave-Bridge-Token), so a whitelist script never needs your Discord bot token.

Discord-side Security MVP

Join-flood, anti-spam, banned words, and escalation on a slot are a separate product feature — shown on the homepage and Features. This page is about how Gamecave protects your dashboard, credentials, and bridges.

Your part of the partnership

Keep your Discord account secure, and treat bot tokens and bridge keys like passwords — do not share them in public channels or screenshots. When you connect a custom bot or rotate secrets, do it from Discord’s developer portal and your Gamecave dashboard. If you run your own host, keep the bot process supervised and backups on a schedule you trust.

Contact

Questions about trust or security: the Discord account linked on your Gamecave dashboard, or Support Discord (link in the header or footer).