Escribí una clave API en el frontend con Vibe Coding y terminé siendo hackeado y me cobraron una tarifa elevada. Aquí hay algunos ejemplos y medidas de seguridad.

La "codificación Vibe", para crear rápidamente una aplicación con énfasis en "hacerla funcionar", está ganando popularidad como estilo de desarrollo moderno.

En particular, el uso de BaaS como Supabase o Firebase permite completar operaciones de autenticación y de base de datos con solo unas pocas líneas de código, lo que lo hace muy útil para la creación rápida de prototipos y la mejora de la interfaz de usuario.

Sin embargo, por otro lado, es fácil cometer errores peligrosos como escribir claves API o información secreta directamente en el frontend lo que supone el riesgo de un hackeo inesperado o facturas elevadas .

Este artículo utiliza ejemplos y demostraciones reales para explicar claramente por qué no se debe escribir la clave privada en el frontend.
presentaremos medidas específicas y puntos de diseño para lograr una codificación vibrante y segura

¿Qué es la Vibecoding? Riesgos que a menudo se pasan por alto a cambio de eficiencia.

Hoy en día, se suele hablar de "codificación de vibraciones".
En términos generales, se trata de un estilo de desarrollo que prioriza "hacer que funcione" y se apoya en IA y herramientas prácticas para mantener un buen ritmo.

Por ejemplo, si usas Supabase o Firebase, puedes escribir el inicio de sesión, la conexión a la base de datos y la visualización, todo desde el frontend, y ver los resultados inmediatamente en el navegador.
Al experimentar esta sensación, muchos se apresuran a hacerlo, pensando: "¡Funciona, así que está bien!", sin pensar demasiado en el diseño y la seguridad.

Sin embargo, si se implementa sin pensarlo dos veces, podría encontrarse con
problemas inesperados De hecho, hay muchos casos en los que información importante, como las claves API, queda expuesta a plena vista desde el front-end.

Hay más personas de las que uno se imagina que implementan cosas sólo porque "funcionan" y exponen información peligrosa al mundo.

¿Esa manera de escribir es realmente incorrecta?

Ahora que es común que la IA ayude con la programación, cada vez hay más casos en los que el programador no se da cuenta del riesgo.
El código funciona, no tiene errores y fue generado por una IA... En ese caso, es aún menos probable que sospeche.

Por ejemplo, si escribes claves API y tokens directamente en el front-end, o si no creas un back-end y tienes todo procesado en el front-end,
puede funcionar al principio, pero en realidad se puede explotar fácilmente desde afuera .

La acumulación de estas "cosas que hacemos sin saberlo" puede a veces dar lugar a problemas graves como fugas de información y facturas elevadas

¿Qué sucede cuando escribes una clave API en el frontend?

a menudo genera código que maneja todo, desde los procesos de inicio de sesión hasta la conexión a API externas,

En este punto, la IA sugerirá "naturalmente" una configuración en la que la información secreta, como claves API y tokens de autenticación, se almacena en el front-end .

A primera vista, parece funcionar correctamente y parece normal,
pero si lo implementa con esta configuración, los secretos que deben mantenerse seguros en el lado del servidor quedarán expuestos y serán visibles para los navegadores de los usuarios.

¿Qué pasa cuando el secreto está al frente?

"Dejar un secreto en recepción" es como "dejar la llave de tu casa en la puerta de entrada antes de salir".

Casos de daños reales: Problemas causados por claves API filtradas

Quizás te preguntes: "¿Es realmente tan malo que una clave API aparezca en la página principal?".
Sin embargo, se han dado varios casos de daños graves debido a las claves API en proyectos que surgieron de la codificación vibe .

Daños reales causados por Lovable.dev

Lovable.dev está ganando popularidad como plataforma de IA para la programación de ambientes .
Si bien permite a los desarrolladores crear aplicaciones con una facilidad casi nula, se han dado varios casos en los que el diseño de seguridad se ha quedado atrás.

Se han reportado varios casos en los que
información confidencial, como claves de autenticación y direcciones de correo electrónico, se dejó públicamente disponible en algunas aplicaciones publicadas con Lovable.dev De hecho, se han confirmado casos en los que las claves secretas de las API de OpenAI y Google Maps se integraron en el frontend, lo que provocó un uso no autorizado .

se generaron solicitudes por valor de decenas de miles de yenes en un solo día , por lo que esto podría tener un impacto financiero inmediato, especialmente para proyectos que utilizan API pagas.

La mitad de los sitios con código de vibración exponen claves API

Otro estudio examinó más de 2000 sitios con código de vibración y descubrió que aproximadamente el 49,5 % de ellos tenían secretos como claves API, JWT y claves API de Google expuestas desde el frente .

Esto demuestra que, en muchos casos, la prioridad es simplemente conseguir que el código se "ejecute" y faltan fundamentos de seguridad

