Ops & Security

Fang mit der mentalen Regel an, die nie versagt: Alles, was in eine statische Seite kompiliert wird, ist öffentlich. MOONKEY LAB ist Astro 4 im SSG-Modus — der Build erzeugt plain HTML+JS, das von Cloudflare Pages ausgeliefert wird. Es gibt keinen Server, der zur Laufzeit Secrets hütet. Jeder String, den du in eine .astro-Komponente importierst und der beim Client ankommt, landet buchstäblich in einer Datei, die jeder mit `view-source` oder über DevTools → Sources herunterlädt. Genau deshalb enthält `src/lib/supabase.ts` AUSSCHLIESSLICH den anon key. Der anon key ist dafür GEMACHT, öffentlich zu sein: Er ist eine Projekt-Kennung plus ein Token mit den Rechten der Rolle `anon`, dessen tatsächliche Autorität Postgres RLS begrenzt. Er ist kein Secret; er ist eine Adresse mit einem Türsteher.

Jetzt der Kontrast, den du verinnerlichen musst. Es gibt zwei Supabase-Schlüssel mit identischem Aussehen (ein langer JWT), aber mit gegensätzlichen Macht-Universen. Der `anon` key arbeitet unter der Rolle `anon`/`authenticated` und ist RLS UNTERWORFEN: Er sieht nur, was die Policies erlauben. Der `service_role` key arbeitet mit `BYPASSRLS`: Er ignoriert alle Policies, liest und schreibt jede Zeile jeder Tabelle — einschliesslich der von XHUB IRON (`iron_*`, `world_*`), die sich dieselbe Instanz `wuchsslgbqlhyxljsmxi` teilen. Taucht der `service_role` im Client auf, kompromittiert ein Angreifer nicht nur MOONKEY: Er pivotiert auf alle Projekte, die in dieser DB leben. Harte Regel: Der `service_role` kommt NIEMALS in ein Frontend-Repo, nicht in ein `.astro`, nicht in ein `import.meta.env.PUBLIC_*`. Sein Platz ist ein Backend mit Session (eine Edge Function, ein Server-Prozess) oder dein lokaler Schlüsselbund — niemals das Bundle.

Der häufigste Leck-Vektor ist nicht, den Schlüssel in den Code zu kleben: Es ist das Präfix der Environment-Variable. In Astro wird `import.meta.env.PUBLIC_X` zur Build-Zeit ins Client-Bundle INLINED; `import.meta.env.X` (ohne `PUBLIC_`) existiert nur im Server-/Build-Kontext und wird NICHT exponiert. Vite/Astro machen das mit Absicht. Der klassische Fehler: `PUBLIC_SUPABASE_SERVICE_KEY` benennen, 'damit die Komponente ihn sieht'. Das erreichst du — und schenkst ihn der ganzen Welt. Dein Entscheidungsbaum zum Benennen einer Env-Var: Darf dieser Schlüssel öffentlich sein? Ja → `PUBLIC_`. Nein → kein Präfix, und frag dich obendrein, was er in einem SSG-Projekt überhaupt verloren hat (wahrscheinlich gehört er gar nicht dorthin).

Bau das Inventar. Öffne dein Projekt und klassifiziere jedes Credential in einer Tabelle mit drei Spalten: Name · Klasse (öffentlich/privat) · wo es heute lebt. In MOONKEY sind die echten Einträge: `PUBLIC_SUPABASE_URL` (öffentlich, Kennung), `PUBLIC_SUPABASE_ANON_KEY` (öffentlich, durch RLS begrenzt) und der `service_role` (privat — sollte in diesem Repo schlicht GAR NICHT existieren; brauchst du ihn für ein Migrations-Skript, lebt er in deiner lokalen Shell oder in einem CI-Secret, niemals in `src/`). Ergänze jedes Drittanbieter-Token, das du anfasst: Schlüssel für transaktionale E-Mails, Webhooks, server-seitige Analytics-Tokens. Jede private Zeile, die auf der falschen Seite steht, ist ein Vorfall, der nur auf seinen Auftritt wartet.

