“La checklist previa al vuelo existe porque la memoria falla y el coste de olvidar es el avión entero.”
La checklist previa al lanzamiento
Antes de lanzar, recórrela una vez, con deliberación, como lo haría un atacante. Es todo el curso en forma de lista. Si no haces nada más, haz esto:
- Acceso a datos: cada tabla tiene Row-Level Security con una política real; un segundo usuario y una petición anónima están ambos bloqueados (cap. 2).
- Secretos: ninguna clave secreta en el bundle de cliente ni en git; todo lo que se filtró está rotado; las claves viven en el servidor (cap. 3).
- Autorización: cada endpoint con id comprueba la propiedad en el servidor; has probado a cambiar un id y te ha rechazado (cap. 4).
- Superficie expuesta: endpoints inventariados, rutas muertas borradas, CORS restringido a tus orígenes, rate limits en auth y rutas costosas (cap. 5).
- Webhooks: cada webhook entrante verifica su firma y rechaza una llamada sin firmar (cap. 5).
Configura las cabeceras que la herramienta se saltó
Las cabeceras de seguridad son unas pocas líneas de configuración que activan protecciones a nivel de navegador, y las herramientas de IA casi nunca las añaden porque nada se rompe sin ellas. Son un seguro barato contra clases enteras de ataque:
- Content-Security-Policy: restringe qué scripts y recursos pueden cargarse, amortiguando el cross-site scripting. La de mayor valor y la más delicada de acertar.
- Strict-Transport-Security (HSTS): fuerza HTTPS para que un usuario no pueda ser degradado a una conexión interceptable.
- X-Content-Type-Options: nosniff y X-Frame-Options / frame-ancestors paran los trucos de content-type y el clickjacking por incrustación.
- Y la base debajo de todas ellas: sirve todo por HTTPS, sin contenido mixto.
Una Content-Security-Policy razonable es en la que realmente merece la pena invertir: es la diferencia entre que un script extraviado quede inerte o corra con las sesiones de tus usuarios. Empieza en modo report-only para ver qué bloquearía antes de imponerla.
Tus dependencias son parte de tu superficie de ataque
Una herramienta de IA incorpora paquetes sin reparos, y cada dependencia es código en el que confías y que distribuyes. El ecosistema AI/JS, que se mueve rápido, es terreno fértil para vulnerabilidades conocidas, typosquats y librerías abandonadas. La higiene es estándar y merece automatizarse: audita de qué dependes, fija versiones y parchea los problemas conocidos antes de que se exploten.
- Ejecuta un escaneo de vulnerabilidades (npm audit, o una herramienta como Dependabot/Snyk) y arregla los críticos antes de lanzar.
- Fija las versiones para que una dependencia no pueda cambiar bajo tus pies, y revisa qué es realmente un paquete nuevo antes de añadirlo.
- Mantén el hábito de actualizar; una dependencia sin mantener es una vulnerabilidad a cámara lenta.
Errores y logs: no narres las tripas
A las apps construidas con IA les encanta devolver el error crudo a la pantalla: stack traces, mensajes SQL, rutas de archivos. Cada uno es un mapa gratuito de tus interioridades para un atacante. Muestra a los usuarios un mensaje genérico; registra el detalle en el servidor, donde solo tú puedes leerlo. Y ya que estás, asegúrate de registrar lo suficiente para notar un ataque: logins fallidos, denegaciones de autorización, saltos del rate limit.
Cuándo traer ayuda
Este curso hace que los agujeros comunes y graves sean detectables por la persona que construyó la app, y para muchos proyectos, ejecutar la checklist con honestidad basta para lanzar de forma responsable. Pero cuanto más manejas (pagos reales, datos de salud o financieros, información sensible de terceros), mayor es el coste del agujero en el que no pensaste mirar, y más merece la pena que revise la app alguien cuyo trabajo a tiempo completo es encontrarlos.
Ese es el trabajo que hace SDEN: endurecer y revisar aplicaciones construidas con IA contra exactamente estos modos de fallo, con el marco SOC 2 / CCPA / PIPEDA que esperan los clientes norteamericanos. Si has construido algo con IA y estás a punto de poner datos de usuarios reales detrás, una revisión de seguridad antes de lanzar es mucho más barata que el incidente después. Combina esto con el curso de Seguridad de IA para las amenazas específicas de los modelos, y tendrás la imagen completa.
Una línea por cada uno
- Ejecuta la checklist previa al lanzamiento con deliberación: acceso a datos, secretos, autorización, superficie expuesta y webhooks, todo el curso en forma de lista.
- Añade los básicos que la IA se salta: cabeceras de seguridad (sobre todo una CSP real), HTTPS/HSTS, escaneo de dependencias y gestión de errores sin fugas.
- Re-ejecuta la checklist tras los cambios: regenerar código con IA elimina guardas en silencio, así que la seguridad es un bucle, no un hito.
- Los escáneres automatizados atrapan los agujeros mecánicos; la autorización rota necesita juicio humano, así que para datos sensibles, consigue una revisión antes de lanzar.