Sicherheit, auch wenn du „nur prototypst"
Warum ich vom ersten Tag an über Sicherheit nachdenke — auch bei kleinen internen Tools — und wie die Architektur von Lovable es leichter macht, es richtig zu machen.
Sicherheit, auch wenn du „nur prototypst"
Wer ein neues Produkt baut — besonders allein und früh — schiebt das Thema Sicherheit sehr leicht auf.
„Das benutze nur ich." „Ich mach das später." „Ich experimentiere ja noch."
Das Problem: Sicherheit ist nichts, was man später hinzufügt. Sie wird von Anfang an mit entworfen — oder versehentlich weg-entworfen.
Das ist das einfache Denkmodell, dem ich beim Bauen meiner Werkzeuge folge.
Das Frontend ist nicht die Anwendung
Alles, was im Browser läuft, ist öffentlich, einsehbar und veränderbar.
Das heißt, das Frontend darf niemals enthalten:
- Geheimnisse oder API-Schlüssel
- Berechtigungslogik
- Validierungsregeln
- Geschäftsentscheidungen
Das Frontend ist nur zuständig für:
- Daten anzuzeigen
- Nutzereingaben zu sammeln
- Anfragen zu senden
Alle wichtige Logik lebt woanders.
Das Backend ist der Ort, an dem Vertrauen existiert
Authentifizierung, Validierung und Geschäftslogik müssen auf dem Server liegen — in Edge Functions.
Das schafft:
- Einen einzigen Ort, an dem Berechtigungen geprüft werden
- Einen einzigen Ort, an dem Daten validiert werden
- Einen einzigen Ort, an dem sensible Operationen passieren
Das macht das System leichter durchschaubar und von Grund auf sicherer.
Row Level Security legt die Datenhoheit fest
Row Level Security ist keine optionale Funktion.
Ohne sie:
- Sehen Nutzer Daten, die ihnen nicht gehören
- Bricht die Trennung zwischen Mandanten
- Kann ein einziger Fehler ganze Tabellen offenlegen
RLS legt fest:
- Wer was sehen darf
- Wer was ändern darf
- Wie Nutzer, Teams und Organisationen getrennt sind
Fehlt RLS oder ist sie falsch, ist das System falsch — auch wenn alles andere gut aussieht.
Authentifizierung ist Infrastruktur, keine Oberfläche
Login-Bildschirme sind Nutzererlebnis. Authentifizierung selbst ist Infrastruktur.
Die Oberfläche reagiert auf den Anmeldezustand, entscheidet aber nie, was erlaubt ist. Alle Berechtigungsprüfungen passieren serverseitig.
Diese Trennung ist entscheidend.
Intern heißt nicht sicher
Auch interne Werkzeuge:
- können falsch konfiguriert sein
- können versehentlich veröffentlicht werden
- können zu echten Produkten heranwachsen
Deshalb sollten interne Werkzeuge trotzdem haben:
- aktivierte Authentifizierung
- konfigurierte RLS
- keine Geheimnisse im Frontend
Jetzt kostet das wenig und verhindert später große Probleme.
Schlussgedanke
Sicherheit ist keine Checkliste, die man vor dem Start abarbeitet.
Sie ist eine strukturelle Entscheidung, die man am Anfang trifft.
Schnell heißt nicht, Struktur zu überspringen. Schnell heißt, eine Struktur zu wählen, die beim Wachsen nicht bricht.