Ich habe mit Vibe Coding einen API-Schlüssel für das Frontend geschrieben und wurde schließlich gehackt, wofür mir eine hohe Gebühr berechnet wurde. Hier sind einige Beispiele und Sicherheitsmaßnahmen.

Ich habe mit Vibe Coding einen API-Schlüssel für das Frontend geschrieben und wurde schließlich gehackt, wofür mir eine hohe Gebühr berechnet wurde. Hier sind einige Beispiele und Sicherheitsmaßnahmen.

„Vibe-Coding“, zum schnellen Erstellen einer App mit Schwerpunkt auf deren „Funktionsfähigkeit“, erfreut sich als moderner Entwicklungsstil zunehmender Beliebtheit.

Insbesondere die Verwendung von BaaS wie Supabase oder Firebase ermöglicht Ihnen die Durchführung von Authentifizierungs- und Datenbankvorgängen mit nur wenigen Codezeilen, was es für schnelles Prototyping und die Verbesserung der Benutzeroberfläche sehr nützlich macht.

Andererseits können jedoch leicht gefährliche Fehler passieren, beispielsweise das Schreiben von API-Schlüsseln oder geheimen Informationen direkt in das Frontend wodurch das Risiko unerwarteter Hackerangriffe oder hoher Rechnungen besteht .

Dieser Artikel verwendet tatsächliche Beispiele und Demonstrationen, um klar zu erklären, warum Sie den privaten Schlüssel nicht in das Frontend schreiben sollten.
spezifische Maßnahmen und Designpunkte vorstellen , um sowohl Vibe-Codierung als auch Sicherheit zu erreichen

Wenn Sie mit Vibes programmieren, ist dies ein Muss!

Dies ist eine Sicherheitsbibel, die jeder Webanwendungsentwickler mindestens einmal lesen sollte.
Lernen Sie systematisch die Prinzipien von Angriffen und Gegenmaßnahmen kennen und legen Sie den Grundstein für das Schreiben von sicherem Code.

*Die Links enthalten Affiliate-Links. Wir hoffen, dass diese beim Kauf von Büchern hilfreich sind.

Inhaltsverzeichnis

Was ist Vibecoding? Risiken, die oft zugunsten der Effizienz übersehen werden

Heutzutage hört man oft von „Vibe Coding“.
Grob gesagt handelt es sich dabei um einen Entwicklungsstil, bei dem es darum geht, „es einfach zum Laufen zu bringen“, und der durch KI und praktische Tools unterstützt wird, um die Dinge in einem guten Tempo voranzutreiben.

Wenn Sie beispielsweise Supabase oder Firebase verwenden, können Sie die Anmeldung, die Datenbankverbindung und die Anzeige an einem Ort im Frontend schreiben und die Ergebnisse sofort im Browser sehen.
Wenn Sie dieses Gefühl erleben, werden viele Leute vorschnell denken: „Es funktioniert, also ist das in Ordnung!“, ohne gründlich über Design und Sicherheit nachzudenken.

Wenn Sie es jedoch ohne jede Überlegung einsetzen, können
unerwartete Fallstricke Tatsächlich gibt es viele Fälle, in denen wichtige Informationen wie API-Schlüssel im Front-End vollständig sichtbar sind.

Es gibt mehr Menschen als man denkt, die Dinge einsetzen, nur weil sie „funktionieren“, und der Welt gefährliche Informationen preisgeben.

Ist diese Schreibweise eigentlich falsch?

Da KI-gestütztes Programmieren mittlerweile zum Standard geworden ist, kommt es immer häufiger vor, dass der Programmierer das Risiko nicht erkennt.
Der Code funktioniert, ist fehlerfrei und wurde von einer KI erstellt. In diesem Fall ist er noch weniger verdächtig.

Wenn Sie beispielsweise API-Schlüssel und Token direkt im Frontend schreiben oder kein Backend erstellen und alles im Frontend verarbeiten lassen,
funktioniert dies möglicherweise zunächst, kann jedoch in Wirklichkeit leicht von außen ausgenutzt werden .

Die Anhäufung dieser „Dinge, die wir unwissentlich tun“ ernsthaften Problemen wie Informationslecks und hohen Rechnungen führen

