Seguridad y datos

Los disgustos del vibecoding casi nunca son aplicaciones que no funcionan. Son aplicaciones que funcionan y, a la vez, dejan algo a la vista: una clave con la que otro usa tu cuenta, una base de datos que cualquiera puede leer o los datos de tus clientes donde no deberían estar.

No hace falta ser experto en seguridad para evitar lo más común. Hacen falta cuatro comprobaciones, siempre las mismas: dónde están las claves, quién puede leer la base de datos, de quién son los datos que guardas y qué piezas de otros usa tu código.

Esta lección las recorre una a una y termina con una lista de ocho puntos que puedes pasar a cualquier cosa que hagas. Si tu herramienta es solo para ti, varios no te afectarán. Si la va a usar otra gente, todos.

Ninguna de estas comprobaciones exige leer código. Todas se hacen probando la aplicación como lo haría otra persona o preguntando al asistente lo que debe contarte.

Claves a la vista

Una clave de API es una contraseña para usar un servicio a tu nombre. Si alguien la encuentra, lo usará y la factura será tuya, o llegará a los datos que esa clave abre.

Se escapan por sitios previsibles:

• escrita en el código de la página, que cualquiera puede leer en su navegador;
• en un proyecto que se publica en internet, como un repositorio público;
• en una captura de pantalla o pegada en una conversación.

Si se te escapa una, lo primero es anularla en el servicio y crear otra. Borrarla del código no basta: puede seguir en el historial de versiones, y puede que alguien ya la haya copiado. Es lo que recomienda la propia documentación de GitHub.

Y en cada servicio que cobre por uso, pon un límite de gasto. Si algo sale mal, el límite pone el techo.

Bases de datos abiertas

Muchas plataformas crean la base de datos en un minuto. Lo que no siempre dejan resuelto es quién puede leerla y escribir en ella. Si nadie lo ha decidido, puede pasar que cualquiera que sepa la dirección vea todos los registros, los de todos tus usuarios.

Se comprueba de una forma sencilla: abre tu aplicación desde otro navegador o en una ventana privada, sin iniciar sesión, e intenta ver o cambiar datos que no son tuyos. Lo que veas así lo puede ver cualquiera.

Pregunta a tu asistente: «¿Quién puede leer y escribir en esta base de datos? Explícame las reglas de acceso que hay ahora». Si la respuesta es «cualquiera», pídele que las cierre para que cada persona vea solo lo suyo, y vuelve a probar sin iniciar sesión.

Datos de otras personas

En cuanto tu herramienta guarda nombres, correos, teléfonos o datos de salud de otras personas, quien la pone en marcha responde de esos datos. En la Unión Europea lo regula el Reglamento General de Protección de Datos, y la Agencia Española de Protección de Datos tiene guías para quien los trata.

Lo básico, que se aplica también aunque seas pequeño:

• Guarda solo lo que necesitas. Si no vas a llamar a nadie, no pidas el teléfono.
• Di qué guardas y para qué, en un texto claro junto al formulario.
• Para probar, datos inventados. Nunca la lista real de tus clientes, ni en las pruebas ni pegada en la conversación con el asistente.
• Borra lo que ya no necesites.

Si lo que haces va a tratar datos sensibles o de mucha gente, consulta con alguien que sepa de protección de datos antes de abrirlo.

Piezas de terceros

Casi todo el código usa piezas hechas por otros, llamadas paquetes o bibliotecas: una para enviar correos, otra para los pagos, otra para las fechas. Es normal y ahorra trabajo. El riesgo está en que el asistente proponga una que no conoces.

Un estudio presentado en USENIX Security 2025 analizó 576.000 fragmentos de código de 16 modelos: de media, al menos un 5,2 % de los paquetes que recomendaban los modelos comerciales y un 21,7 % de los de los modelos abiertos no existían. Un nombre inventado es una puerta: alguien puede registrarlo y llenarlo de código malicioso.

Antes de aceptar un paquete nuevo, comprueba tres cosas: que existe en su repositorio oficial, que lo usa más gente y que alguien lo mantiene. Y pide al asistente la lista de piezas que usa tu proyecto y para qué sirve cada una.

La lista de ocho puntos

1. Ninguna clave en el código ni en nada que llegue al navegador.
2. Límite de gasto en cada servicio que cobra por uso.
3. La base de datos solo deja leer y escribir a quien debe, probado sin iniciar sesión.
4. Para probar, solo datos inventados.
5. Solo los datos de otras personas que de verdad necesitas, y les dices cuáles.
6. Sabes qué piezas de terceros usa, y existen de verdad.
7. Hay una versión guardada de cuando funcionaba.
8. Sabes qué hacer si una clave se escapa: anularla y crear otra.

Pásala antes de enseñar lo que hayas hecho y cada vez que cambies algo importante.

Hazlo: revisa lo que has hecho con la lista

1. Si ya has empezado tu herramienta, pásale la lista de ocho puntos, uno a uno.
2. Si todavía no, pide a tu asistente que te haga una página mínima que guarde un nombre y un correo, y revísala con la lista.
3. Pide al asistente: «Revisa todo el proyecto y dime si hay alguna clave, contraseña o token escrito en el código».
4. Abre tu herramienta sin iniciar sesión, desde otro navegador, y apunta qué ves.

Lo que no cumpla no es un fracaso: es tu lista de tareas antes de que lo use nadie más.

Repite la revisión cada vez que añadas algo importante: un formulario nuevo, una clave nueva o una pieza de terceros. Lo que estaba bien ayer puede dejar de estarlo con un cambio.