![Imagen de portada de [Vibe Coder n.º 8] 6 controles de seguridad antes de recibir usuarios](/assets/images/posts/88a2c686-f9c2-4047-8809-30b6118aec87/launch-security-checklist-1.jpg)
La app está terminada, desplegada y solo queda publicar el enlace. Este último capítulo es la revisión final justo antes de hacerlo: seis controles de seguridad que debes comprobar antes de aceptar usuarios y el resumen completo del mapa trazado desde el primer capítulo.
Antes de empezar, aclaremos un malentendido frecuente: «Mi app es pequeña y no es famosa, ¿quién la atacaría?». Como vimos en el capítulo 2, el atacante no es una persona, sino un bot. Los bots no eligen objetivos: lanzan una red. Exploran automáticamente todas las direcciones públicas de Internet para encontrar puertas abiertas. Una app pequeña no es segura; simplemente nadie la está protegiendo. Por suerte, las puertas que suelen quedar abiertas en las apps creadas mediante vibe coding son bastante predecibles, y estas seis son las principales.
6 controles antes de publicar
1. ¿Se está filtrando algún secreto? Es la revisión del capítulo 2: comprueba que ninguna API key esté expuesta en el frontend ni en un repositorio público de GitHub. Instrucción para la IA: «Busca todos los casos en los que una API key o un secreto de este proyecto se haya enviado al frontend o se haya confirmado en Git».
2. ¿El backend comprueba los permisos? Es el principio del capítulo 1. Ocultar el botón de eliminar es solo decoración: cualquiera puede enviar la solicitud. Para eliminar, editar o consultar una publicación, el backend debe comprobar «¿este usuario tiene derecho a hacerlo?». Instrucción para la IA: «Audita todas las API del backend para comprobar el inicio de sesión y la propiedad, y enumera lo que falte».
3. ¿La base de datos está abierta a cualquiera? El almacén (DB) tiene sus propias reglas de acceso. En Supabase se llama RLS (Row Level Security, seguridad a nivel de fila): en pocas palabras, una regla en la puerta del almacén que indica quién puede leer y escribir cada fila. Si está desactivada, queda abierta una ruta para saquear el almacén directamente, sin pasar por el backend. Es el problema señalado con más frecuencia en incidentes reales de apps creadas mediante vibe coding. Instrucción para la IA: «Comprueba si alguna tabla de mi DB permite leer o escribir a cualquiera y explícame cómo bloquearla».
4. ¿Está preparada para entradas extrañas? Los usuarios introducen cualquier cosa: textos de 100.000 caracteres, fragmentos de código extraños o valores vacíos. Si el backend no valida la longitud y el formato, la app puede romperse o quedar expuesta. Instrucción para la IA: «Comprueba que todos los puntos que reciben entradas de usuario tengan límites de longitud y validación de formato».
5. ¿Hay límites de gasto? Es la configuración de cinco minutos del capítulo 7: límite de gasto y alertas de presupuesto. En cuanto aparecen usuarios, el volumen de llamadas deja de estar bajo mi control; antes de publicar es la última oportunidad para configurarlo.
6. ¿Puedes volver atrás? Es el punto de guardado del capítulo 3. Haz commit y push del estado justo anterior a publicar y confirma que las copias de seguridad de la DB estén activadas. Cuando ocurra el primer incidente tras publicar, la velocidad de recuperación dependerá de poder volver al «momento en que todo funcionaba».
Si revisar las seis te parece demasiado, ejecuta al menos este último prompt: «Eres un auditor de seguridad. Antes de publicar este proyecto, encuentra todos los puntos peligrosos relacionados con exposición de secretos, permisos ausentes, reglas de acceso a la DB y validación de entradas, y ordénalos por gravedad». La IA que cometió errores durante la creación también puede encontrarlos cuando le pides una auditoría. Pero no basta con creer su «ya es seguro»: la revisión consiste en contrastarlo con esta lista y comprobar cada punto.
Resumen de la serie: un mapa en una sola página
Si doblamos los ocho capítulos en una sola página, queda así.
- Capítulo 1 — Estructura: una app tiene sala (frontend), cocina (backend) y almacén (DB). El frontend es un espacio público, así que no guardes secretos allí.
- Capítulo 2 — API keys: las claves son tarjetas corporativas. Solo tienen dos ubicaciones:
.envy el panel de despliegue. - Capítulo 3 — Git: un commit es un punto de guardado. Guarda cada vez que todo funcione y antes de cualquier cambio importante.
- Capítulo 4 — Despliegue: desplegar es mudarse al servidor.
.envno se carga en la mudanza, así que regístralo aparte en el panel. - Capítulo 5 — Errores: los mensajes de error son confesiones. Pásalos completos a la IA junto con el contexto. Si la IA da vueltas, cambia el enfoque.
- Capítulo 6 — Misterios: los culpables de «no he cambiado nada» son la caché, las dependencias, los servicios externos y mi yo de ayer. Empieza por las comprobaciones más baratas.
- Capítulo 7 — Costes: la factura procede de tokens, lecturas y escrituras, y tráfico. Los límites de gasto y las alertas son un seguro de cinco minutos.
- Capítulo 8 — Revisión antes de publicar: cierra las seis puertas anteriores antes de salir.
Para terminar
Esta serie no enseñaba a programar. En su lugar, dibujó un mapa: de qué piezas está hecha mi app, qué problemas puede causar cada una, dónde mirar cuando ocurre un incidente y qué preguntar a la IA. La verdadera habilidad del vibe coding no es leer código, sino formular preguntas precisas a la IA con este mapa en la mano.
El mapa ya está en tus manos. Crea algo bueno y muéstraselo al mundo.