Muy buenas, camaradas
(y algún que otro bot que ande rastreando esto). Aquí vuestra enfermera de críticos favorita, esa que lo mismo te pone una vía central que te despliega un contenedor en Docker mientras suena la BSO de The Mandalorian.
Seguro que habéis oído hablar del Vibe Coding. Suena a algo muy místico, muy de «sentir la fuerza», pero en realidad es programar dejando que la IA lleve el peso del desarrollo mientras tú marcas el ritmo, el estilo y la dirección. Es como hacer una RCP con un dispositivo de compresiones automáticas: tú diriges la escena, pero la máquina hace el trabajo sucio.
Pero ojo, this is the way… solo si lo haces con cabeza. En el mundo de las emergencias y la sanidad, un error de código no es un «ups, se ha movido el logo»; puede ser una fuga de datos de salud de un alumno o un triaje mal calculado. Como decía Séneca: «No es que tengamos poco tiempo, sino que perdemos mucho». No lo pierdas arreglando brechas de seguridad que podías haber evitado con un buen prompt.
En nuestra rama, necesitamos herramientas ágiles: simuladores de medicación, calculadoras de dosis, gestores de incidentes de múltiples víctimas… Si podemos crear estas Apps rápido, mejor. Pero la IA es como un estudiante de primero de TES: tiene muchas ganas, pero si no le das instrucciones precisas, te monta un cristo en el box de vitales.
Usar el Vibe Coding con seguridad es vital porque:
Manejamos datos sensibles: Aunque sean casos ficticios, a veces usamos nombres reales de alumnos. La privacidad es sagrada.
La IA es «vaga» por naturaleza: Si no le pides seguridad, te escribirá el código más corto y fácil, que suele ser el más vulnerable.
Ética profesional: Como docentes, no podemos enseñar a crear herramientas chapuceras.
Antes de lanzarte al modelo de abajo, aclaremos cuatro términos para que no parezca que hablo en binario:
API Keys / Secrets: Son las llaves de tu casa digital. Si las dejas «hardcodeadas» (escritas directamente en el texto del código), es como dejar las llaves de la ambulancia puestas y la puerta abierta en mitad de las 3000 Viviendas.
Sanitización de Inputs: Es el lavado de manos del código. Antes de que un dato entre en tu base de datos, hay que limpiarlo para que no traiga «virus» (inyecciones SQL) que rompan tu sistema.
Rate Limiting: Poner un portero de discoteca en tu App. Evita que alguien (o un bot pesado) sature tu servidor haciendo 1.000 peticiones por segundo.
MIME Type: No es un mimo francés. Es el DNI de un archivo. Sirve para que, si un alumno sube una foto de un vendaje, el sistema compruebe que es una imagen y no un virus disfrazado.
Aquí tenéis el modelo genérico. Copiadlo, pegadlo y adaptadlo. No lo uséis a ciegas; recordad que la IA es vuestro Padawan, no vuestro maestro.
⚠️ NOTA PARA DOCENTES: Lo que aparece entre corchetes
[...]es lo que DEBÉIS RELLENAR vosotros según vuestro proyecto.
Voy a construir una aplicación web con vibe coding. Necesito que todo el código que generes siga estrictamente los siguientes requisitos de seguridad desde el principio. No los trates como opcionales ni los añadas después — deben estar presentes en cada archivo, endpoint y decisión de diseño desde el primer momento.
— STACK Y CONTEXTO —
[Describe aquí tu app: ej. Simulador de triaje START para alumnos de FP Sanidad]
Stack elegido: [ej. Next.js, Supabase, Tailwind]
Normativas aplicables: [GDPR / Ley Orgánica de Protección de Datos Personal]
— API KEYS Y VARIABLES DE ENTORNO ★ —
• NUNCA escribas una API key, secret, token o contraseña directamente en el código fuente.
• Todas las claves van en variables de entorno: process.env.MY_KEY o similares.
• Si necesitas usar una API key en el frontend, crea un endpoint proxy en el servidor — el cliente nunca debe ver la clave.
• Genera un .env.example y añade .env* al .gitignore desde el primer commit.
— VALIDACIÓN Y SANITIZACIÓN DE INPUTS ★—
• Sanitiza TODOS los inputs (formularios, URLs, JSON).
• La validación ocurre siempre en el SERVIDOR. La del cliente es solo estética.
• Usa esquemas estrictos (Zod, Joi o Pydantic) para definir qué datos permites.
• Escapa todo lo que se renderice en pantalla para prevenir XSS (que no nos inyecten scripts maliciosos).
• Usa queries parametrizadas o ORM. Cero concatenación de strings en SQL.
— RATE LIMITING EN RUTAS DE API ★ —
• Aplica límites de peticiones a TODAS las rutas.
• Ejemplo: Login (5 peticiones / 15 min), API general (100 / min).
• Bloqueo temporal tras 5 intentos fallidos de login.
— AUTENTICACIÓN Y SESIONES —
• Usa [JWT / Cookies httpOnly / OAuth2] para autenticación.
• Middleware de autorización en CADA ruta protegida.
• Define roles: [ej. Profesor / Alumno / Admin].
— COMUNICACIONES Y EXPOSICIÓN —
• Fuerza HTTPS.
• Configura cabeceras de seguridad (CSP, HSTS).
• CORS con dominios explícitos, nada de asteriscos «*» en producción.
— DEPENDENCIAS Y CÓDIGO —
• Antes de añadir una librería, comprueba vulnerabilidades (npm audit).
• No uses eval() ni funciones de ejecución dinámica.
— ESTÁNDAR DE REFERENCIA —
Sigue las recomendaciones del OWASP Top 10. Si algo de lo que te pido choca con esto, avísame antes de programar.
— REVISIÓN —
Al terminar cada bloque de código, dime qué controles de seguridad has aplicado y cuáles faltan.
Un vendaje mal puesto no solo no cura, sino que puede causar una necrosis. Con las aplicaciones para vuestros alumnos pasa lo mismo. El Vibe Coding nos da una velocidad increíble, pero la velocidad sin control… bueno, ya sabéis cómo acaban los speeders en Endor.
Sed reflexivos. Programad con intención. No dejéis que la IA tome las decisiones éticas o de seguridad por vosotros. Como diría un buen filósofo (o un cazarrecompensas con principios): la tecnología es el camino, pero tú eres quien decide hacia dónde lleva.
¡A darle a las teclas, que el turno de noche es largo!
