Discord bot tokens and OAuth client secrets are stored in plaintext Firestore fields (no app-level encryption) #261

New Issue

2026-10-05T02:54:08-04:00

logan commented

2026-10-05 02:54:08 -04:00

Found while building #225 S6 (PR #260). Not fixed there.

What: Radio-bot Discord tokens (bot_tokens/{id}.token) and, from S6 on, each bot's OAuth2 client secret (bot_oauth/{id}.client_secret) are plain strings in Firestore documents. The only protections are:

Google's own at-rest encryption, and
the Firestore rules that deny client reads.

The codebase has no application-level encryption pattern (no Fernet, KMS or envelope key), so S6 deliberately did not invent one.

Why it matters now:

#161: the rules deploy job has failed on every run, so whether the deny rules are live in prod is unverified.
If they are not live, any signed-in user could read every bot token. Today that is the whole pool of radio bots, and after S6 the OAuth secrets too.

What to do:

First, the plan's rollout check. With a non-admin ID token, read bot_tokens and bot_oauth, and expect PERMISSION_DENIED.
Then decide whether to encrypt these two fields with a key held outside Firestore (env or Secret Manager). That would be a new pattern: c2-core decrypts on read in discord_rest / discord_oauth / routers/discord.py node_token.

Doesn't taint: nothing measured. This is a secret-storage hardening item, not a behaviour bug.

Found while building #225 S6 (PR #260). Not fixed there. **What:** Radio-bot Discord tokens (`bot_tokens/{id}.token`) and, from S6 on, each bot's OAuth2 client secret (`bot_oauth/{id}.client_secret`) are plain strings in Firestore documents. The only protections are: - Google's own at-rest encryption, and - the Firestore rules that deny client reads. The codebase has no application-level encryption pattern (no Fernet, KMS or envelope key), so S6 deliberately did not invent one. **Why it matters now:** - #161: the rules deploy job has failed on every run, so whether the deny rules are live in prod is unverified. - If they are not live, any signed-in user could read every bot token. Today that is the whole pool of radio bots, and after S6 the OAuth secrets too. **What to do:** 1. First, the plan's rollout check. With a non-admin ID token, read `bot_tokens` and `bot_oauth`, and expect PERMISSION_DENIED. 2. Then decide whether to encrypt these two fields with a key held outside Firestore (env or Secret Manager). That would be a new pattern: c2-core decrypts on read in `discord_rest` / `discord_oauth` / `routers/discord.py` `node_token`. **Doesn't taint:** nothing measured. This is a secret-storage hardening item, not a behaviour bug.

logan referenced this issue

2026-10-05 02:54:13 -04:00

Discord: customers shouldn't need the main DRB bot in their server — radio bots (via C2) should cover linking, channel directory and permission checks #225

logan referenced this issue

2026-10-05 03:25:59 -04:00

Discord: org owners can't register their own (BYO) radio bot or its OAuth secret — platform-admin only #273

logan referenced this issue

2026-10-05 03:31:21 -04:00

Discord: customers shouldn't need the main DRB bot in their server — radio bots (via C2) should cover linking, channel directory and permission checks #225

Sign in to join this conversation.