MIS-Contro-Tower/security_risks.md

Security Risks Review (mis-control-tower)

This review focuses on the risks highlighted in the tweet you shared: backend-first architecture, trusting the client, column/role escalation, and missing rate limits.

Good news: this project is backend-first and uses Prisma on the server, not direct-to-DB from the client. Prisma itself is not the core risk here. The main issues are around authorization scope, secret handling, and rate limiting.

Critical: Cross-org reminder trigger + weak auth fallback

What can go wrong

Any logged-in user can trigger the reminders job if the secret is not set, and the job queries across all orgs. This can spam email reminders to users in other orgs.

Source

• Auth fallback to "any session" when secret missing: app/api/downtime/actions/reminders/route.ts:40
• Cross-org query (no orgId filter): app/api/downtime/actions/reminders/route.ts:62

Why this maps to the tweet

This is a classic "missing backend guardrails" and "rate limits/abuse" problem.

Fix ideas

• Require DOWNTIME_ACTION_REMINDER_SECRET in all environments (fail closed if missing).
• If you want session-based access, also require:
  • role check (OWNER/ADMIN), and
  • explicit orgId scoping in the findMany query.
• Consider also logging who triggered it.

---

High: Invite token exposure + invite claim risk

What can go wrong

A regular member can retrieve active invite tokens and then accept invites intended for other people.

Source

• Members GET has no role check: app/api/org/members/route.ts:23
• Members GET returns raw invite tokens: app/api/org/members/route.ts:52
• Accepting an invite creates a user for the invite email and marks it verified based only on the token: app/api/invites/[token]/route.ts:93, app/api/invites/[token]/route.ts:98

Why this maps to the tweet

This is a "hidden columns / privilege escalation" flavor of bug: sensitive fields (tokens) are being exposed to users who should not see them.

Fix ideas

• Add a role check to GET /api/org/members (OWNER/ADMIN only).
• Do not return invite tokens from the API (or only return to OWNER/ADMIN).
• Optional hardening:
  • Bind invites more tightly to identity (e.g., require proof of email ownership), or
  • require the invite acceptance flow to complete a verification step before granting access.

---

Medium: Pairing code brute force path to machine API keys

What can go wrong

Pairing codes are short and the pairing endpoint returns the machine API key. Without rate limiting, attackers can attempt many codes and occasionally succeed.

Source

• Pairing codes length = 5: lib/pairingCode.ts:5
• Pair endpoint returns apiKey: app/api/machines/pair/route.ts:56

Why this maps to the tweet

This aligns with "rate limits are not optional anymore" and "don’t trust defaults."

Fix ideas

• Add rate limiting to /api/machines/pair (by IP and/or code prefix).
• Increase pairing code entropy (length and/or attempt tracking).
• Track failed attempts and temporarily disable pairing for a machine after too many failures.

---

Medium: Missing rate limiting on high-abuse endpoints

What can go wrong

Attackers can brute-force or abuse endpoints to consume resources and/or trigger unwanted actions.

Source (representative endpoints)

• Login: app/api/login/route.ts:20
• Signup: app/api/signup/route.ts:26
• Pairing: app/api/machines/pair/route.ts:12
• Ingest: app/api/ingest/kpi/route.ts:35, app/api/ingest/heartbeat/route.ts:33, app/api/ingest/event/route.ts:60, app/api/ingest/reason/route.ts:11

Why this maps to the tweet

This is directly item #10 in the tweet: rate limits at auth, API routes, and webhooks/ingest.

Fix ideas

• Apply rate limiting to:
  • auth endpoints (/api/login, /api/signup, invite acceptance),
  • pairing (/api/machines/pair),
  • ingest endpoints (especially if publicly reachable).
• Even a simple KV-based limiter or middleware-based limiter is a large improvement.

---

Not the core risk: Prisma usage

Observation

This project uses Prisma server-side via Next.js route handlers and server components. I did not see direct DB calls from the browser.

Source (representative)

• Session enforcement in API routes: lib/auth/requireSession.ts:42
• Server-side data access in routes: app/api/machines/route.ts:31, app/api/settings/route.ts:146

Why this matters

This avoids the tweet’s main direct-to-DB + RLS pitfalls, but you still need strong authorization and rate limiting in your own backend.

---

Quick fix priority order

1. Lock down POST /api/downtime/actions/reminders (fail closed + org scoping).
2. Lock down GET /api/org/members and stop exposing invite tokens.
3. Add rate limiting to pairing and auth endpoints.
4. Consider increasing pairing code entropy + attempt tracking.

If you want, I can implement the first two fixes in small, safe patches.