Was passiert, wenn Sie einen API-Schlüssel im Frontend schreiben?

generiert häufig Code, der alles von Anmeldeprozessen bis hin zur Verbindung mit externen APIs

An diesem Punkt schlägt die KI „natürlich“ eine Konfiguration vor, in der geheime Informationen wie API-Schlüssel und Authentifizierungstoken auf dem Frontend gespeichert werden .

Auf den ersten Blick scheint es korrekt zu funktionieren und sieht normal aus,
aber wenn Sie es mit dieser Konfiguration bereitstellen, werden Geheimnisse, die auf der Serverseite sicher aufbewahrt werden sollten, offengelegt und für die Browser der Benutzer sichtbar.

Was passiert, wenn das Geheimnis an der Front liegt?

  • Sie können ihn ganz einfach extrahieren, indem Sie über einen Browser darauf zugreifen
    → Auch wenn er nicht auf dem Bildschirm angezeigt wird, können Sie den Schlüssel erhalten, indem Sie sich den Kommunikationsinhalt und den Code ansehen.
  • Dieser Schlüssel ermöglicht es „anderen Personen“, externe Dienste zu betreiben.
    → Normalerweise eingeschränkte Vorgänge wie Datenbankzugriff, KI-API und E-Mail-Versand sind jetzt vollständig geöffnet.
  • Pay-per-Use-APIs führen zu sofortigen und hohen Gebühren
    . Die betrügerische Verwendung von ChatGPT und die externe E-Mail-Verteilung können zu Gebühren von Zehntausenden bis Hunderttausenden Yen pro Nacht führen.
  • Fälle, in denen das Durchsickern von Geheimnissen direkt zu Datenlecks führt
    → Beispielsweise kann in Fällen wie Supabase die gesamte Datenbank mit nur einem Schlüssel gelesen werden.

„Ein Geheimnis an der Rezeption zu hinterlassen“ ist wie „den Hausschlüssel vor dem Ausgehen an die Haustür zu stecken“.

Aktuelle Schadensfälle: Probleme durch geleakte API-Schlüssel

Sie denken vielleicht: „Ist es wirklich so schlimm, nur weil ein API-Schlüssel auf der Startseite steht?“
jedoch mehrere Fälle, in denen durch API-Schlüssel in Projekten, die eigentlich aus Vibe-Coding entstanden waren, schwerwiegende Schäden entstanden sind .

Echter Schaden durch Lovable.dev

Lovable.dev gewinnt als KI-Plattform für „Vibe Coding“ zunehmend an Aufmerksamkeit .
Entwickler können damit zwar Apps nahezu ohne Code erstellen, doch in einigen Fällen wurde das Sicherheitsdesign vernachlässigt.

Es gibt mehrere gemeldete Fälle, in denen
vertrauliche Informationen wie Authentifizierungsschlüssel und E-Mail-Adressen in einigen mit Lovable.dev veröffentlichten Apps Tatsächlich gibt es bestätigte Fälle, in denen geheime Schlüssel für die OpenAI-API und die Google Maps-API in das Front-End eingebettet waren, was zu einer unbefugten Nutzung führte .

an nur einem Tag Anfragen im Wert von mehreren zehntausend Yen generiert wurden . Dies könnte unmittelbare finanzielle Auswirkungen haben, insbesondere bei Projekten, die kostenpflichtige APIs verwenden.

Die Hälfte der Vibe-codierten Websites legt API-Schlüssel offen

In einer anderen Studie wurden über 2.000 Vibe-codierte Websites gescannt und festgestellt, dass bei etwa 49,5 % davon Geheimnisse wie API-Schlüssel, JWTs und Google-API-Schlüssel von vorne herein offengelegt wurden .

Dies zeigt , dass in vielen Fällen die Priorität einfach darin besteht, den Code zum Laufen zu bringen, und dass es an den grundlegenden Sicherheitsmaßnahmen mangelt

Eine kurze Demo: Ist Ihr API-Schlüssel wirklich unsichtbar?

