Website-Sicherheit für Vibecoder: 4 Lücken, die du schließen musst

Was heißt „Website schützen“ in einfachen Worten

Deine Website ist ein Haus. Drinnen liegen deine Sachen, Nutzerdaten, manchmal deren Geld. Und jetzt stell dir vor, du:

• hast das Passwort vom Safe mit Edding direkt auf die Haustür geschrieben;
• hast ein krasses Schloss eingebaut, aber den Schlüssel im Schloss stecken lassen;
• lässt jeden rein, der „ich gehör dazu“ murmelt, ohne ihm ins Gesicht zu schauen.

Verrückt? Genau so sieht eine Website aus, die eine KI generiert hat, wenn ihr niemand ein Wort über Sicherheit gesagt hat. Der Agent sorgt standardmäßig dafür, dass es funktioniert. Nicht dafür, dass es sicher ist. Das sind zwei verschiedene Aufgaben, und die zweite musst du extra bestellen.

Wer braucht schon meine kleine Landingpage? Wozu überhaupt schützen

„Ich mach doch nur eine Landingpage, wer interessiert sich schon für mich?“ - der häufigste Anfänger-Gedanke. Und der teuerste. So sieht es nämlich wirklich aus:

• Bots scannen das ganze Internet rund um die Uhr. Denen ist egal, wer du bist. Sie suchen offene Türen automatisch - millionenfach pro Stunde.
• Hat deine Website ein Formular? Selbst ein simples „gib deine E-Mail ein“ ist schon ein Einfallstor.
• Ist ein API-Key API-Key - ein geheimes Passwort, über das deine Website mit anderen Diensten kommuniziert: Bezahlung, Newsletter, KI. Wenn er leakt, geben Fremde Geld in deinem Namen aus. von einem Bezahldienst geleakt - dann verbraten dir Fremde dein Geld, während du selig schläfst.
• Und sind Nutzerdaten geleakt, ist das kein „Ups“ mehr. Das sind Strafen, Stress und ein Ruf in Scherben.

Die gute Nachricht: Du musst kein Cybersecurity-Guru werden. Du musst die vier wichtigsten Lücken kennen und den Agenten bitten können, sie zu schließen. Genau das machen wir jetzt.

Die vier wichtigsten Sicherheitslücken einer Website

ECC hat einen Skill security-review - eine Checkliste, mit der der Agent den Code vor der Veröffentlichung prüft. Ziehen wir das Wichtigste und Häufigste daraus.

1. Wo bewahrt man API-Keys und Passwörter (Secrets) auf

Ein Secret Secret - jedes Passwort, Token oder jeder Key: Zugang zur Datenbank, zum Bezahldienst, zur API. Alles, was Macht über deinen Service gibt. ist der Schlüssel zum Haus. Die Regel ist eine und ganz einfach: der Schlüssel liegt nicht offen im Haus rum.

So machen es Anfänger (und so solltest du es NICHT machen):

const apiKey = "sk-proj-xxxxx" - der Key steckt direkt im Code. Und Code lebt oft in Git. Git ist oft öffentlich. Und schon ist der Key nicht mehr deiner.

Und wie macht man es richtig? Die Keys liegen in einer separaten Datei (meist .env.local), und im Code steht nur eine Referenz darauf - process.env.OPENAI_API_KEY. Und diese Datei mit den Keys ist unbedingt in der .gitignore eingetragen, damit sie niemals in Git landet.

2. Nutzereingaben und Datei-Uploads prüfen

Alles, was der User eingibt - Text in einem Formular, eine hochgeladene Datei, eine Seitenadresse - musst du prüfen, bevor du irgendwas damit machst. Die Regel in einer Zeile: trau der Eingabe nicht standardmäßig.

Das gilt besonders für Datei-Uploads. Hast du ein „Lad deinen Avatar hoch“? Dann prüft der Agent laut Checkliste drei Dinge:

• Größe - zum Beispiel maximal 5 Megabyte. Sonst lädt dir jemand eine Gigabyte-Datei hoch und legt dir sauber den Server lahm;
• Typ - nur Bilder: jpeg, png, gif. Und keine ausführbare Virus-Datei, die sich als Katzenbild tarnt;
• Endung - .jpg, .png. Und nicht .exe, dem man einen Bildnamen verpasst hat.

Und noch eine Regel aus der Checkliste: prüf per Whitelist („nur genau das ist erlaubt“), nicht per Blacklist („das ist verboten“). Eine Blacklist ist immer löchrig. Du kannst unmöglich alles Schlechte der Welt auflisten, und dem Hacker reicht eine einzige übersehene Variante.