Die Kontrolle, die den Kreis schliesst, ist die automatische Erkennung — denn menschliche Disziplin versagt. Vor jedem Commit willst du, dass etwas aufschreit, wenn sich ein privater Schlüssel einschleicht. Das Minimal-Muster: ein grep im pre-commit, der nach dem Muster eines `service_role` sucht (Supabase-Service-JWTs tragen `"role":"service_role"` im base64-Payload) und nach Wörtern wie `service_role`, `BEGIN PRIVATE KEY`, `sk-`. Für echte Repos nimm `gitleaks` oder `trufflehog` als Hook. Und falls ein Schlüssel BEREITS in einem vergangenen Commit geleakt ist: Ihn aus dem Code zu löschen reicht nicht — er steckt weiter in der Git-History. Du musst ihn im Supabase-Panel ROTIEREN (Settings → API → roll key) und die History umschreiben, falls es ein hartes Secret war. Rotieren ist Pflicht; die Datei zu löschen widerruft gar nichts.

Schliess mit dem Fall Espejo, der eine ethische Achse hinzufügt, nicht nur eine technische. Espejo ist multi-tenant: Jeder Influencer-Tenant hat seine eigenen Daten. Hier verdoppelt sich die Frage 'öffentlich vs. privat': Neben Infrastruktur-Schlüsseln verwaltest du personenbezogene/einwilligte Daten von Endnutzern. Der Service-Schlüssel, der ACROSS Tenants lesen könnte, ist das sensibelste Secret des Produkts — sein Leck ist nicht nur technisch, es verletzt die Datengrenze, die das Projektgedächtnis als nicht verhandelbar markiert. Querschnitts-Lektion: Ein privates Credential definiert sich nicht über sein Format, sondern über das, was es entsperrt. Miss es immer an seinem blast radius.

Nimm den richtigen mentalen Rahmen an: In einer SSG ist der Client nicht deine Anwendung, er ist Feindesland. Der Angreifer hat dein komplettes Bundle (es ist öffentlich), deine `PUBLIC_SUPABASE_URL`, deinen anon key und das Wissen, dass dahinter Postgres steckt. Er muss dein JavaScript nicht 'hacken': Er liest es. Er kann seinen eigenen Supabase-Client mit DEINEM anon key aus einer Node-Konsole instanziieren und direkt mit deiner DB sprechen, ohne je durch dein HTML zu gehen. Also ist jede Sicherheitslogik, die in `.astro` oder im Client-JS lebt — ein `if (user.role === 'admin')`, eine Komponente, die sich versteckt — UX, nicht Security. Das CLAUDE.md von MOONKEY sagt es wörtlich: `admin.astro` ist UX; die Sicherheit hängt NICHT von diesem Gate ab.

Zähl die konkrete Angriffsfläche auf. Für MOONKEY gibt es fünf mit dem anon key erreichbare Tabellen: `profiles, progress, feedback, leads, proofs`. Der Angreifer wird mit einem über Magic-Link authentifizierten Client (jeder kann sich registrieren) das Naheliegende versuchen: `supabase.from('profiles').select('*')`, um ALLE Profile abzuziehen; `supabase.from('leads').select('*')`, um die Lead-Liste zu stehlen; ein `update` auf seine eigene Zeile in `profiles` mit `role = 'admin'` oder `founder_badge = true`, um sich selbst hochzustufen; ein `insert` in `proofs` mit fremdem `user_id`, um den Fortschritt eines anderen zu fälschen. Jede davon ist eine Angriffshypothese, die DU mit einer Policy widerlegen musst. Hast du sie nicht explizit widerlegt, geh davon aus, dass sie funktioniert.

Versteh, warum RLS die Autorität ist und wie sich die echte Verteidigung von MOONKEY zusammensetzt. SELECT auf `profiles/progress/feedback/proofs` ist self-or-admin: Die Policy lässt die Zeile nur durch, wenn `user_id = auth.uid()` ODER `is_admin()`. `is_admin()` ist SECURITY DEFINER — es läuft mit den Rechten des Eigentümers und prüft, ob der Aufrufer Admin ist, ohne dass der Aufrufer diese Entscheidung manipulieren kann. Ergebnis: Ein Nicht-Admin, der `select('*')` anfragt, bekommt keinen Fehler, er bekommt SEINE Zeilen und sonst nichts — der Massen-Dump liefert eine einzige Zeile, seine eigene. Die Privilegien-Eskalation stoppt ein Trigger (`guard_privileged_profile_columns`): `role` und `founder_badge` sind für Nicht-Admins unveränderlich, also wird das `update role='admin'` auf DB-Ebene abgelehnt. Den fremden Insert stoppt `proofs_insert_self`: Es verlangt eine Session und bindet `user_id = auth.uid()`.

Die operative Konsequenz des Modells: Verifiziere durch Impersonation, nicht durch Code-Lektüre. Eine Policy, die korrekt 'aussieht', kann ein Loch haben (ein falsch gesetztes OR, ein USING ohne WITH CHECK, das Updates durchlässt). Der einzige Beweis, der zählt, ist, dich in die Schuhe des Angreifers zu stellen: Authentifiziere dich als normaler Nutzer und FÜHRE die oben aufgezählten Angriffe gegen die echte DB AUS, und bestätige, dass jeder leer oder mit Fehler zurückkommt. CLAUDE.md erwähnt, dass die Lese-Isolation 'durch Impersonation verifiziert' ist — das ist der Standard. 'Ich habe die Policy geschrieben' ist kein Beweis; 'ich habe den Angriff als Nutzer X versucht und die Zeile von Nutzer Y nicht gelesen' schon.

Vergiss die Vektoren nicht, die kein RLS sind. Das Bedrohungsmodell einer SSG umfasst auch: (a) den Unterschied USING vs. WITH CHECK — USING filtert, welche Zeilen du siehst/betriffst, WITH CHECK validiert den Endzustand eines INSERT/UPDATE; ein vergessenes WITH CHECK in einem UPDATE lässt dich eine Zeile auf einen fremden user_id verschieben. (b) Die RPCs: Eine schlecht geschriebene SECURITY-DEFINER-Funktion ist ein Loch, das RLS per Design umgeht — MOONKEY beschränkt sie auf `authenticated` und entzieht gefährliche Operationen. (c) TRUNCATE: anon/authenticated entzogen, weil RLS nicht gegen TRUNCATE schützt (es löscht die ganze Tabelle, ohne Policies pro Zeile auszuwerten). (d) Leck durch Fehler und durch Spalten: ein SELECT, das eine sensible Spalte zurückgibt, die du auszuschliessen vergessen hast.

Land mit dem Projekt-Kontrast, um das Prinzip zu fixieren. XNLAB ist eine Markenseite fast ohne Backend: Ihre Fläche ist minimal — Kontaktformulare, Header, vielleicht ein Akquise-Endpoint. Dort ist das Bedrohungsmodell 'Spam und XSS in dem wenigen, das Input annimmt', nicht DB-Eskalation. XHUB IRON lebt in DERSELBEN DB wie MOONKEY, ist aber ein operatives Panel des Gründers: Seine `iron_*`-Tabellen dürfen für einen MOONKEY-Nutzer nicht lesbar sein — dieselbe RLS-Engine muss ZWEI Produkte tragen, die sich Postgres teilen, ohne dass eines das andere liest (das ist OS-05). Das Bedrohungsmodell ist nicht generisch: Es leitet sich ab aus WELCHE Daten es gibt, WER sich authentifizieren kann und WAS die Infrastruktur teilt. Fang immer damit an, diese drei Achsen zu inventarisieren.

Das Leitprinzip ist popperianisch: Ein Sicherheitsbefund ist nicht wahr, weil du ihn behauptest, er ist wahr, weil du VERSUCHT hast, ihn zu widerlegen, und es nicht konntest. Dreh den natürlichen Ablauf um. Wenn du glaubst, eine Verwundbarkeit gefunden zu haben ('jeder kann `leads` lesen'), ist dein nächster Schritt nicht, sie zu melden — es ist der Versuch zu zeigen, dass du dich irrst: Gibt es eine Policy, die es verhindert? Habe ich es mit der richtigen Rolle getestet? Hat das `select` echte Daten geliefert oder leer? Erst wenn dein Widerlegungsversuch scheitert, steigt der Befund zu 'bestätigt' auf. Und umgekehrt: Wenn du glaubst, etwas sei sicher ('die self-or-admin-Policy schützt `profiles`'), ist deine Aufgabe, es anzugreifen, bis es bricht oder überlebt.

Definiere die zwei Fehler, die du jagst, mit klaren Namen. Falsch-Positiv: Du meldest eine Verwundbarkeit, die nicht existiert — z. B. schreist du 'der anon key ist im Bundle exponiert', während der anon key per Design öffentlich ist und die DB durch RLS geschützt (siehe OS-01). Du verbrennst Vertrauen; beim nächsten Mal glaubt dir niemand. Falsch-Negativ: Du hältst etwas für sicher, das es nicht ist — z. B. 'das Admin-Panel ist versteckt, alles gut', ohne den direkten DB-Zugriff zu testen. Du lässt die Lücke offen. Das adversarielle Audit existiert, um BEIDE zu minimieren, und das Werkzeug für beide ist dasselbe: der ausführbare Test.

Die konkrete Methode: Erzeuge für jeden Befund einen reproduzierbaren Test, keine Behauptung. 'Reproduzierbar' heisst: ein Befehl oder Snippet, das jeder ausführen und dasselbe Ergebnis sehen kann. Um zu bestätigen, dass `profiles` NICHT gedumpt werden kann: ein Skript, das sich als user_A authentifiziert, `.from('profiles').select('*')` macht und die Zeilenzahl ausgibt — erwartet 1 (nur seine eigene). Um zu bestätigen, dass die Privilegien-Eskalation geschlossen ist: als user_A `.from('profiles').update({ role: 'admin' }).eq('id', myId)` und den Fehler ausgeben, den der Guard-Trigger zurückgibt. Liefert der Angriff, was du erwartet hast (leer/Fehler), ist die Kontrolle verifiziert. Liefert er Daten, hast du einen ECHTEN Befund — und er kommt gleich mit seinem PoC im Anhang.

Arbeite mit dem Werkzeug von Supabase selbst, aber kapituliere nicht davor. `get_advisors` (security lints) zeigt dir Tabellen ohne RLS, permissive Policies, SECURITY-DEFINER-Funktionen ohne fixen search_path. Behandle es als HYPOTHESEN-Generator, nicht als Urteilsinstanz. Ein Advisor, der sagt 'Funktion X ist SECURITY DEFINER mit mutable search_path', ist eine Risiko-Hypothese: Geh zur Funktion, schau, ob ein Angreifer ein Objekt in ein Schema platzieren kann, das sie zuerst auflöst. Manchmal ist es ausnutzbar, manchmal nicht — je nach Kontext. Der Advisor spart dir den ersten Durchgang; die Widerlegung machst du. CLAUDE.md institutionalisiert es bereits: RLS-Änderungen = versionierte Migration + danach `get_advisors`. Dieser zweite Teil ist das adversarielle Audit als Routine.

Achte auf die Falsch-Negative der Methode selbst: Der Angriff, der 'durchgeht', kann aus dem falschen Grund durchgehen. Wenn dein `select('*')` auf `profiles` leer zurückkommt — liegt das daran, dass RLS es blockiert hat, oder dass deine Test-Session abgelaufen war / du nicht authentifiziert warst / die Tabelle leer war? Eine Kontrolle gilt nie als gut ohne einen KONTRAST-Fall: Beweise, dass dieselbe Query SEHR WOHL Daten liefert, wenn sie soll (als Admin, oder als Eigentümer der Zeile). Ein Sicherheitstest ohne seine positive Kontrolle ist ein als Erfolg getarntes Falsch-Negativ. Verifiziere immer, dass deine Waffe funktioniert, bevor du das Ziel für immun erklärst.

Land die Strenge in den Projekten, wo der Irrtum am meisten schmerzt. In XCAP ist das adversarielle Audit zentrale Doktrin: Das Projektgedächtnis beschreibt es als 'Anti-Fabrikation per Konstruktion' — ein System, das Forecasts erfasst und sie gegen reale Ergebnisse kalibriert, das seine eigenen Vorhersagen widerlegt, statt sie zu glauben. Denselben Muskel wendest du auf Security an: Unterschreib nicht 'das Ledger ist read-only', bis ein Schreibversuch mit dem Ingest-Credential vor deinen Augen scheitert. In Espejo, wo die Grenze personenbezogener Daten ethisch und technisch ist, ist ein Audit, das sagt 'es gibt kein Leck zwischen Tenants', ohne einen PoC, in dem ein Tenant versucht, einen anderen zu lesen, KEIN Audit: Es ist ein Wunsch. Zuerst widerlegen, immer, besonders wenn das erwartete Ergebnis das bequeme ist.

Verinnerliche die Sequenz DCRP: Detektieren → Containen (eindämmen) → Recovern (Rollback) → Post-mortem. Der Fehler der meisten ist, direkt zum 'Reparieren' zu springen und blind in Produktion einzugreifen. Die Reihenfolge zählt, weil jede Phase die nächste schützt: Detektierst du schlecht, dämmst du das Falsche ein; dämmst du nicht ein, wächst der Schaden, während du recoverst; recoverst du ohne zu verstehen, wiederholst du den Vorfall. Und die Null-Regel, in jedem ernsthaften Runbook festgehalten: In einem Vorfall improvisierst du NICHT in Produktion. Du führst vordefinierte Schritte aus. Kreativität ist fürs Post-mortem, nicht für 3 Uhr nachts mit ausgefallener Seite.

Detektieren heisst zu wissen, WAS kaputt ist und seit WANN. In MOONKEY (Cloudflare Pages + Supabase) sind deine Signale: das Cloudflare-Deploy (welcher Commit ist live? Ist der letzte Build durchgelaufen?), die Supabase-Logs (`get_logs` pro Service: api, postgres, auth — dort siehst du Policy-Fehler, scheiternde Queries, Peaks von 4xx/5xx) und die Nutzerbeschwerde (oft das erste Signal). Das Erste, was du etablierst, ist die Zeitleiste: Was hat sich kurz davor geändert? Fast immer korreliert der Vorfall mit einem kürzlichen Deploy oder einer Migration. 'Begann nach dem Merge um 16:20' verengt den Suchraum von Stunden auf Minuten.

Containen heisst, die Blutung zu stoppen, bevor du die Wunde versorgst. Schlüsselfrage: Korrumpiert das gerade JETZT Daten? Wenn ein Bug schlechte Zeilen in `proofs` oder `progress` schreibt, vervielfacht jede Minute, die du brauchst, das Cleanup. Eindämmungs-Optionen nach Schweregrad: das Cloudflare-Deploy auf das vorherige zurücksetzen (ein Klick — Cloudflare Pages bewahrt frühere Deploys und erlaubt sofortigen Rollback, das ist dein schnellster und sicherster Hebel), das kaputte Feature deaktivieren, oder im Extremfall destruktiven Schreibens den Zugriff auf Policy-Ebene kappen. Containen ist NICHT reparieren: Es ist, den Schaden in seinem aktuellen Zustand einzufrieren, um Zeit zum Nachdenken zu haben.

Recovern verlangt, ZWEI Rollbacks zu unterscheiden, die Leute verwechseln und die gegensätzliche Risiken haben. (1) CODE-Rollback: zurück zu einem früheren Deploy/Commit. Er ist billig, reversibel und fast immer sicher — in Cloudflare Pages ist er sofortig. Das ist deine erste Option. (2) SCHEMA-/DATEN-Rollback: eine Migration zurücknehmen oder Daten wiederherstellen. Er ist GEFÄHRLICH und irreversibel: Eine `down`-Migration, die ein `DROP COLUMN` macht, löscht Daten, die vielleicht nur beschädigt, nicht verloren waren. Regeln: Führe nie einen Daten-Rollback aus, ohne zuvor ein Backup/PITR bestätigt zu haben; bevorzuge eine FORWARD-Migration, die korrigiert (ein neues `UPDATE`, das die schlechten Zeilen repariert), gegenüber einem destruktiven `down`; jede Supabase-Migration ist versioniert (`apply_migration`), genau damit der Zustand rekonstruierbar ist. Ist die Frage 'Code- oder Daten-Rollback', fang IMMER mit dem Code-Rollback an: oft reicht er und fasst die DB nicht an.

Das Post-mortem ist, wo der Vorfall seine Schuld begleicht, indem er zu Lernen wird. Es ist OHNE Schuldzuweisung (blameless): Das Ziel ist nicht, wer es brach, sondern was am SYSTEM einem normalen Menschen erlaubt hat, es zu brechen. Struktur: Zeitleiste (was passierte wann, Minute für Minute), Impact (wie viele Nutzer, welche Daten, wie lange), Wurzelursache (die '5 Warums', bis du beim System-Versagen landest, nicht beim Personen-Versagen), und korrigierende Massnahmen mit Eigentümer und Datum. Jeder Vorfall muss mindestens eine Kontrolle hervorbringen, die ihn VERHINDERT oder früher ERKANNT hätte — ein Test, ein Advisor in CI, ein Alarm. Wenn das Post-mortem nichts am System ändert, war es kein Post-mortem, es war ein Geständnis.

Veranker das Runbook in der Realität jedes Projekts, denn Schweregrad und Hebel ändern sich. In XCAP existiert eine heilige Kapital-Invariante — das Kapital akkumuliert über Sessions und bewegt sich nur bei realisierten Closes, es wird nie zurückgesetzt. Ein Vorfall, der diese Invariante berührt, wird NICHT mit einem blinden Daten-Rollback repariert: Du würdest reale Buchhaltungs-Historie löschen. Dort zwingt das Runbook zur Forward-Korrektur und zur Verifikation der Invariante, bevor du irgendetwas anfasst. In Espejo, multi-tenant, hat ein Vorfall eine Zusatzfrage in der Detektions-Phase: Hat das Versagen die Grenze zwischen Tenants überschritten? Hat ein Bug Daten eines Tenants einem anderen exponiert, gibt es neben dem Rollback eine Pflicht zur Eindämmung des Lecks. Das generische Runbook gibt dir das Rückgrat; die Invarianten jedes Projekts geben dir die Regeln, die du in der Panik NIEMALS verletzt.

Geh vom konkreten Fakt aus: Die Instanz `wuchsslgbqlhyxljsmxi` beherbergt ZWEI Produkte. MOONKEY nutzt `profiles, progress, feedback, leads, proofs`. XHUB IRON nutzt `iron_*, world_*, focus_*, daily_focus_history`. Sie teilen sich dasselbe Postgres, dasselbe `auth.users` und — entscheidend — DERSELBE anon key wird benutzt, um mit der DB zu sprechen. Das heisst, der öffentliche MOONKEY-Client KANN technisch `from('iron_command').select('*')` versuchen. Der einzige Grund, warum das nicht funktioniert, muss eine harte Barriere in der DB sein, nicht die CLAUDE.md-Notiz, die sagt 'fass sie nicht an'. Diese Notiz schützt davor, dass DU sie aus Versehen beim Schreiben von Code editierst; sie schützt nicht gegen einen Angreifer, der deinen anon key bereits hat.

Versteh die Isolations-Schichten von der schwächsten zur stärksten. (1) Konvention (Namen `iron_*` vs. ohne Präfix): organisiert, isoliert nicht — ein Angreifer ignoriert Konventionen. (2) RLS pro Tabelle: Jede XHUB-Tabelle muss Policies haben, die Zugriff nur ihrer eigenen Rolle/ihrem eigenen Nutzer gewähren; eine `iron_*`-Tabelle ohne RLS oder mit einer permissiven Policy ist ein direktes Leck. (3) Separate Schemas: XHUB in ein eigenes Postgres-Schema legen und es NICHT in der PostgREST-API exponieren (das `db.schema`, das Supabase publiziert) ist eine stärkere Barriere — was nicht im exponierten Schema ist, sieht der Client gar nicht. (4) Rollen/Grants: REVOKE von `anon`/`authenticated` auf den fremden Tabellen/Objekten. Die robuste Verteidigung STAPELT diese Schichten; vertrau nicht einer einzigen.

Für den Fall MOONKEY↔XHUB ist die Audit-Frage direkt: Kann ein authentifizierter MOONKEY-Nutzer eine Zeile aus `iron_*` lesen? Widerleg es (OS-03): Authentifiziere dich als normaler MOONKEY-Nutzer und führe `supabase.from('iron_command').select('*')` aus. Korrekt ist, dass es einen Berechtigungsfehler oder leer durch RLS zurückgibt. Gibt es Daten zurück, hast du ein kritisches Isolations-Leck. Das Projektgedächtnis sagt, dass die Health berechnet wird und das Modell für den HUB 'open RLS, computed health' ist — das heisst, du musst EXPLIZIT verifizieren, dass 'open' für den HUB nicht 'offen für MOONKEY-Clients' bedeutet. Isolation zwischen Projekten = jede Tabelle antwortet nur ihrem legitimen Eigentümer, bewiesen durch gekreuzte Impersonation.

Die zweite Achse ist Multi-Tenant INNERHALB eines Projekts, das ist Espejo. Hier sind es nicht zwei Produkte, es sind N Tenants (jeder Influencer) in denselben Tabellen. Die Isolation wird zeilenbasiert: Jede Zeile trägt einen `tenant_id`, und die RLS-Policy verlangt, dass `tenant_id` mit dem Tenant des Aufrufers übereinstimmt. Der zu widerlegende Angriff: Tenant A versucht, Zeilen mit dem `tenant_id` von B zu lesen/schreiben. Die klassische Falle ist das UPDATE ohne WITH CHECK: USING begrenzt, welche Zeilen A sieht, aber ohne WITH CHECK könnte A eine Zeile auf B umhängen oder eine mit fremdem `tenant_id` erzeugen. Eine weitere Falle: eine SECURITY-DEFINER-RPC, die `tenant_id` als Parameter empfängt und nicht validiert, dass er mit `auth.uid()` übereinstimmt — ein Loch, das alle Tenants durchkreuzt. Multi-Tenant-Isolation ist nur dann real, wenn JEDE Policy jeder Operation (SELECT/INSERT/UPDATE/DELETE) den Tenant an die Identität des Aufrufers ankert, nicht an einen Parameter, den der Client kontrolliert.

Es gibt Übergangs-Vektoren, die kein SELECT sind und die Leute vergessen. `auth.users` ist geteilt: Ein Nutzer ist derselbe in MOONKEY und in XHUB — stell sicher, dass ein Konto im einen keine Rollen im anderen gewährt (in MOONKEY sind `role` und `founder_badge` für Nicht-Admins genau deshalb unveränderlich, damit die Registrierung keine gekreuzten Privilegien eskaliert). Die RPCs und SECURITY-DEFINER-Funktionen sind globale Objekte: Eine von `authenticated` ausführbare XHUB-Funktion ist vom MOONKEY-Client aufrufbar — beschränke sie per Rolle oder validiere den Kontext innen. Geteilte Trigger und Sequenzen, Views, die JOINs zwischen Tabellen beider Produkte machen, und `get_advisors`, das fehlendes RLS in irgendeiner Tabelle des Projekts meldet: All das ist Übergangsfläche. Isolation ist keine Policy, sie ist eine Eigenschaft des gesamten Systems.

Schliess mit der operativen Disziplin, die die Isolation über die Zeit am Leben hält. Jede Schema-Änderung läuft als versionierte Migration ein (`apply_migration`), nie als manuelle Bearbeitung im Panel — so ist der Sicherheitszustand rekonstruierbar und auditierbar. Nach jeder Migration, die Tabellen oder Policies berührt, lauf `get_advisors`, um deaktiviertes RLS oder versehentlich eingeführte permissive Policies zu jagen. Und halte einen Isolations-Test als Teil des Runbooks: ein Skript, das als MOONKEY-Nutzer versucht, jedes fremde Präfix (`iron_*`, `world_*`) zu lesen, und den Build fehlschlagen lässt, falls eines Zeilen zurückgibt. Isolation zwischen Projekten wird nicht 'einmal konfiguriert'; sie wird bei jeder Änderung neu verifiziert, denn eine harmlose Migration kann eine Tür öffnen, die monatelang geschlossen war.

Die drei Ströme eines lebenden Systems. Logs = das Tagebuch dessen, was passiert (Requests, Queries, Auth). Fehler = das, was stillschweigend auf der Client-Seite bricht, wo deine Server-Logs nicht hinreichen. Kosten = der Zähler, der läuft, auch wenn niemand das System nutzt. Es sind drei verschiedene Leitungen mit drei verschiedenen Werkzeugen; sie zu verwechseln ist der Grund, warum Leute glauben zu monitorn und es nicht tun.

Observability in einer SSG ist nicht dasselbe wie in einem Server. MOONKEY ist statisch: Es gibt KEINEN server-seitigen Handler, in den man einen Logger setzen könnte. Deine Telemetrie lebt an drei Orten ausserhalb deines HTML: (1) Cloudflare Pages Analytics (Requests, Bandbreite, Edge-Fehler), (2) die Supabase-Logs (Dashboard → Logs: API, Postgres, Auth — jede Query, die durch PostgREST läuft, und jeder Login hinterlässt eine Spur) und (3) der Browser des Nutzers (JS-Fehler, die nur du nicht siehst). Akzeptier es: In einer SSG passiert ein Grossteil dessen, was scheitert, auf einer Maschine, die du nicht kontrollierst.

Was wirklich überwachen, nicht alles. Die Versuchung ist, alles zu loggen und nichts zu lesen. Definiere eine Handvoll Signale, die zählen: 4xx/5xx-Fehlerrate am Edge (ein Peak von 401/403 = RLS lehnt ab oder ein Angreifer probiert herum), Auth-Fehler in Supabase (gescheiterte Magic-Link-Versuche), Latenz der langsamen Queries (Supabase markiert die, die dauern) und Volumen gelesener Zeilen (eine Query ohne Filter, die plötzlich 10.000 Zeilen liefert, ist ein Kosten-Bug). Eine Metrik, die keine Entscheidung auslöst, ist Rauschen; lösch sie.

Error-Tracking auf der Client-Seite: der blinde Fleck. In einer statischen Seite bricht ein TypeError in deinem JS die Erfahrung des Nutzers, und bei dir kommt NICHTS an — kein Server-Log, kein Alert. Du musst Fehler im Browser einfangen und nach aussen senden. Das ehrliche Minimum: ein window.addEventListener('error', ...) und ('unhandledrejection', ...), das ein fetch an einen eigenen Endpoint macht (eine Supabase Edge Function, die in eine Log-Tabelle mit Insert-only-RLS einfügt). Das Robuste: Sentry oder Ähnliches mit seinem kostenlosen SDK bis zu einem gewissen Volumen. Die Regel: Wenn du keine Client-Fehler einfängst, operierst du in der Hälfte deines Systems blind.

Die realen Kosten des Betriebs, aufgeschlüsselt. Der Supabase Free Tier hat konkrete Decken, bei deren Überschreiten man dich entweder kappt oder dir berechnet: DB-Zeilen, Egress-Bandbreite, Speicher, Monthly Active Users von Auth und Edge-Function-Invocations. Cloudflare Pages ist grosszügig, hat aber Limits bei Builds/Monat und bei Requests in Funktionen. Und die Ausgabe, die am stärksten skaliert und am wenigsten sichtbar ist: die KI-Tokens. Jeder Aufruf an die Claude-API wird nach Input- und Output-Tokens abgerechnet, mit unterschiedlichen Tarifen; ein Prompt mit einem riesigen CLAUDE.md oder eine Agent-Schleife ohne Deckel kann die Kosten vervielfachen, ohne dass sich ändert, 'was die App tut'. Der Operator kennt seine drei Rechnungen: DB, Edge und Tokens.

Warum Überraschungsrechnungen kommen und wie man sie nicht bekommt. Drei klassische Ursachen: (1) ein Endpoint oder eine Edge Function ohne Rate-Limit, den jemand entdeckt und hämmert — Nutzung = Geld; (2) eine Query ohne LIMIT und ohne Index, die bei jedem Laden die ganze Tabelle scannt; (3) eine KI-Agent-Schleife ohne Token- und Iterations-Deckel (die XCAP-Kapital-Invariante existiert teils deswegen: Schleifen, die Lernen akkumulieren, nicht Kosten). Die Verteidigung ist nicht, die Rechnung zum Monatsende zu überwachen, sondern die Bremsen VORHER zu setzen: Budgets mit Alert bei 50/80/100%, harte Limits, wo die Plattform sie bietet, und explizite Decken für max_tokens und Iterationen bei jedem KI-Aufruf.

Über das alarmieren, was zählt, ohne Alert-Müdigkeit. Ein Alert, der jede Stunde springt, wird in einer Woche ignoriert. Das Kriterium: Alarmiere nur das Handlungsfähige und Dringende. Gut: 'die Ausgabe des Monats hat 80% des Budgets überschritten', 'die 5xx-Rate ging über 1%', 'Client-Fehler > X in 10 Min'. Schlecht: 'es gab einen Request'. Konfiguriere die Budget-Alerts, die dir Supabase, Cloudflare und die Anthropic-Konsole bereits geben — sie sind gratis und sind deine erste Linie. Jeder Alert muss 'was tue ich, wenn er springt' beantworten; gibt es keine Handlung, ist es kein Alert, es ist Angst.

Schliess den Kreis mit der Vorfall-Reaktion (OS-04). Beobachten ohne Reaktionsplan ist nur Zuschauen, wie es brennt. Das Panel und die Alerts dieses Moduls sind die Sensoren; der Rollback und das Incident Response von OS-04 sind die Aktoren. Ein gut operiertes System verbindet beide: Der Alert weckt dich, die Logs sagen dir, was passiert ist, und der Reaktionsplan sagt dir, was zu tun ist. Observability + Kosten + Reaktion = wirklich operieren, nicht beten.