Hier stellen wir drei gängige Implementierungsmuster für den Umgang mit API-Schlüsseln vor (zwei falsche und ein richtiges Beispiel).
Auch wenn man auf den ersten Blick denkt, dass es gut funktioniert, kann es tatsächlich ein ernstes Sicherheitsrisiko darstellen.

  • Falsches Beispiel 1:
    Festcodierung des API-Schlüssels im Frontend. Dies ist ein häufiges Fehlbeispiel. Jeder kann den Schlüssel durch einen Blick in den Code herausfinden.
  • Falsches Beispiel 2 : Definieren des API-Schlüssels in .env.
    Manchmal sagen die Leute: „Es gibt kein Problem, wenn ich es in .env definiere“, aber das ist nicht anders als falsches Beispiel 1.
  • .env
    auf der Serverseite über die API und die Kommunikation mit dem Front-End über die API wird der Schlüssel dem Benutzer nicht angezeigt.

Falsches Beispiel 1: Schreiben des API-Schlüssels direkt auf die Vorderseite

Zunächst einmal sollten Sie den Schlüssel niemals direkt in den Code schreiben .

// app/page.tsx "use client"; importiere { useState } von "react"; const openaiApiKey = "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; // ← ⚠️ Achtung! Schreibe es direkt ins Frontend! exportiere Standardfunktion Seite() { const [Eingabe, setInput] = useState(""); const [Antwort, setResponse] = useState(""); const handleSubmit = async () => { const res = await fetch("https://api.openai.com/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${openaiApiKey}`, }, body: JSON.stringify({ model: "gpt-3.5-turbo", messages: [{ role: "user", content: input }], }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Keine Antwort."; setResponse(text); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 ChatBot-Demo (gefährliches Implementierungsbeispiel)</h1><input type="text" placeholder="メッセージを入力..." value={input} onChange={(e) => setInput(e.target.value)} className="w-full p-2 border border-gray-300 rounded" /> <button onClick={handleSubmit} className="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700" >Sende</button> {Antwort && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>KI-Antwort:</strong> {response}</div> )}</main> ); }

Wenn Sie den Schlüssel direkt im Frontend schreiben, wird er nach dem Build in die JavaScript-Datei aufgenommen.
also veröffentlichen, kann sie jeder in einem Browser anzeigen .

in Chrome DevTools die Registerkarte „Quellen“ , können Sie die verteilte Bundle-Datei so anzeigen, wie sie ist.
sk- there , können Sie schnell den fest codierten API-Schlüssel finden.

Falsches Beispiel ② : Definieren eines API-Schlüssels in .env

Manche Leute glauben, dass es sicher ist, es in .env zu schreiben, aber wenn Sie direkt vom Front-End-Code darauf verweisen, wird es letztendlich in das erstellte JavaScript eingebettet und öffentlich gemacht.

Wenn Sie beispielsweise den folgenden Code erstellen:

.env

# .env NEXT_PUBLIC_OPENAI_KEY=sk-yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

Seite.tsx

// app/page.tsx "use client"; import { useState } from "react"; const openaiApiKey = process.env.NEXT_PUBLIC_OPENAI_KEY; // ← ⚠️ Gefährlich! Sogar in .env ist dies die NG-Export-Standardfunktion Page() { const [input, setInput] = useState(""); const [response, setResponse] = useState(""); const handleSubmit = async () => { const res = await fetch("https://api.openai.com/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${openaiApiKey}`, }, body: JSON.stringify({ model: "gpt-3.5-turbo", messages: [{ role: "user", content: input }], }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Keine Antwort."; setResponse(text); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 ChatBot-Demo (gefährliches Implementierungsbeispiel)</h1><input type="text" placeholder="メッセージを入力..." value={input} onChange={(e) => setInput(e.target.value)} className="w-full p-2 border border-gray-300 rounded" /> <button onClick={handleSubmit} className="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700" >Sende</button> {Antwort && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>KI-Antwort:</strong> {response}</div> )}</main> ); }

process.env.NEXT_PUBLIC_OPENAI_KEY , wird dessen Wert während des Builds als Zeichenfolge erweitert.
Mit anderen Worten: .env , wird es tatsächlich in die Front-End-JavaScript-Datei aufgenommen und ist für Benutzer frei sichtbar.

Wenn Sie das verteilte Paket auf der Registerkarte „Quellen“ Ihres Browsers sk- unverändert eingebettet sind.
.env dieselben Risiken , solange Sie vom Front-End darauf verweisen, .