3. Zugriffsrechte: prüf auf dem Server, wer darf

Die Lieblingsfalle der Anfänger: „Ich hab den Löschen-Button einfach vor normalen Usern versteckt - also ist es sicher.“ Nein. Einen Button zu verstecken ist, als würdest du eine Tür mit einem Vorhang verhängen. Den Button sieht man nicht, aber die Tür ist offen: wer die Adresse kennt, kommt rein.

Und wie geht es richtig? Eine Prüfung auf dem Server vor jeder wichtigen Aktion. Bevor fremde Daten gelöscht, geändert oder angezeigt werden, muss der Code fragen: „Hat diese Person überhaupt das Recht dazu?“ Zum Beispiel vergewissert sich der Server vor dem Löschen eines Users erst, dass die Anfrage von einem Admin kommt, und fasst erst dann irgendwas an.

4. Sichere Fehler und Logs: plapper nicht zu viel

Wenn etwas kaputtgeht, darf die Website dem User nicht die Eingeweide rauskippen - einen detaillierten Fehler mit Tabellennamen, Dateipfaden und Codeschnipseln. Das ist eine fertige Landkarte für den Einbrecher. Dem User - ein höfliches „Ups, versuch’s später nochmal“. Und alle Details - nur in die Logs auf dem Server, wo kein Fremder rankommt.

Und die Spiegelregel: in die Logs dürfen keine Secrets gelangen. Logge keine Passwörter, Kartennummern, CVV und Token. Leakt so ein Log - und du servierst dem Hacker selbst alles auf dem Silbertablett.

Sichere Website gegen löchrige: der Vergleich

Wie eine Website gehackt wird: ein Beispiel aus dem Leben

Du hast mit dem Agenten einen kleinen Shop gebaut: Katalog, Bestellformular, Foto-Upload fürs Produkt, Bezahlung über einen externen Dienst. Alles läuft, du bist zufrieden, lädst es auf GitHub und veröffentlichst es. Und zwei Tage später:

1. Es flattert eine Rechnung vom Bezahldienst über einen Haufen Geld rein - weil der Key direkt im Code lag und die Bots ihn aus deinem öffentlichen Repository gefischt haben.
2. Der Server japst nach Luft - jemand hat über „Produktfoto“ riesige fremde Dateien hochgeladen, weil Größe und Typ niemand geprüft hat.
3. Ins Admin-Panel ist ein Fremder gelangt - der ganze Schutz hing an „den Link sieht man nicht“, und er hat einfach die Adresse /admin erraten.

Nichts davon wäre passiert, hättest du den Agenten gebeten, von Anfang an an Sicherheit zu denken. Und so geht das mit einem einzigen Prompt:

Mach ein security-review meines Projekts vor der Veröffentlichung. Prüf anhand der Checkliste:

Secrets: keine Passwörter, API-Keys und Token direkt im Code. Alles muss in .env.local liegen, und .env.local selbst in .gitignore.
Nutzereingaben: wird jede Eingabe geprüft. Bei Datei-Uploads begrenze Größe, Typ und Endung per Whitelist.
Zugriffsrechte: gibt es vor jeder wichtigen Aktion (Löschen, Ändern, fremde Daten) eine Rechteprüfung auf dem Server, nicht nur einen versteckten Button.
Fehler und Logs: dem User werden allgemeine Meldungen gezeigt, in die Logs gelangen keine Passwörter und Kartennummern.
Zeig die Liste der gefundenen Probleme in einfachen Worten und schlag vor, wie man jedes davon repariert.

Häufige Anfängerfehler bei der Sicherheit

• „Mich braucht niemand.“ Bots scannen automatisch alle reihenweise. Die Größe der Website spielt dabei überhaupt keine Rolle.
• Key im Code plus öffentliches Git. Der Klassiker. Secrets gehören in .env.local, die Datei in .gitignore.
• Schutz nach dem Motto „Button nicht sichtbar“. Im Interface verstecken heißt nicht schützen. Die Rechteprüfung lebt auf dem Server.
• Das Formular nimmt alles an. Prüf Eingaben und Dateien per Whitelist, nicht nach dem Prinzip „wird schon gutgehen“.
• Kompletter Fehlertext direkt ins Gesicht des Users. Das ist eine Landkarte für den Einbrecher. Ihm gibst du ein „Ups“, die Details kommen in die Logs.
• Passwörter und Kartendaten loggen. Leakt das Log, leakt alles. Secrets haben in Logs nichts zu suchen.
• Ohne Review veröffentlichen. Ein einziger Prompt security-review fängt die meisten Anfänger-Lücken und kostet keinen Cent.