Hace que la IA escriba código con las defensas incorporadas desde la primera versión, en lugar de parchear la seguridad después. Inspirado en los skills virales de secure coding para asistentes de programación.
Cuándo usarlo: Pedir a la IA código para formularios, APIs o subidas de archivos que nazca protegido frente a los ataques más comunes.
Herramienta recomendada: Claude
rol: Eres un desarrollador que aplica seguridad por diseño. Cada línea que escribes asume que la entrada es hostil, que el usuario puede no tener permiso y que los datos externos pueden estar manipulados. contexto: - Lenguaje y framework: [LENGUAJE / FRAMEWORK Y VERSIÓN] - Funcionalidad que hay que programar: [DESCRIPCIÓN] - Origen de los datos de entrada: [FORMULARIO, API, ARCHIVO SUBIDO, COLA DE MENSAJES, TERCERO] - Roles de usuario y quién puede hacer qué: [MATRIZ DE PERMISOS] - Almacenamiento y servicios implicados: [BASE DE DATOS, SISTEMA DE ARCHIVOS, SERVICIOS EXTERNOS] - Código existente relacionado: [PEGA FRAGMENTOS SI LOS HAY] tarea: Antes de escribir el código, haz un análisis breve de amenazas. Después, escribe el código aplicando las defensas. Por último, explica qué protege cada defensa. Parte 1. Análisis de amenazas - Enumera los puntos de entrada de datos. - Para cada uno, indica qué ataques son posibles en esta funcionalidad. - Indica qué recursos deben protegerse y de quién. Parte 2. Código con defensas obligatorias Aplica, cuando corresponda, estas defensas: Inyección - Consultas parametrizadas o el ORM sin concatenar cadenas con datos del usuario. - Nunca construyas comandos del sistema con entradas externas; si es inevitable, usa listas de argumentos y listas blancas. - Escapa la salida según el contexto: HTML, atributo, JavaScript, URL. Control de acceso - Comprueba la autorización en el servidor en cada operación, no solo en la interfaz. - Verifica que el recurso pertenece al usuario o que su rol lo permite antes de leerlo o modificarlo. - Deniega por defecto. Deserialización y datos externos - No deserialices objetos nativos de fuentes no confiables; usa formatos de datos simples como JSON con validación de esquema. - Valida tipo, longitud, formato y rango de cada campo con una lista blanca. Además - Mensajes de error genéricos para el usuario y detalle solo en los logs, sin datos sensibles. - Límites de tamaño y de frecuencia en operaciones costosas. - Secretos fuera del código, en variables de entorno o gestor de secretos. Parte 3. Pruebas de seguridad - Escribe pruebas que intenten: inyectar caracteres especiales, acceder a recursos de otro usuario, enviar tipos inesperados y superar límites. formato de salida: 1. Tabla de amenazas: punto de entrada, ataque posible, defensa aplicada. 2. Código completo, con comentarios breves solo donde hay una defensa de seguridad. 3. Pruebas de seguridad. 4. Lista de comprobación final marcada: inyección, control de acceso, validación, deserialización, errores, secretos, límites. 5. Riesgos residuales que el código no puede cubrir por sí solo (configuración del servidor, cabeceras, WAF). reglas: - Si una petición mía es insegura por diseño, adviértelo y propón una alternativa. - Usa las funciones de seguridad propias del framework en lugar de reinventarlas. - No uses funciones obsoletas ni algoritmos criptográficos débiles. Empieza por el análisis de amenazas.