Darüber hinaus wird der Schlüssel beim Aufruf einer API dem Autorisierungsheader hinzugefügt
daher die Registerkarte „Netzwerk“ . Dies entspricht der Veröffentlichung des Schlüssels für alle Benutzer.

Richtig: Über API

.env definierten Schlüssel nicht
direkt vom Frontend referenziert werden Wenn Sie die API-Routen und Routenhandler von Next.js verwenden, sendet der Client nur „Benutzereingaben“, und der OpenAI-API-Schlüssel wird niemals veröffentlicht. (Dieselbe Konfiguration funktioniert auch bei der Bereitstellung in Vercel usw. sicher.)

Wenn Sie beispielsweise den folgenden Code erstellen:

.env

OPENAI_API_KEY=sk-zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

route.ts

// app/api/ai/route.ts importiere { NextResponse } von "next/server"; exportiere asynchrone Funktion POST(req: Request) { versuche { const { Eingabe } = warte auf req.json(); const apiKey = process.env.OPENAI_API_KEY; // Nur serverseitig, nicht verfügbar, wenn (!apiKey) { returniere NextResponse.json( { Fehler: "Server-Fehlkonfiguration: OPENAI_API_KEY fehlt" }, { Status: 500 } ); } const r = warte auf fetch("https://api.openai.com/v1/chat/completions", { Methode: "POST", Header: { Autorisierung: `Bearer ${apiKey}`, "Content-Type": "application/json", }, Body: JSON.stringify({ Modell: "gpt-4o-mini", Nachrichten: [{ Rolle: "Benutzer", Inhalt: Eingabe }], }), }); const data = warte auf r.json(); returniere NextResponse.json(Daten, { Status: r.status }); } catch (e) { console.error(e); returniere NextResponse.json({ Fehler: "Ungültige Anfrage" }, { Status: 400 }); } }

Seite.tsx

// app/page.tsx "Client verwenden"; importiere { useState } von "reagieren"; exportiere Standardfunktion Page() { const [Eingabe, Eingabe festlegen] = useState(""); const [Antwort, Antwort festlegen] = useState(""); const handleSubmit = async () => { const res = warte auf fetch("/api/ai", { Methode: "POST", Header: { "Content-Type": "application/json" }, Body: JSON.stringify({ Eingabe }), }); const data = warte auf res.json(); const text = data.choices?.[0]?.message?.content ?? "Keine Antwort."; Antwort festlegen(Text); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 ChatBot-Demo (über sichere API)</h1><input type="text" value={input} onChange={(e) => setInput(e.target.value)} className="w-full p-2 border border-gray-300 rounded" /> <button onClick={handleSubmit} className="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700" >Sende</button> {Antwort && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>KI-Antwort:</strong> {response}</div> )}</main> ); }

Natürlich gibt es auf der Front-End-Seite keinen API-Schlüssel, Sie werden ihn also auch dann nicht finden, wenn Sie auf die Registerkarte „Quellen“ schauen.

Darüber hinaus ist der Autorisierungsheader nicht in der Registerkarte „Netzwerk“ enthalten und da die Serverseite die Anfrage in Ihrem Namen an OpenAI stellt, wird sie nicht an den Benutzer weitergegeben.

Lösung: Proxy-Anfragen vom Server

Wie Sie den obigen Beispielen entnehmen können, die Handhabung von API-Schlüsseln auf dem Front-End äußerst gefährlich.
Stellen Sie daher sicher API-Schlüssel nur auf der Serverseite lesen

Wenn das Front-End nur Benutzereingaben an den Server sendet und der Server in Ihrem Namen Anfragen an die OpenAI-API stellt , wird der API-Schlüssel nicht an die Außenwelt weitergegeben. Dies die einfachste und sicherste Vorgehensweise .

  • ❌Handschriftlich → Jeder kann den Schlüssel aus dem Quellcode oder Kommunikationsinhalten kopieren
  • .env → Nach dem Build eingebettet, sodass es jeder sehen kann
  • ✅Proxy -Anfragen über den Server → Schlüssel werden nie preisgegeben