También es posible que desee leer

¿Tus sitios web codificados con Vibe están filtrando secretos? Cómo analicé 2000 sitios web creados con herramientas de Vibe y lo que encontré…

Una demostración rápida: ¿Su clave API es realmente invisible?

Aquí presentaremos tres patrones de implementación comunes para el manejo de claves API (dos ejemplos incorrectos y uno correcto).
Aunque a primera vista parezca que funcionará correctamente, en realidad puede suponer un grave riesgo de seguridad.

• Ejemplo incorrecto 1:
  Codificar la clave API en el front-end. Este es un mal ejemplo común. Cualquiera puede averiguar la clave consultando el código.
• Ejemplo incorrecto 2 : definir la clave API en .env
  A veces la gente dice: "No hay problema si la defino en .env", pero esto no es diferente del Ejemplo incorrecto 1.
• .env
  en el lado del servidor a través de la API y comunicarse con el frontend a través de la API, la clave no quedará expuesta al usuario.

Ejemplo incorrecto 1: Escribir la clave API directamente en el frente

En primer lugar, lo que nunca debes hacer escribir la clave directamente en el código .

// app/page.tsx "usar cliente"; importar { useState } desde "react"; const openaiApiKey = "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; // ← ⚠️ ¡Peligro! ¡Escríbelo directamente en el 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", { método: "POST", encabezados: { "Tipo de contenido": "application/json", Autorización: `Portador ${openaiApiKey}`, }, cuerpo: JSON.stringify({ modelo: "gpt-3.5-turbo", mensajes: [{ rol: "usuario", contenido: entrada }], }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Sin respuesta."; setResponse(texto); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> Demostración de ChatBot (Ejemplo de implementación peligrosa)</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" >Enviar</button> {respuesta && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Respuesta de IA:</strong> {respuesta}</div> )}</main> ); }

Si escribe la clave directamente en el frontend, se incluirá en el archivo JavaScript después de la compilación,
por lo que si publica la aplicación, cualquiera podrá verla desde un navegador .

la pestaña Fuentes en Chrome DevTools , puedes ver el archivo del paquete distribuido tal como está.
"sk- there" , puedes encontrar rápidamente la clave API codificada.

Ejemplo incorrecto ② : Definición de una clave API en .env

Algunas personas creen que es seguro escribirlo en .env, pero si lo referencias directamente desde el código del front-end, terminará integrándose en el JavaScript compilado y se hará público.

Por ejemplo, si crea el siguiente código:

.env

# .env NEXT_PUBLIC_OPENAI_KEY=sk-yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

página.tsx

// app/page.tsx "usar cliente"; import { useState } from "react"; const openaiApiKey = process.env.NEXT_PUBLIC_OPENAI_KEY; // ← ⚠️ ¡Peligro! Incluso en .env, esto es 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", { método: "POST", encabezados: { "Tipo de contenido": "application/json", Autorización: `Portador ${openaiApiKey}`, }, cuerpo: JSON.stringify({ modelo: "gpt-3.5-turbo", mensajes: [{ rol: "usuario", contenido: entrada }], }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Sin respuesta."; setResponse(texto); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> Demostración de ChatBot (Ejemplo de implementación peligrosa)</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" >Enviar</button> {respuesta && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Respuesta de IA:</strong> {respuesta}</div> )}</main> ); }

process.env.NEXT_PUBLIC_OPENAI_KEY , su valor se expande como una cadena durante la compilación.
En otras palabras, .env , se incluirá en el archivo JavaScript del frontend y será visible para los usuarios.

Si abre el paquete distribuido en la pestaña Fuentes de su navegador sk- están incrustadas tal cual.
.env , siempre que lo referencia desde el frontend, los mismos riesgos que si lo escribiera directamente .

Además, al llamar a una API, la clave se añade al
encabezado de autorización Por lo tanto, la pestaña "Red" , lo que equivale a hacerla pública para todos los usuarios.

Correcto: Vía API

Las claves definidas en .env deben
referenciarse directamente Si utiliza las rutas y los controladores de ruta de la API de Next.js, lo único que envía el cliente es la entrada del usuario, y la clave de la API de OpenAI nunca se publica. (Esta misma configuración funcionará de forma segura incluso si se implementa en Vercel, etc.).

Por ejemplo, si crea el siguiente código:

.env

OPENAI_API_KEY=sk-zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

ruta.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; // Solo del lado del servidor, no expuesto if (!apiKey) { return NextResponse.json( { error: "Configuración incorrecta del servidor: falta OPENAI_API_KEY" }, { status: 500 } ); } const r = await fetch("https://api.openai.com/v1/chat/completions", { método: "POST", encabezados: { Autorización: `Portador ${apiKey}`, "Tipo de contenido": "application/json", }, cuerpo: JSON.stringify({ modelo: "gpt-4o-mini", mensajes: [{ rol: "usuario", contenido: entrada }], }), }); const data = await r.json(); return NextResponse.json(data, { estado: r.status }); } catch(e) { console.error(e); return NextResponse.json({ error: "Solicitud incorrecta" }, { estado: 400 }); } }

página.tsx

// app/page.tsx "usar cliente"; importar { useState } desde "react"; exportar función predeterminada Page() { const [input, setInput] = useState(""); const [response, setResponse] = useState(""); const handleSubmit = async() => { const res = await fetch("/api/ai", { método: "POST", encabezados: { "Tipo de contenido": "application/json" }, cuerpo: JSON.stringify({ input }), }); const data = await res.json(); const text = data.choices?.[0]?.message?.content ?? "Sin respuesta."; setResponse(texto); }; return (<main className="max-w-xl mx-auto p-4 space-y-4"><h1 className="text-2xl font-bold"> Demostración de ChatBot (a través de API segura)</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" >Enviar</button> {respuesta && (<div className="border p-3 rounded bg-gray-100 whitespace-pre-wrap"> <strong>Respuesta de IA:</strong> {respuesta}</div> )}</main> ); }

Por supuesto, no hay ninguna clave API en el frontend, por lo que no la encontrarás incluso si miras la pestaña Fuentes.

Además, el encabezado de Autorización no está incluido en la pestaña Red y, dado que el lado del servidor realiza la solicitud a OpenAI en su nombre, no se filtra al usuario.

Solución: solicitudes de proxy desde el servidor

Como puede ver en los ejemplos anteriores, manipular claves API en el frontend es extremadamente peligroso,
así que asegúrese de leer claves API

Si el front-end solo envía la información del usuario al servidor , y este realiza solicitudes a la API de OpenAI en su nombre , la clave de API no se filtrará. Esta la forma más sencilla y segura de operar .

• ❌Escrito a mano → Cualquiera puede copiar la clave del código fuente o del contenido
• ❌ .env → Se integra después de la compilación para que todos puedan verlo
• ✅Solicitudes de proxy a través del servidor → Las claves nunca se revelan

Si la información se filtra al mundo exterior aunque sea por un momento, es posible que un uso fraudulento pueda resultar en una factura de cientos de miles a cientos de miles de yenes

Existen muchos
otros riesgos para los secretos que pueden filtrarse inesperadamente publicar accidentalmente un .env . Dado que los secretos pueden exponerse al público sin que usted se dé cuenta, siempre debe tener cuidado al manejar secretos como las claves API .

También he publicado un artículo que utiliza este método para abordar adecuadamente los problemas de seguridad.
Si desea ver ejemplos detallados de código e implementación, consulte este artículo.

También es posible que desee leer

Creación de un chatbot con la API de OpenAI [Next.js + Tailwind CSS] Cada vez más personas utilizan la API de OpenAI para crear sus propios chatbots y asistentes empresariales. En este artículo, te mostraré cómo crear un chatbot con Next.js (App Router) y Tailwind CSS.

¡Si estás codificando con vibraciones, esto es una lectura obligada!

Si has leído hasta aquí y piensas: "Ay, no, quizá no le presté atención a la seguridad", no te preocupes, aún tienes tiempo.
hay una biblia que deberías leer al menos una vez, independientemente de tu puesto

trata "Aprender sistemáticamente a crear aplicaciones web seguras, 2ª edición" (autor: Tokumaru Hiroshi) .

explica
la esencia de la seguridad: "¿Por qué es peligrosa?" y "¿Cómo prevenirla?", desde los principios de vulnerabilidad hasta ejemplos y contramedidas un libro verdaderamente sistemático que enseña los detalles del flujo de ataque y los puntos clave de la defensa.

Aunque no lo pongas en práctica, puedes prevenir accidentes graves con solo adquirir los conocimientos mínimos .
Si unos pocos miles de yenes pueden prevenir riesgos de cientos de miles, no hay razón para no leerlo.

Si encuentra el contenido difícil,
una buena idea pedirle a un ingeniero experimentado que lo revise .

Finalmente, veámoslo ahora.

Como se explica en este artículo, manejar claves API en el front-end es extremadamente peligroso .
Incluso si algo parece funcionar correctamente, no es raro que la clave API quede expuesta a todo el mundo.

Por ejemplo, ¿ entiendes realmente cómo
la aplicación "programaste con vibraciones" Si aún no lo tienes claro, deberías revisar el diseño inmediatamente y asegurarte de que sea seguro .

Con la ayuda de la IA, muchas personas
ahora pueden escribir código y pensar: "Yo también puedo". Puede parecer que funciona bien,
pero si descuidas la seguridad y tu clave API se filtra, existe un riesgo real de que te cobren una cantidad elevada.
Si eso ocurre, tú quien asuma la responsabilidad.