Recurso · Buen uso · 7 min

Vibe coding sin agujeros: seguridad antes de publicar

Los fallos de seguridad típicos de las apps hechas con IA y cómo pedirle a la propia IA que los busque por ti.

Todos los recursos

La IA escribe código que funciona, pero no siempre código seguro: si no se lo pides, prioriza que la app haga lo que dices, no que nadie pueda abusar de ella. Por suerte, los fallos suelen ser siempre los mismos, y la propia IA es muy buena encontrándolos si se lo pides.

  • 01

    Claves a la vista

    Una clave secreta en el código del navegador la puede copiar cualquiera. En Next.js, todo lo que empieza por NEXT_PUBLIC_ es público.

  • 02

    Base de datos sin cerrojo

    En Supabase, una tabla sin RLS (seguridad por filas) deja que cualquiera lea o borre los datos de todos.

  • 03

    Botones ocultos, puertas abiertas

    Esconder el botón de «borrar» no basta: el servidor tiene que comprobar quién hace cada petición.

  • 04

    Fiarse del navegador

    El precio, el rol de usuario o el «soy administrador» nunca deben venir del navegador: se pueden manipular.

  • 05

    Paquetes inventados

    A veces la IA recomienda librerías que no existen, y hay gente que crea paquetes falsos con esos nombres. Comprueba cada una antes de instalarla.

  • 06

    Sin límites de uso

    Un botón que llama a una IA de pago sin límite puede vaciarte la cuenta si alguien lo usa mil veces.

Checklist antes de publicar

  1. 1Las claves secretas están en .env, el .env está en el .gitignore y en Vercel van en Environment Variables.
  2. 2Ninguna clave secreta empieza por NEXT_PUBLIC_ (ni VITE_ en otros proyectos).
  3. 3Todas las tablas de Supabase tienen RLS activado, con reglas de quién puede leer y escribir.
  4. 4Cada ruta del servidor comprueba que el usuario ha iniciado sesión y tiene permiso.
  5. 5Los precios y los pagos se calculan en el servidor, y los webhooks de Stripe verifican su firma.
  6. 6Has revisado las dependencias con npm audit.
Prompt de auditoría para cualquier agente
Revisa este proyecto como un experto en seguridad. Busca: claves expuestas en el código del navegador, tablas sin control de acceso, rutas del servidor que no comprueban quién hace la petición, datos que deberían calcularse en el servidor y llamadas a servicios de pago sin límite. Para cada problema dime dónde está, qué podría hacer un atacante y cómo arreglarlo. Ordénalos de más a menos grave y no cambies nada todavía.
Ver más prompts como este

Para una revisión a fondo, Cloudflare ha publicado gratis la skill que usa para buscar vulnerabilidades: varios agentes buscan fallos y otros intentan desmentirlos, y al final te entrega un informe con lo confirmado y lo pendiente.

Instalar la skill de auditoría de Cloudflare
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

# Después, dentro de tu proyecto, pídele a tu agente:
# «haz una auditoría de seguridad de este proyecto»

Ojo. La auditoría completa lanza muchos agentes y gasta mucho uso: con un plan básico puede agotar tu límite en una sola pasada. Pruébala en un proyecto pequeño. Y si una clave secreta llegó a subirse a GitHub, no basta con borrarla: cámbiala en el servicio.

Mal uso vs buen uso

  • Publicar en cuanto funciona.

    Pasar la checklist y pedir una auditoría antes de enseñarlo.

  • Borrar el commit donde se coló una clave.

    Cambiar la clave en el servicio: lo que se subió ya puede estar copiado.

  • Instalar todo lo que sugiere la IA.

    Comprobar que cada paquete existe, es conocido y está mantenido.