Wenn die Informationen auch nur für einen Moment nach außen dringen, kann es durch betrügerische Verwendung zu einer Rechnung von Hunderttausenden bis Hunderttausenden Yen kommen

Es gibt viele
weitere Risiken für Geheimnisse, die unerwartet preisgegeben werden können das versehentliche Veröffentlichen einer .env- . Da Geheimnisse der Öffentlichkeit zugänglich gemacht werden können, ohne dass Sie es merken, sollten Sie beim Umgang mit Geheimnissen wie API-Schlüsseln stets vorsichtig sein .

Ich habe auch einen Artikel veröffentlicht, der diese Methode zur angemessenen Behebung von Sicherheitsproblemen verwendet.
Detaillierte Code- und Bereitstellungsbeispiele finden Sie in diesem Artikel.

Wenn Sie mit Vibes programmieren, ist dies ein Muss!

Wenn Sie bis hierher gelesen haben und denken: „Oh nein, vielleicht habe ich nicht auf die Sicherheit geachtet“, machen Sie sich keine Sorgen, Sie haben noch Zeit.
gibt es eine Bibel, die Sie mindestens einmal lesen sollten, unabhängig von Ihrer Position

Es „Systematically Learning How to Create Secure Web Applications, 2. Auflage“ (Autor: Tokumaru Hiroshi) .

erklärt
die Grundlagen der Sicherheit – „Warum ist sie gefährlich?“ und „Wie kann sie verhindert werden?“ – von den Prinzipien der Schwachstelle bis hin zu Beispielen und Gegenmaßnahmen ein wirklich „systematisches“ Buch, das Ihnen die Besonderheiten des Angriffsablaufs und die wichtigsten Punkte der Verteidigung vermittelt.

Auch wenn Sie es nicht in die Praxis umsetzen, können Sie durch den Erwerb eines Mindestmaßes an Wissen schwere Unfälle verhindern .
Wenn ein paar Tausend Yen Risiken von Hunderttausenden bis Hunderttausenden von Yen verhindern können, gibt es keinen Grund, es nicht zu lesen.

Wenn Sie mit Vibes programmieren, ist dies ein Muss!

Dies ist eine Sicherheitsbibel, die jeder Webanwendungsentwickler mindestens einmal lesen sollte.
Lernen Sie systematisch die Prinzipien von Angriffen und Gegenmaßnahmen kennen und legen Sie den Grundstein für das Schreiben von sicherem Code.

*Die Links enthalten Affiliate-Links. Wir hoffen, dass diese beim Kauf von Büchern hilfreich sind.

Wenn Sie den Inhalt schwierig finden,
eine gute Idee, ihn von einem erfahrenen Ingenieur überprüfen zu lassen .

Schauen wir es uns nun endlich an

Wie in diesem Artikel erläutert, ist die Handhabung von API-Schlüsseln im Frontend äußerst gefährlich .
Selbst wenn etwas scheinbar ordnungsgemäß funktioniert, kommt es nicht selten vor, dass der API-Schlüssel tatsächlich der ganzen Welt zugänglich ist.

Sie beispielsweise wirklich, wie
die App „mit Vibes codiert“ haben Wenn Sie immer noch Unklarheiten haben, sollten Sie das Design umgehend überprüfen und sicherstellen, dass es sicher ist .

Mithilfe von KI
können viele Menschen heute Code schreiben und sich dabei sicher sein: „Das kann ich auch.“ Es mag zwar so aussehen, als ob es gut funktioniert,
aber wenn Sie die Sicherheit vernachlässigen und Ihr API-Schlüssel durchsickert, besteht die Gefahr, dass Ihnen ein hoher Betrag in Rechnung gestellt wird.
In diesem Fall tragen Sie

Teilen Sie, wenn Sie möchten!

Wer hat diesen Artikel geschrieben

Dies ist ein Blog, in dem ich angefangen habe, Informationssicherheit zu studieren. Als neuer Angestellter würde ich mich freuen, wenn Sie mit einem breiten Herzen schauen könnten.
Es gibt auch Teech Lab, das eine Gelegenheit ist, Programmierspaß zu studieren. Wenn Sie also an der Softwareentwicklung interessiert sind, sollten Sie sich unbedingt ansehen!

Inhaltsverzeichnis