Skip to content

fix: telemetry-ingest edge function uses service role key instead of anon key#750

Open
Gonzih wants to merge 1 commit intogarrytan:mainfrom
Gonzih:fix/telemetry-ingest-anon-key
Open

fix: telemetry-ingest edge function uses service role key instead of anon key#750
Gonzih wants to merge 1 commit intogarrytan:mainfrom
Gonzih:fix/telemetry-ingest-anon-key

Conversation

@Gonzih
Copy link
Copy Markdown

@Gonzih Gonzih commented Apr 1, 2026

The Problem

`supabase/functions/telemetry-ingest/index.ts` uses `SUPABASE_SERVICE_ROLE_KEY`:

```typescript
const supabase = createClient(
Deno.env.get("SUPABASE_URL") ?? "",
Deno.env.get("SUPABASE_SERVICE_ROLE_KEY") ?? "" // ← wrong
);
```

The service role key bypasses all Row Level Security and has full unrestricted database access including admin operations. This is a public-facing edge function called by every gstack user for telemetry. Using the service role here means any exploit in the JSON parsing or validation logic has full database access as a blast radius.

Issue #675.

The Fix

Use `SUPABASE_ANON_KEY` instead. The RLS INSERT policies for the `anon` role are already in place (`001_telemetry.sql` + `002_tighten_rls.sql`). Anon can INSERT into `telemetry_events` and `installations` — that's all this function needs.

The service role key should never be on the network path to user-facing endpoints.


sent from mStack

The service role key bypasses Row Level Security entirely and grants
unrestricted access to all Supabase tables and admin operations.
Using it in a public-facing edge function called by all gstack users
is a significant unnecessary privilege escalation.

The anon key with INSERT-only RLS policies is the correct approach:
- telemetry_events: anon can INSERT (migration 001/002)
- installations: anon can INSERT (migration 001/002)
- No SELECT, UPDATE, DELETE for anon
- The service role key should never touch the public network path

RLS INSERT policies are already in place (migration 001_telemetry.sql
+ 002_tighten_rls.sql). Switching to SUPABASE_ANON_KEY is safe.

Closes garrytan#675
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant