APIs sind nicht optional | Thomas Panzeri

Moderne Anwendungsentwicklung fühlt sich oft wie ein Rennen an. Schneller bauen. Früher ausliefern. Ständig iterieren. In dieser Eile bieten Plattformen wie Firebase und Supabase eine verlockende Abkürzung: Sie versprechen, dass du dich nicht um die Backend-Infrastruktur kümmern musst. Einfach die App direkt mit der Datenbank verbinden, ein paar Regeln darüberlegen, fertig.

Diese Denkweise hat aber einen grundlegenden Fehler, und der ist nicht nur theoretisch. Echte Firmen und echte Nutzer lernen ihn gerade auf die harte Tour.

🚨 Was passiert ist: das Datenleck der App T

Nimm das Beispiel von T, einer App nur für Frauen mit strenger Identitätsprüfung. Die Nutzerinnen luden sensible Dokumente hoch, Selfies, Ausweise und mehr, im Glauben, ihre Daten seien sicher. Stattdessen landeten sie in einem Firebase-Storage-Bucket… der öffentlich war.

Richtig gelesen. Sensible Dateien, inklusive Personendaten und eingebetteter Metadaten, lagen offen, weil Firebase so voreingestellt ist und seine APIs oft so verwendet werden: unsicher, ohne eigene Berechtigungsschicht und ohne Trennung der Zugriffe.

Es brauchte nur jemanden, der einen öffentlich erreichbaren Endpunkt fand, alle Datei-URLs auflistete und den ganzen Bestand herunterlud. Das war kein raffinierter Hack. Das war Fahrlässigkeit. Und schlimmer noch: Es war absehbar.

Warum es APIs braucht: eine Lektion in Architektur

Im Kern dieses Desasters steht ein Missverständnis darüber, wie Software aufgebaut sein sollte. So sieht eine gute Infrastruktur aus:

Nutzer → API → Datenbank
Jede Anfrage wird authentifiziert, validiert und autorisiert, bevor sie auf Daten zugreift.
Die Geschäftslogik lebt auf dem Server, nicht im Client.

Die API ist der Türsteher. Dort werden:

Berechtigungen durchgesetzt,
Logs geschrieben,
Eingaben bereinigt,
Rate Limits angewendet.

Wenn du diese Schicht weglässt, wenn Nutzer direkt mit deiner Datenbank sprechen, verlierst du all das. Firebase und Supabase verkaufen dir genau diese Abkürzung. Und wenn du die Risiken nicht sehr genau kennst (und viel Erfahrung hast), wird sie dich im Stich lassen.

Firebase und Supabase: die Probleme

Schauen wir an, was diese Werkzeuge in den Händen der meisten Entwickler gefährlich macht:

1. Standardmässig offen

Firebase-Buckets und Firestore-Datenbanken sind oft für nicht angemeldete Nutzer lesbar, solange du sie nicht ausdrücklich absicherst. Supabase ist etwas strenger, drängt Entwickler aber trotzdem dazu, die Datenbank direkt aus dem Frontend abzufragen.

2. Keine echte API-Schicht

Diese Plattformen verwischen die Grenze zwischen Datenbank und API. Das ist ein Fehler. Berechtigungen, Validierung, Logging gehören in den Code, nicht in Regeln oder Rollen, die man an sein Datenmodell klebt.

3. Sicherheitstheater

Row-Level Security oder Berechtigungsregeln auf Client-Seite klingen in der Theorie gut, aber sie:

sind schwer zu durchschauen,
sind oft unvollständig,
werden selten so getestet wie normale Server-Logik.

Vor allem: Sie verstecken Komplexität, statt sie sichtbar zu machen. Und das ist gefährlich.

4. Schlechte Voreinstellungen, schlechtere Gewohnheiten

Weil Firebase und Supabase die Einstiegshürde senken, ziehen sie Entwickler an, die die Grundlagen von Backends vielleicht noch nicht verstehen und sie vielleicht nie lernen, weil die Plattform alles wegabstrahiert.

So entsteht ein Ökosystem voller «vibe-coded» Apps: Sie funktionieren, bis sie es nicht mehr tun. Dann fliegen sie auf eine Art in die Luft, die das Vertrauen der Nutzer zerstört, und manchmal ganze Firmen.

Was das Datenleck von T lehrt

Sagen wir es ganz deutlich:

Nichts wurde «gehackt». Das System war einfach nicht abgeschlossen. Das ist nicht raffiniert, das ist tragisch.
Metadaten wurden nicht entfernt. Selbst wenn die Dateien nicht öffentlich gewesen wären, wären EXIF- und Standortdaten standardmässig abgeflossen.
Es gab keine eigenen APIs. Die App verliess sich auf die offenen Storage- und Firestore-APIs von Firebase, ohne eigenes Backend, das den Zugriff regelt.
Die Verantwortung liegt in der Architektur. Firebase hat die Daten nicht geleakt. Die Leute, die es falsch eingesetzt haben, schon. Aber Firebase hat es leicht gemacht, diese Fehler zu begehen.

Das war kein Einzelfall. Ähnliche Fehlkonfigurationen haben schon über 125 Millionen Konten in mehr als 900 Apps mit Firebase-Backend offengelegt, viele davon von Mobile-Entwicklern oder Startups gebaut, die eine Abkürzung gesucht haben.

Das Wichtigste: Schreib deine APIs

Wenn du ein Produkt baust, ist das die harte Wahrheit:

Du kommst um Backend-Code nicht herum. Wenn du es versuchst, baust du deine App auf eine Falltür.

Schreib Server-Logik. Bau echte API-Endpunkte. Leg Zugriffsregeln im Code fest, nicht in der Datenbank. Speichere Dateien sicher, mit signierten URLs, Ablaufzeiten und richtiger Authentifizierung.

Es gibt moderne Werkzeuge, die dabei helfen:

Convex: serverloses Backend mit erzwungener, funktionsbasierter Zugriffskontrolle.
tRPC + Next.js: Full-Stack-TypeScript mit strengen Typen und API-Schichten.
Go-, Node- oder Python-Backends: bewährte, produktionsreife Werkzeuge, die dir die Disziplin sicherer Entwicklung beibringen.

Zum Schluss

APIs sind kein Overhead. Sie sind die Architektur. Wenn du sie weglässt, baust du keine Software. Du baust ein Haftungsrisiko.

Firebase und Supabase sind nicht an sich böse, aber sie sind gefährlich, wenn du nicht weisst, was du tust. Sie tauschen kurzfristiges Tempo gegen langfristiges Risiko. Und wenn deine App echte Nutzer, echtes Geld oder echte Identitätsdaten verarbeitet, kannst du dir diesen Tausch nicht leisten.