J'ai écrit une clé API en front-end avec Vibe Coding, et j'ai fini par être piraté et me faire payer des frais élevés. Voici quelques exemples et mesures de sécurité.

Le « Vibe coding », permettant de créer rapidement une application en mettant l'accent sur sa « mise en œuvre », gagne en popularité en tant que style de développement moderne.

En particulier, l'utilisation de BaaS tels que Supabase ou Firebase vous permet de réaliser des opérations d'authentification et de base de données avec seulement quelques lignes de code, ce qui le rend très utile pour le prototypage rapide et l'amélioration de l'interface utilisateur.

Cependant, d'un autre côté, il est facile de commettre des erreurs dangereuses telles que l'écriture de clés API ou d'informations secrètes directement sur le front-end ce qui présente un risque de piratage inattendu ou de factures élevées .

Cet article s'appuie sur des exemples concrets et des démonstrations pour expliquer clairement pourquoi il est déconseillé d'écrire la clé privée sur le front-end.
présenterons des mesures et des points de conception spécifiques pour garantir à la fois le codage Vibe et la sécurité

Qu'est-ce que le Vibecoding ? Risques souvent négligés au profit de l'efficacité

On entend souvent parler de « vibe coding » ces temps-ci.
En gros, il s'agit d'un style de développement qui privilégie le simple fait de « faire fonctionner » et qui s'appuie sur l'IA et des outils pratiques pour maintenir un rythme soutenu.

Par exemple, si vous utilisez Supabase ou Firebase, vous pouvez créer les identifiants de connexion, les connexions à la base de données et les afficher au même endroit depuis le front-end, et voir les résultats immédiatement dans le navigateur.
Face à ce sentiment, beaucoup se précipitent en se disant : « Ça marche, donc c'est bon ! » sans réfléchir sérieusement à la conception et à la sécurité.

Cependant, si vous le déployez sans y prêter attention, vous risquez de rencontrer
des difficultés inattendues En effet, il existe de nombreux cas où des informations importantes, telles que les clés API, sont exposées en plein écran depuis le front-end.

Il y a plus de gens qu'on ne le pense qui déploient des choses simplement parce qu'elles « fonctionnent » et exposent des informations dangereuses au monde.

Cette façon d’écrire est-elle vraiment mauvaise ?

Maintenant qu'il est courant de recourir à l'IA pour coder, il y a de plus en plus de cas où le développeur ignore le risque.
Le code fonctionne, il ne comporte aucune erreur et a été généré par une IA… Dans ce cas, il est encore moins susceptible d'être suspect.

Par exemple, si vous écrivez des clés API et des jetons directement dans le front-end, ou si vous ne créez pas de back-end et que tout est traité sur le front-end, cela
peut fonctionner au début, mais en réalité, cela peut être facilement exploité de l'extérieur .

L’accumulation de ces « choses que nous faisons sans le savoir » peut parfois entraîner de graves problèmes tels que des fuites d’informations et des factures élevées

Que se passe-t-il lorsque vous écrivez une clé API sur le front-end ?

génère souvent du code qui gère tout, des processus de connexion à la connexion aux API externes

À ce stade, l'IA suggérera « naturellement » une configuration dans laquelle des informations secrètes telles que les clés API et les jetons d'authentification sont stockées sur le front-end .

À première vue, cela semble fonctionner correctement et semble normal,
mais si vous le déployez avec cette configuration, les secrets qui doivent être conservés en toute sécurité côté serveur seront exposés et visibles pour les navigateurs des utilisateurs.

Que se passe-t-il lorsque le secret est au premier plan ?

« Laisser un secret à la réception » c'est comme « coller sa clé de maison sur sa porte d'entrée avant de sortir ».

Cas de dommages réels : problèmes causés par des fuites de clés API

Vous vous demandez peut-être : « Est-ce vraiment si grave simplement parce qu'une clé API est en première page ? »
Pourtant, plusieurs cas de dommages graves ont été recensés à cause de clés API dans des projets issus du code Vibe .

Dégâts réels causés par Lovable.dev

Lovable.dev attire de plus en plus l'attention en tant que plateforme de « vibe coding » d'IA .
Si elle permet aux développeurs de créer des applications presque sans code, la conception sécuritaire a parfois été négligée.

Plusieurs cas ont été signalés où
des informations sensibles, telles que des clés d'authentification et des adresses e-mail, ont été rendues publiques dans certaines applications publiées via Lovable.dev même été constatés où des clés secrètes des API OpenAI et Google Maps ont été intégrées au front-end, entraînant une utilisation non autorisée .

des demandes valant des dizaines de milliers de yens ont été générées en une seule journée , ce qui pourrait avoir un impact financier immédiat, en particulier pour les projets qui utilisent des API payantes.

La moitié des sites codés par Vibe exposent des clés API

Une autre étude a analysé plus de 2 000 sites codés par Vibe et a découvert qu'environ 49,5 % d'entre eux avaient des secrets tels que des clés API, des JWT et des clés API Google exposés de front .

Cela montre que dans de nombreux cas, la priorité est simplement de faire « fonctionner » le code, et les fondamentaux de sécurité font défaut

Vous pouvez également lire

Vos sites Vibe Coded révèlent-ils des secrets ? Comment j'ai analysé 2 000 sites créés avec Vibe Tools et ce que j'ai découvert…

Une démonstration rapide : votre clé API est-elle vraiment invisible ?

Nous allons ici présenter trois modèles d'implémentation courants pour la gestion des clés API (deux exemples incorrects et un exemple correct).
Même si vous pensez que cela fonctionnera correctement à première vue, cela peut en réalité présenter un risque de sécurité important.

• Exemple erroné n° 1 :
  Coder en dur la clé API sur le front-end. Il s'agit d'un exemple erroné courant. N'importe qui peut trouver la clé en consultant le code.
• Exemple incorrect 2 : Définition de la clé API dans .env
  Parfois, les gens disent : « Il n'y a pas de problème si je le définis dans .env », mais ce n'est pas différent de l'exemple incorrect 1.
• .env
  côté serveur via l'API et en communiquant avec le front-end via l'API, la clé ne sera pas exposée à l'utilisateur.

Exemple incorrect 1 : écriture de la clé API directement sur le front

Tout d’abord, la chose que vous ne devriez jamais faire d’écrire la clé directement dans le code .

// app/page.tsx "use client"; import { useState } from "react"; const openaiApiKey = "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; // ← ⚠️ Danger ! Écrivez-le directement sur le frontend ! export default function 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 ?? "Aucune réponse."; setResponse(text); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 Démonstration de ChatBot (exemple d'implémentation dangereuse)</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" >Envoyer</button> {réponse && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Réponse de l'IA :</strong> {response}</div> )}</main> ); }

Si vous écrivez la clé directement dans le frontend, elle sera incluse dans le fichier JavaScript après la construction,
donc si vous publiez l'application, tout le monde peut la visualiser à partir d'un navigateur .

l'onglet « Sources » dans Chrome DevTools , vous pouvez visualiser le fichier de bundle distribué tel quel.
« sk- there » , vous trouverez rapidement la clé API codée en dur.

Exemple incorrect 2 : Définition d'une clé API dans .env

Certaines personnes pensent qu'il est sûr de l'écrire dans .env, mais si vous le référencez directement à partir du code front-end, il finira par être intégré dans le JavaScript construit et rendu public.

Par exemple, si vous créez le code suivant :

.env

# .env NEXT_PUBLIC_OPENAI_KEY=sk-yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

page.tsx

// app/page.tsx "use client"; import { useState } from "react"; const openaiApiKey = process.env.NEXT_PUBLIC_OPENAI_KEY; // ← ⚠️ Dangereux ! Même dans .env, c'est NG export default function 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 ?? "Aucune réponse."; setResponse(text); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 Démonstration de ChatBot (exemple d'implémentation dangereuse)</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" >Envoyer</button> {réponse && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Réponse de l'IA :</strong> {response}</div> )}</main> ); }

process.env.NEXT_PUBLIC_OPENAI_KEY , sa valeur est développée sous forme de chaîne lors de la compilation.
Autrement dit, .env , elle sera incluse dans le fichier JavaScript front-end et sera librement visible par les utilisateurs.

Si vous ouvrez le bundle distribué dans l'onglet Sources de votre navigateur sk- sont intégrées telles quelles.
.env , tant que vous le référencez depuis le front-end, les risques associés à l'écriture directe persistent.

De plus, lors de l'appel d'une API, la clé est ajoutée à
l'en-tête d'autorisation donc l'onglet Réseau , ce qui revient à rendre la clé publique pour tous les utilisateurs.

Correct : via l'API

Les clés définies dans .env non
référencées directement Si vous utilisez les routes et gestionnaires de routes API de Next.js, le client ne transmet que des données utilisateur, et la clé API OpenAI n'est jamais rendue publique. (La même configuration fonctionnera en toute sécurité même en cas de déploiement sur Vercel, etc.)

Par exemple, si vous créez le code suivant :

.env

OPENAI_API_KEY=sk-zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

route.ts

// app/api/ai/route.ts import { NextResponse } from "next/server"; export async function POST(req: Request) { try { const { input } = await req.json(); const apiKey = process.env.OPENAI_API_KEY; // Côté serveur uniquement, non exposé if (!apiKey) { return NextResponse.json( { error: "Server misconfig: OPENAI_API_KEY missing" }, { status: 500 } ); } const r = await fetch("https://api.openai.com/v1/chat/completions", { method: "POST", headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json", }, body: JSON.stringify({ model: "gpt-4o-mini", messages: [{ role: "user", content: input }], }), }); const data = await r.json(); return NextResponse.json(data, { status: r.status }); } catch (e) { console.error(e); return NextResponse.json({ error: "Bad request" }, { status: 400 }); } }

page.tsx

// app/page.tsx "utiliser le client"; importer { useState } depuis "react"; exporter la fonction par défaut Page() { const [input, setInput] = useState(""); const [response, setResponse] = useState(""); const handleSubmit = async () => { const res = await fetch("/api/ai", { méthode : "POST", en-têtes : { "Content-Type": "application/json" }, corps : JSON.stringify({ input }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Aucune réponse."; setResponse(texte); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> 💬 Démo ChatBot (via API sécurisée)</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" >Envoyer</button> {réponse && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Réponse de l'IA :</strong> {response}</div> )}</main> ); }

Bien sûr, il n'y a pas de clé API sur le front-end, vous ne la trouverez donc pas même si vous regardez l'onglet Sources.

De plus, l'en-tête d'autorisation n'est pas inclus dans l'onglet Réseau et, comme le côté serveur fait la demande à OpenAI en votre nom, elle n'est pas divulguée à l'utilisateur.

Solution : requêtes proxy du serveur

Comme vous pouvez le voir dans les exemples ci-dessus, la manipulation des clés API sur le front-end est extrêmement dangereuse,
assurez- vous donc de ne lire les clés API

Si le front-end envoie uniquement les entrées utilisateur au serveur , et que ce dernier effectue des requêtes à l'API OpenAI en votre nom , la clé API ne sera pas divulguée à l'extérieur. C'est la méthode la plus simple et la plus sûre .

• ❌Manuscrit → N'importe qui peut copier la clé à partir du code source ou du contenu
• ❌ .env → Intégré après la construction, afin que tout le monde puisse le voir
• ✅Requêtes proxy via le serveur → Les clés ne sont jamais révélées

Si l'information est divulguée au monde extérieur, même pour un instant, il est possible qu'une utilisation frauduleuse puisse entraîner une facture de plusieurs centaines de milliers à plusieurs centaines de milliers de yens

Il existe de nombreux
autres risques liés aux secrets qui peuvent être divulgués de manière inattendue la publication accidentelle d'un .env . Puisque les secrets peuvent être divulgués au public sans que vous vous en rendiez compte, soyez toujours prudent lorsque vous manipulez des secrets tels que des clés d'API .

J'ai également publié un article qui utilise cette méthode pour résoudre efficacement les problèmes de sécurité.
Pour consulter du code détaillé et des exemples de déploiement, veuillez consulter cet article.

Vous pouvez également lire

Créer un chatbot avec l'API OpenAI [Next.js + Tailwind CSS] De plus en plus de personnes utilisent l'API OpenAI pour créer leurs propres chatbots et assistants professionnels. Dans cet article, je vous montre comment créer un chatbot avec Next.js (App Router) et Tailwind CSS.

Si vous codez avec des vibrations, c'est une lecture incontournable !

Si vous avez lu jusqu'ici et que vous vous dites : « Oh non, j'ai peut-être négligé la sécurité », pas d'inquiétude, il est encore temps.
il existe une bible que vous devriez lire au moins une fois, quel que soit votre poste

Il « Apprendre systématiquement à créer des applications Web sécurisées, 2e édition » (auteur : Tokumaru Hiroshi) .

explique
l'essence de la sécurité : « Pourquoi est-ce dangereux ? » et « Comment la prévenir ? » – des principes de vulnérabilité aux exemples et aux contre-mesures Véritable ouvrage systématique, il vous enseigne les spécificités du flux d'attaque et les points clés de la défense.

Même sans le mettre en pratique, vous pouvez prévenir des accidents graves en acquérant simplement un minimum de connaissances .
Si quelques milliers de yens peuvent éviter des risques de plusieurs centaines de milliers de yens, il n'y a aucune raison de ne pas le lire.

Si vous trouvez le contenu difficile,
une bonne idée de demander à un ingénieur expérimenté de le vérifier .

Enfin, vérifions-le maintenant

Comme expliqué dans cet article, la manipulation des clés API en front-end est extrêmement dangereuse .
Même si quelque chose semble fonctionner correctement, il n'est pas rare que la clé API soit exposée au monde entier.

Par exemple, comprenez-vous vraiment le
de l'application « codée avec Vibes »  Si vous avez encore des doutes, vous devriez immédiatement revoir sa conception et vous assurer qu'elle est sécurisée .

Grâce à l'IA, de nombreuses personnes
peuvent désormais écrire du code et se dire : « Je peux le faire aussi. » Cela peut sembler efficace,
mais si vous négligez la sécurité et que votre clé API est divulguée, vous risquez de payer des frais importants.
Dans ce cas, vous en assumerez la responsabilité.