Reeve Ist deine Windsurf-App sicher?
Taugt Windsurf für eine Live-App? Der erzeugte Code ist meist in Ordnung. Durchrutscht die Änderung, die niemand las, in einer Datei, die niemand öffnete.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine Windsurf-App ist auf der Code-Seite meistens sicher. Durch rutscht die Änderung, die niemand gelesen hat, prüfe also Ergebnisse statt Diffs.
- Durchsuche deine Build-Ausgabe nach service_role und sk_live_. Das deckt jede Datei ab, die die Assistenz angefasst hat, ob du sie geöffnet hast oder nicht.
- Row Level Security ist die eine Prüfung, die Code überlebt, den du nie gelesen hast, weil jede Anfrage an der Datenbank vorbei muss.
Windsurf kann in einem Schritt sehr viel an deinem Projekt ändern: mehrere Dateien, eine Migration, eine Konfiguration, alles auf einmal und alles funktionierend. Das Ergebnis ist meist gut. Das Problem ist die Durchsicht: Eine Änderung, die sich über viele Dateien verteilt, wird nicht so gelesen wie eine, die eine einzige berührt, und die zwei Dinge, die es zu fangen lohnt, sind beide eine Zeile lang.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Die Antwort ist nicht, sorgfältiger zu lesen. Im Tempo dieser Werkzeuge skaliert sorgfältiges Lesen nicht. Was skaliert, ist die zwei Ergebnisse zu prüfen, auf die es ankommt: von außen und im Nachhinein.
Die Hälfte deiner App, die in jedem Fall öffentlich ist
Ihre ganze Vorderseite.
Stell es dir als Laden vor. Alles, was Windsurf in deine Oberfläche baut, ist die Ladenfront, und die Ladenfront wird jedem Besucher vollständig ausgehändigt: Ein Browser kann keine Seite anzeigen, die ihm nicht geschickt wurde. Dahinter liegt das Lager, deine Datenbank, ein eigenes Gebäude im Internet mit eigener Adresse und eigenem Schloss.
Diese Unterscheidung zählt, weil Code zu lesen dir etwas über Absicht sagt, und Absicht ist nicht das, was ausgeliefert wird. Ausgeliefert wird die Build-Ausgabe: ein Bündel JavaScript, zusammengesetzt aus jeder bearbeiteten Datei, ausgehändigt an jeden, der deine Seite lädt. Genau dieses Bündel lohnt die Untersuchung, und es ist viel kleiner zu durchsuchen als der Quellcode, aus dem es kam.
Ist ein Schlüssel im Bundle deiner Windsurf-App ein Problem?
Meistens nicht. Es hängt davon ab, welcher, und die beiden sehen fast identisch aus.
Ein öffentlicher Schlüssel benennt dein Projekt und tut sonst nichts:
sb_publishable_… in neuen Supabase-Projekten, anon in älteren. Er ist zum
Mitlesen gedacht, und ihn zu finden ist kein Befund. Ein geheimer Schlüssel,
sb_secret_… oder das ältere service_role, umgeht jede Regel, die du
geschrieben hast, und liest und schreibt jede Zeile in jeder Tabelle.
Wie der zweite dort landet, ist wissenswert, denn es ist keine Nachlässigkeit.
Eine Assistenz, die eine Browser-Komponente mit deiner Datenbank sprechen lassen
soll, schreibt Code, der funktioniert, und wenn dieser Code einen geheimen
Schlüssel braucht, wandert der Schlüssel dorthin, wo der Code läuft. Vite sagt
rundheraus, dass ein Wert mit VITE_-Präfix beim Bauen in deinen Quellcode
gebündelt wird; Next.js tut dasselbe mit NEXT_PUBLIC_. Es warnt dich nichts,
weil du aus Sicht des Werkzeugs genau danach gefragt hast.
Nachzulesen, welchen Schlüssel du hast,
dauert etwa eine Minute.
Die eine Regel, die Code überlebt, den du nicht gelesen hast
Row Level Security, wenn deine Daten in Supabase liegen, ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf.
Deshalb ist das die Prüfung, die sich lohnt. Jede Anfrage erreicht die Datenbank, welche Datei sie auch gestellt und wer diese Datei auch geschrieben hat. Eine dort durchgesetzte Regel gilt für alle auf einmal, einschließlich des Codes aus der Änderung, die du nur überflogen hast. Kein Umfang ungeprüften Codes ändert, was eine nicht angemeldete Anfrage zurückbekommt.
Zwei Dinge entscheiden, ob du sie hast. Supabase aktiviert Row Level Security standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, und nicht für Tabellen, die per SQL angelegt werden, und genau so legt sie eine erzeugte Migration an. Und der Schalter ist nur die halbe Miete: Eine Policy, die alle durchlässt, lässt die Tabelle offen, während das Dashboard sie als gesichert meldet.
So prüfst du dein eigenes Windsurf-Projekt in etwa zehn Minuten
Durchsuche den Build, nicht den Quellcode. Baue das Projekt und such dann in
den Ausgabedateien nach service_role, sb_secret_ und sk_live_. Ein Befehl,
und er deckt jede Datei ab, die die Assistenz angefasst hat, ob du sie geöffnet
hast oder nicht.
Lies die Variablen mit Präfix. Alles, was VITE_… oder NEXT_PUBLIC_…
heißt, ist veröffentlicht. Frag dich bei jedem, ob du es auf deine Startseite
setzen würdest.
Öffne in Supabase Authentication → Policies. Jede Tabelle, die dort mit deaktivierter Row Level Security steht, antwortet jedem, der deine Projektadresse hat, und die steckt in deiner App.
Und dann schau von außen. Die drei Prüfungen oben sagen dir, was konfiguriert ist. Was ein Fremder tatsächlich erreicht, ist eine andere Frage, und die beantwortet unser kostenloser Scan: Er liest deine Live-Seite als Besucher und gibt dir in etwa 20 Sekunden eine Note, ohne Konto: App scannen.
Was zu tun ist
- Prüfe nach Ergebnis, nicht nach Diff. In diesem Tempo ist jede geänderte Zeile zu lesen kein Plan.
- Ausgeliefert wird das gebaute Bundle. Es zu durchsuchen ist schneller und wahrhaftiger als den Quellcode zu lesen, aus dem es kam.
- Ein öffentlicher Schlüssel im Browser ist richtig.
sb_secret_…undservice_rolesind die, die auszutauschen sind. - Eine Assistenz legt einen Schlüssel dorthin, wo der Code, den sie schrieb, ihn braucht. Ihn aus dem Browser zu halten war nie Teil der Anfrage.
- Row Level Security ist die Prüfung, die Code überlebt, den du nie gelesen hast, weil jede Anfrage an der Datenbank vorbei muss.
Baue dein Projekt und durchsuche die Ausgabe nach service_role und sk_live_:
Es dauert eine Minute und gibt eine eindeutige Antwort über die Änderung, die du
nicht gelesen hast. Danach deckt die
Sicherheits-Checkliste in 10 Minuten den Rest ab.
Was bei einer mit Windsurf gebauten App tatsächlich schiefgehen kann
Nichts davon heißt, dass du etwas falsch gemacht hast: Das sind die normalen Nebenwirkungen, wenn ein Agent schnell viel Code schreibt. Das lohnt sich zu prüfen:
Ein geheimer Schlüssel, den der Agent für dich eingebaut hat
Damit eine Integration in einem Durchgang funktioniert, schreibt der Agent den Schlüssel manchmal direkt in den Code, und läuft diese Datei im Browser, kann ihn jeder lesen. Manche Schlüssel gehören dorthin, das ist in Ordnung. Reeve liest den geladenen Code deiner App, findet alle Schlüssel und sagt dir, welche sicher sind und welche auf den Server gehören.
Eine committete .env oder ein offener .git-Ordner
Schlüssel gehören in eine .env-Datei, die nie mit ausgeliefert wird. Aber eine Änderung über Dutzende Dateien bestätigt man leicht, ohne jeden Pfad darin zu lesen, so wandert .env doch in den Commit oder der versteckte .git-Ordner ins Deployment, und deine ganze Historie samt Schlüsseln ist einen Download entfernt. Reeve prüft, ob eins von beidem von außen erreichbar ist.
Deine Datenbank offen gelassen (RLS aus)
Wenn deine App Daten speichert (meist in Supabase oder einem anderen Postgres), entscheidet Row Level Security, wer welche Zeile lesen oder ändern darf. Sie abzuschalten ist ein schneller Weg, ein Feature beim Bauen zum Laufen zu bringen, und bleibt dann gern so. Reeve prüft das, indem es Zeilen zählt, nie indem es sie liest.
Öffentlicher Datei-Speicher
Uploads landen in Speicher-"Buckets", und ein öffentlicher Bucket lässt jeden auflisten und herunterladen, was drin liegt: Rechnungen, Ausweise, private Fotos. Reeve prüft, ob deine Buckets auflistbar sind; es lädt niemals die Dateien von jemandem herunter.
Source Maps angelassen
Eine Source Map gibt jedem, der nachsieht, eine lesbare Kopie deines ursprünglichen Codes. Beim Bauen nützlich, im Live-Betrieb ein Geschenk an Fremde, weil sie jede andere Lücke leichter auffindbar macht. Reeve prüft, ob deine mit ausgeliefert wurden.
Fehlende Sicherheits-Header & offene Endpunkte
Ein paar Einstellungen sagen Browsern, wie sie deine Besucher schützen sollen; davon getrennt ist die Frage, ob deine Daten-Endpunkte jedem und jeder Website antworten. Einzeln ist das klein, zusammen entscheidet es, wie viel ein Fremder mit dem anfangen kann, was er findet. Reeve zeigt, was fehlt.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Inspektor, der die Türen probiert, ohne hineinzugehen. Sie ist schnell und fängt die häufigen, folgenreichen Fehler ab. Sie ist kein vollständiges Sicherheitsaudit, und eine saubere Note ist keine Garantie. Sie bedeutet, dass die offensichtlichen Türen zu sind.
Windsurf ist ein Editor, kein Hoster: Er schreibt und führt Code mit dir aus, aber er deployt deine App nicht und bewacht sie danach auch nicht. Dieser Teil liegt bei dir und bei dem, was der Agent produziert hat. Eine große Änderung durchzusehen, bevor du sie annimmst, ist hier die beste Gewohnheit, und wenn du Supabase nutzt, meldet dessen eigener Advisor Datenbankprobleme. Was Reeve hinzufügt, ist der Blick von außen: was deine ausgelieferte App tatsächlich preisgibt, in klaren Worten, mit denen du etwas anfangen kannst. Und wenn du lieber gar nicht daran denken willst, behalten wir sie für dich im Auge.
Willst du es erledigt, nicht nur geprüft?
Reeve Care behält deine App im Blick, sichert deine Daten und hilft dir, Dinge zu reparieren, wenn sie kaputtgehen, damit du weiterbauen kannst, statt dir Sorgen zu machen.
Mehr über Reeve Care erfahrenFAQ
Ist Code, den Windsurfs Agent schreibt, sicher?
Oft ist es guter Code, aber "der Agent hat es geschrieben" heißt nicht "jemand hat es auf Sicherheit geprüft". Agentische Änderungen optimieren auf ein funktionierendes Ergebnis, und dafür landet schon mal ein Schlüssel an der falschen Stelle oder eine Datenbankregel wird abgeschaltet, um an einem Fehler vorbeizukommen. Sicher weißt du es nur, wenn du nachsiehst, was offenliegt. Reeve macht das kostenlos in etwa 20 Sekunden.
Cascade hat viele Dateien auf einmal geändert. Wie erkenne ich, was jetzt offenliegt?
Durch Lesen meistens nicht. Das ist die ehrliche Antwort, und genau deshalb hilft ein Blick von außen: Statt ein Diff zu prüfen, schaut Reeve auf die App, die du tatsächlich deployt hast, und meldet, was ein Fremder erreichen kann: Schlüssel im Browser, eine offene Datenbank, herunterladbare Dateien, eine offene .env.
Woran erkenne ich, ob meine Windsurf-App API-Schlüssel leakt?
Der übliche Grund ist ein Schlüssel in Code, der im Browser läuft; dort gibt es "versteckt" nicht. Reeve liest den geladenen Code deiner App, findet alle Schlüssel und sagt dir, welche öffentlich sein dürfen und welche auf den Server gehören, ohne die echten Werte je zu speichern.
Ändert das Scannen meiner Windsurf-App irgendetwas?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es meldet sich nie an, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, so wie man prüft, ob eine Tür abgeschlossen ist, ohne einzutreten.
Ein Agent hat Dateien geändert, die ich nie geöffnet habe. Wie soll ich das prüfen?
Nicht Zeile für Zeile, das ist die ehrliche Antwort. Prüfe stattdessen nach Ergebnis: Baue das Projekt und durchsuche die Ausgabe nach den Formen geheimer Schlüssel, und sieh dann nach, was deine Datenbank auf eine Anfrage ohne Anmeldung zurückgibt. Beides dauert Minuten, und beides fängt die zwei Fehler, auf die es wirklich ankommt, egal wie viele Dateien sich geändert haben.
Legt eine KI-Assistenz absichtlich Geheimnisse in mein Frontend?
Sie legt sie dorthin, wo der Code, den sie geschrieben hat, sie braucht. Wurde eine Komponente, die im Browser läuft, so geschrieben, dass sie etwas aufruft, das einen geheimen Schlüssel verlangt, muss der Schlüssel im Browser sein, damit dieser Code funktioniert, also sorgt die Assistenz dafür, dass er funktioniert. Die Anweisung, ihn auf einem Server zu lassen, stand nie in der Anfrage.
Welche einzelne Prüfung sagt mir am meisten über meine App?
Ob Row Level Security für jede Tabelle an ist und ob die Policies tatsächlich irgendjemanden einschränken. Es ist die eine Regel, die für jede Anfrage gilt, egal welche Datei sie gestellt hat, und deshalb überlebt sie beliebig viel Code, den du nicht gelesen hast.