ISGroup Consultoría de Ciberseguridad

App generada con IA: 15 controles de seguridad antes del go-live

App generada con IA: 15 controles de seguridad antes del go-live

Cuando una aplicación web, un MVP SaaS o una herramienta interna creada con IA parece funcionar, la presión natural es publicarla. El problema es que “funciona” y “puede ir online” son dos condiciones distintas. Antes de conectar datos reales, usuarios, pagos, API corporativas o sistemas internos, hace falta una verificación concreta sobre el código, las configuraciones, las autorizaciones y el comportamiento expuesto.

Esta lista de verificación (checklist) está pensada para equipos que han usado ChatGPT, GitHub Copilot, Cursor, Codex, Claude Code, Lovable, Bolt.new, v0, Replit Agent, Devin, Kiro, Gemini u otras herramientas de codificación por IA. Antes del go-live, lo que cuenta es qué se ha construido, qué está expuesto y qué riesgos pueden llegar a producción junto con la funcionalidad.

Úsala antes del go-live, antes de una beta con clientes, antes de importar datos reales o antes de conectar la aplicación a pagos, CRM, bases de datos corporativas, almacenamiento en la nube o API internas.

El valor de la checklist aumenta cuando se aplica sobre un entorno real, no solo sobre el repositorio. Muchas vulnerabilidades no se ven leyendo una sola función: emergen cuando el código, los roles, las rutas, las configuraciones en la nube, el almacenamiento, las devoluciones de llamada (callbacks) y las variables de entorno trabajan juntos. Por eso, cada control debería producir una evidencia verificable: una solicitud HTTP, una configuración, una política, una prueba negativa, una captura de pantalla de permisos o una decisión de remediación.

[Callforaction-WAPT]

Antes de empezar: define el perímetro real

Una checklist solo funciona si el perímetro es claro. Antes de los 15 controles, recopila al menos esta información: repositorio o proyecto, URL de staging y producción, rutas públicas, API, roles de usuario, datos tratados, proveedores de autenticación, bases de datos, almacenamiento, servicios en la nube, variables de entorno, dependencias añadidas por la IA y partes generadas o modificadas con asistentes o agentes.

Si no logras reconstruir estos elementos, el primer riesgo es precisamente la falta de control sobre el go-live. Una aplicación generada por IA puede haberse construido rápidamente, pero antes de publicarla debe convertirse en un producto verificable.

El perímetro debe incluir también lo que se añadió para hacer funcionar rápidamente el prototipo: paquetes instalados, integraciones temporales, cuentas de servicio, webhooks de prueba, buckets creados durante el desarrollo, claves compartidas en chats, prompts usados para generar código y partes copiadas de ejemplos. Son elementos que a menudo no aparecen en la historia de usuario, pero pueden determinar el nivel de exposición real de la aplicación.

Qué se vuelve público en el go-live

El primer control es inventariar lo que será accesible: dominio, subdominios, API, webhooks, callbacks, almacenamiento, despliegues de vista previa (preview), paneles de administración, rutas de depuración, archivos estáticos y entornos temporales. Muchos incidentes nacen de lo que el equipo no pensaba haber publicado.

Comprueba que las demos, endpoints de prueba, datos de prueba (seed data), cuentas de administrador temporales, páginas de diagnóstico y mensajes de error detallados no sean accesibles. Si usas Vercel, Replit, Lovable, Bolt.new, Firebase, Supabase o nubes similares, verifica también las URL de vista previa, despliegues anteriores y dominios personalizados.

Este inventario debe compararse con la intención del producto. Si una ruta es pública solo porque el framework la expuso por defecto, si un entorno de vista previa permanece indexado, si una función serverless acepta llamadas sin autenticación o si un endpoint de administración responde fuera de la VPN, la superficie de ataque es más amplia de lo previsto. Antes del go-live, lo que no sirve debe desaparecer; lo que sirve debe tener control de acceso, registro (logging) y límites coherentes.

Autenticación, sesiones y recuperación de cuentas

La autenticación debe verificarse más allá del “camino feliz” (login exitoso). Prueba el registro, inicio de sesión, cierre de sesión, restablecimiento de contraseña, invitaciones, cambio de correo electrónico, cambio de contraseña, caducidad de sesión y revocación de tokens. Si la aplicación gestiona datos sensibles, roles administrativos o pagos, evalúa el uso de MFA o controles equivalentes.

Los errores más frecuentes en las aplicaciones generadas con IA son sesiones demasiado largas, restablecimientos de contraseña reutilizables, tokens no invalidados tras el cambio de contraseña, invitaciones caducadas que siguen siendo válidas, controles solo en el frontend y mensajes de error que revelan si una cuenta existe. Antes de publicar, cada flujo de cuenta debe probarse con un usuario válido, un usuario no válido, un token caducado, un enlace ya usado e intentos repetidos.

Comprueba también el comportamiento entre dispositivos y sesiones paralelas. Un cambio de contraseña debería invalidar los tokens donde sea necesario, un cierre de sesión debería cerrar realmente la sesión, una invitación no debería poder ser usada por una cuenta distinta a la prevista. En aplicaciones B2B, verifica también qué sucede cuando un usuario deja una organización, cambia de rol o es eliminado de un inquilino (tenant).

Autorizaciones, BOLA y aislamiento de inquilinos

El control de acceso roto (Broken access control) es uno de los riesgos más críticos para aplicaciones web y API. En las aplicaciones creadas con IA suele presentarse así: el usuario está autenticado, pero puede acceder a objetos que no le pertenecen cambiando un ID en la solicitud.

Prueba manualmente user_id, project_id, tenant_id, organization_id, order_id, document_id y cualquier identificador controlable desde el cliente. Un usuario estándar debe intentar leer, modificar, borrar o exportar registros de otros usuarios; un usuario de un inquilino debe intentar acceder a recursos de otro inquilino.

El control debe ser del lado del servidor (server-side). Ocultar un botón en la interfaz de usuario (UI) no protege la API: cada endpoint debe verificar la identidad, el rol, la propiedad y el inquilino antes de devolver o modificar datos. Las aplicaciones generadas con IA pueden introducir este problema de forma sutil: una página nueva usa un filtro del lado del cliente, una función de exportación olvida el tenant_id, un endpoint de detalle solo comprueba que el usuario esté conectado, una consulta usa un ID recibido del navegador sin verificar la propiedad. La prueba debe atravesar flujos diferentes, no limitarse a la pantalla principal.

API y rutas no visibles en la UI

Muchas aplicaciones generadas con IA tienen rutas creadas para depuración, pruebas o comodidad que, aunque no aparezcan en la interfaz, pueden seguir siendo accesibles a través del navegador, curl, proxy o scripts.

Llama directamente a todas las API y prueba métodos HTTP diferentes, tokens faltantes, tokens caducados, roles insuficientes, cargas útiles (payloads) incompletas, parámetros manipulados y solicitudes fuera de secuencia. Verifica rutas de administración, endpoints de exportación, carga de archivos, importación, webhooks, callbacks, comprobaciones de estado (health checks) y funciones del lado del servidor. Si una ruta no debe existir en producción, elimínala; si debe existir, protégela con autenticación, autorización, límites de tasa (rate limit), registro y gestión de errores coherente.

Incluye en el control también las rutas creadas por convenciones del framework: endpoints de API generados automáticamente, páginas dinámicas, funciones serverless, callbacks OAuth, webhooks de pago, URL de vista previa y rutas para trabajos programados (cron jobs). Una interfaz limpia puede ocultar un backend mucho más amplio de lo que el equipo recuerda.

Validación de entrada, manejo de salida y carga de archivos

El código generado por la IA puede manejar correctamente la ruta prevista e ignorar por completo las entradas maliciosas. Verifica formularios, cadenas de consulta (query strings), cuerpos JSON, encabezados, nombres de archivo, rutas, plantillas, markdown, HTML y valores numéricos.

Los casos mínimos a probar incluyen inyección SQL, inyección NoSQL, XSS, recorrido de rutas (path traversal), inyección de comandos, SSRF donde sea pertinente, carga de archivos activos, extensiones dobles, tipo MIME falsificado, archivos demasiado grandes y datos fuera de formato. La validación debe ser del lado del servidor, con listas blancas (allowlist) donde sea posible. La salida también debe gestionarse: los errores, registros, mensajes al usuario, exportaciones y renderizado HTML no deben exponer seguimientos de pila (stack traces), tokens, consultas, rutas internas o datos de otros usuarios.

Para las cargas de archivos, verifica todo el ciclo de vida del archivo: carga, escaneo o validación, guardado, descarga, vista previa, eliminación y acceso mediante enlaces compartidos. Si la aplicación genera vistas previas, PDF, imágenes o documentos, comprueba que el contenido cargado no se interprete como código ni se reutilice en prompts, plantillas o flujos de trabajo automáticos sin saneamiento.

Secretos, claves API y credenciales

Busca secretos en el código, archivos .env, historial de Git, prompts, chats, registros, salidas de compilación, artefactos, pruebas, archivos README, ejemplos y configuraciones. Las aplicaciones generadas por IA suelen contener claves insertadas “temporalmente” para hacer funcionar una demo.

Si una clave ha sido expuesta en un repositorio, prompt, registro o artefacto, debe rotarse: eliminarla del archivo no es suficiente. Usa gestores de secretos o variables de entorno gestionadas, separa desarrollo/staging/producción y asigna alcances mínimos. Atención al frontend: una clave privada no debe terminar en el paquete (bundle), en una página, en una respuesta JSON o en un registro del lado del cliente.

La verificación debe incluir la compilación final y los artefactos, no solo las fuentes. Busca claves en el paquete minificado, en los mapas de origen (source maps), en los registros de la tubería (pipeline), en los contenedores, en los archivos de configuración exportados y en los ejemplos dejados en el repositorio. Si un asistente de IA sugirió pegar una clave para “probar rápidamente”, trátala como potencialmente comprometida hasta que haya sido rotada.

Datos personales, datos corporativos y entornos

Antes del go-live debes saber qué datos tratas, dónde terminan y quién puede leerlos. Los datos personales, documentos de clientes, registros de aplicaciones, cargas útiles de webhooks, tickets, capturas de pantalla, exportaciones y copias de seguridad deben tener una ubicación clara.

Las demos generadas con IA suelen usar datos reales demasiado pronto. Separar desarrollo, staging y producción reduce el riesgo: usa datos sintéticos cuando sea posible, evita volcados reales en los repositorios y verifica la retención de registros. Si la aplicación trata datos personales, comprueba la base jurídica, la política de privacidad, la minimización, el acceso, la eliminación, la conservación y los proveedores involucrados. Esto no sustituye una evaluación de privacidad, pero evita publicar sin saber por dónde pasan los datos.

Un control útil es seguir un solo dato desde su inserción hasta su eliminación: formularios, API, base de datos, registros, correos electrónicos, notificaciones, webhooks, analíticas, copias de seguridad y exportaciones. Este recorrido muestra rápidamente si la aplicación conserva más información de la necesaria o si los datos de producción terminan en entornos de desarrollo, herramientas de soporte, sistemas de seguimiento o prompts usados para depuración.

Bases de datos, BaaS y reglas de seguridad

Si usas Supabase, Firebase, Replit Database, bases de datos SQL gestionadas o backend-as-a-service, no basta con que la aplicación lea y escriba correctamente: debes verificar las reglas de acceso.

  • Para Supabase: comprueba la seguridad a nivel de fila (Row Level Security), políticas por rol e inquilino, que la clave de rol de servicio (service role key) nunca esté en el cliente, funciones SQL, políticas de almacenamiento y clave anónima (anon key).
  • Para Firebase: comprueba las reglas de Firestore/Realtime Database, reglas de almacenamiento, reclamaciones personalizadas (custom claims) y denegación por defecto (default deny).
  • Para bases de datos SQL: comprueba consultas, filtros user_id/tenant_id, migraciones, copias de seguridad y acceso a la red.

La prueba más importante sigue siendo manual: dos usuarios diferentes, dos inquilinos diferentes, objetos similares, API directas e intentos de leer o modificar datos no autorizados. No des por sentado que las reglas del BaaS sean equivalentes a la lógica de la aplicación: una página puede mostrar solo los datos correctos, pero una política permisiva puede permitir el acceso directo desde el cliente. Por el contrario, una política demasiado rígida puede empujar al equipo a usar claves de servicio del lado del servidor sin controles granulares. Antes de la publicación se necesita coherencia entre reglas, código y modelo de datos.

Almacenamiento, buckets y documentos cargados

La carga y el almacenamiento suelen añadirse rápidamente por los constructores de aplicaciones de IA. Verifica quién puede cargar, leer, descargar, borrar y compartir archivos, porque un bucket público o una URL predecible puede exponer documentos corporativos incluso si el resto de la aplicación requiere inicio de sesión.

Comprueba la separación entre activos públicos y archivos privados, tipo MIME, tamaño máximo, extensiones, recorrido de rutas, antivirus o controles equivalentes cuando sea necesario, caducidad de enlaces, copias de seguridad y eliminación. Prueba la descarga y eliminación con usuarios diferentes: un usuario no debería poder descargar archivos de otro cliente solo modificando el ID, la ruta o el nombre del archivo.

Verifica también los metadatos. El nombre original del archivo, autor, tamaño, ruta, etiquetas, vistas previas y texto extraído pueden revelar información sensible incluso cuando el archivo principal parece protegido. Si los documentos cargados son procesados por funciones de IA, comprueba dónde se guardan los resultados de la extracción y quién puede leerlos.

Dependencias, lockfiles y cadena de suministro

Las herramientas de IA suelen añadir paquetes para resolver errores rápidamente. Cada modificación en package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, lockfiles y scripts de instalación/compilación/prueba debe ser revisada.

Comprueba vulnerabilidades conocidas, mantenimiento del paquete, licencia, dependencias transitivas, typosquatting, scripts postinstall, versiones bloqueadas y librerías casi homónimas. Si una dependencia se añadió solo para hacer pasar una prueba, pregunta si existe una solución más sencilla o ya aprobada. El análisis de composición de software (SCA) y la revisión de dependencias ayudan, pero no sustituyen la decisión técnica: ¿esa librería realmente debe entrar en el producto?

Cuando la IA modifica dependencias, mira también qué se elimina. Una actualización puede cambiar el middleware de seguridad, el análisis sintáctico (parsing), la validación, la gestión de cookies o el comportamiento por defecto; una librería sustituida por una alternativa más sencilla puede perder controles que el equipo daba por sentados. La revisión debe incluir lockfiles y diferencias de configuración, no solo el código de la aplicación.

Nube, despliegue y configuraciones

El despliegue es el punto en el que los atajos y los valores por defecto se convierten en exposición real. Verifica CORS, CSP, encabezados de seguridad, callbacks, redirecciones, modo de depuración, informes de errores, límites de tasa, variables de entorno, IAM, grupos de seguridad, buckets, bases de datos públicas, contenedores, funciones serverless e IaC.

Una configuración generada por la IA puede resolver un error de compilación y debilitar la seguridad al mismo tiempo. CORS *, redirecciones no permitidas en listas blancas, depuración activa, errores detallados, secretos en los registros de despliegue y permisos en la nube demasiado amplios son problemas que deben bloquearse antes de la publicación. Si el proyecto usa AWS, Google Cloud, Firebase, Supabase, Vercel, Replit u otros entornos gestionados, comprueba también la separación de desarrollo/staging/producción y los privilegios de las cuentas de servicio.

Las configuraciones de despliegue merecen una prueba en un entorno similar a la producción: verifica encabezados reales, redirecciones efectivas, comportamiento de los errores, activos publicados, respuestas de las API, callbacks permitidos y acceso desde redes externas. Un archivo de configuración correcto en el repositorio no garantiza que la plataforma esté ejecutando la aplicación con los mismos valores.

CI/CD, protección de ramas y artefactos

La tubería (pipeline) debe impedir que el código generado o modificado por la IA llegue a producción sin revisión. Comprueba la protección de ramas, revisores obligatorios, pruebas mínimas, escaneo de secretos, escaneo de dependencias, artefactos de compilación, registros de CI/CD y permisos de tokens.

Atención a las modificaciones que “simplifican” la tubería: pruebas desactivadas, pasos de seguridad eliminados, tokens con mayor alcance, despliegue automático en ramas no protegidas, registros más detallados, caché que contiene datos sensibles. Si usas agentes que abren PR o modifican tuberías, exige aprobación humana en las áreas sensibles: autenticación, API, secretos, dependencias, IaC, despliegue y datos.

Comprueba también qué se conserva como artefacto. Informes, compilaciones, cobertura, registros, volcados de pruebas, capturas de pantalla y paquetes comprimidos pueden incluir datos o configuraciones que no deberían salir de la tubería. Una tubería rápida pero demasiado detallada puede convertirse en una segunda superficie de exposición.

Pruebas negativas y casos de abuso

Las pruebas generadas por la IA suelen cubrir el camino feliz. Antes del go-live hacen falta pruebas que intenten romper las reglas: usuarios sin permiso, inquilinos diferentes, tokens caducados, entradas maliciosas, cargas no válidas, condiciones de carrera (race conditions), flujos fuera de orden, pagos manipulados, invitaciones reutilizadas, restablecimiento de contraseña abusado.

Cada control crítico debería tener al menos una prueba positiva y una negativa. Si una funcionalidad trata sobre datos o roles, hace falta demostrar no solo que el usuario correcto puede acceder, sino que el usuario incorrecto no puede. El WAPT manual es útil porque aporta una mentalidad diferente: no pregunta si la funcionalidad funciona, sino cómo puede ser abusada desde el exterior.

Para cada flujo importante, prepara al menos una pregunta de abuso: ¿puedo crear algo sin pagar, ver datos de otro usuario, repetir una acción, saltarme un paso, forzar un estado, usar un token antiguo, cambiar el precio, modificar cantidades, eludir un límite, exportar más datos de los previstos? Las respuestas a estas preguntas cuentan más que el porcentaje de cobertura de las pruebas.

Registro, monitoreo y pista de auditoría

Los registros y el monitoreo sirven para entender qué sucede después del go-live, pero pueden convertirse en un riesgo si contienen tokens, PII, cargas útiles sensibles, consultas, seguimientos de pila o datos de otros usuarios.

Verifica qué eventos críticos se registran: inicio de sesión, restablecimiento de contraseña, cambio de rol, acciones de administración, exportación, eliminación, pago, carga de archivos, errores, cambios de configuración y accesos anómalos. Los registros deben ser útiles para la respuesta ante incidentes, pero minimizados y protegidos. Si la aplicación se crea con agentes de IA, conserva también evidencias de qué se generó, qué PR se aceptaron, qué pruebas pasaron y qué remediaciones se hicieron: la pista de auditoría ayuda a reconstruir decisiones y responsabilidades.

El monitoreo debe estar listo antes del lanzamiento, no añadido después del primer incidente. Define qué eventos producen alertas, quién los recibe, qué umbrales indican abuso y qué acciones están previstas. Para una aplicación web expuesta, los inicios de sesión fallidos, errores 403/401 anómalos, picos en endpoints sensibles, cargas inusuales, exportaciones masivas y restablecimientos de contraseña repetidos son señales que deben tratarse con atención.

Decisión de remediación antes del go-live

La checklist no sirve si al final no produce una decisión. Cada hallazgo debe tener un estado: corregir antes del go-live, aceptar temporalmente con justificación, monitorear o bloquear la publicación.

Bloquea el go-live si encuentras acceso no autorizado a datos, secretos expuestos, buckets públicos no previstos, bases de datos alcanzables, API sin autenticación, escalada de privilegios, pagos manipulables o configuraciones en la nube demasiado permisivas.

Puedes planificar después del lanzamiento solo lo que tenga un riesgo residual claro, propietario definido, fecha límite y monitoreo. Si nadie es dueño del riesgo, el riesgo no se acepta: solo se pospone. Una buena decisión de remediación distingue entre defectos funcionales, vulnerabilidades explotables, endurecimiento (hardening) y deuda técnica: no todo bloquea el lanzamiento, pero lo que afecta a datos, autorizaciones, secretos, pagos, superficies públicas y privilegios debe tener prioridad. El go-live debería basarse en hallazgos cerrados o riesgos explícitamente gobernados, no solo en la percepción de que el prototipo funciona.

Cuándo basta una revisión interna y cuándo hace falta una verificación independiente

Una revisión interna puede bastar para prototipos no públicos, sin datos reales, sin roles, sin API expuestas, sin pagos, sin integraciones corporativas y con un revisor competente en las áreas modificadas.

Hace falta una verificación independiente cuando la aplicación está online o a punto de estarlo, trata datos reales, tiene usuarios externos, gestiona pagos, usa roles administrativos, integra API corporativas, expone cargas de archivos, modifica la nube/IaC o deriva de PR amplias generadas por agentes de IA. La presión del go-live no debe desaparecer: debe transformarse en prioridad. Primero se controlan datos, autorizaciones, secretos, superficies expuestas y configuraciones de producción; luego se decide qué puede ir online.

Cómo ISGroup puede verificar una aplicación generada con IA

El control cambia según lo que se haya construido y lo que se exponga. Si la aplicación o las API son alcanzables online, el Web Application Penetration Testing verifica el comportamiento real desde el exterior. Si el riesgo está en el código, en la lógica de la aplicación, en los middlewares, en los secretos o en las dependencias, la Code Review ayuda a identificar vulnerabilidades y regresiones antes de la fusión (merge). Si el problema afecta a superficies conocidas, hosts, servicios y configuraciones expuestas, el Vulnerability Assessment ayuda a mapear vulnerabilidades conocidas y prioridades.

Si la aplicación generada con IA tiene… Riesgo principal Control recomendado
Aplicación web, API, rutas públicas, carga de archivos, flujos de login o pago Comportamientos abusables desde el exterior Web Application Penetration Testing
Código generado, autenticación, roles, lógica de negocio, secretos, dependencias Vulnerabilidades o regresiones en el código Code Review
Hosts, servicios, versiones, configuraciones expuestas, endpoints técnicos Vulnerabilidades conocidas o exposiciones técnicas Vulnerability Assessment
Nube, IAM, buckets, bases de datos, CI/CD, IaC, cuentas de servicio Configuraciones erróneas o privilegios excesivos Cloud Security Assessment
Límites de confianza, multi-inquilino, integraciones, datos sensibles Suposiciones arquitectónicas débiles Secure Architecture Review
Uso continuo de codificación por IA en el ciclo de lanzamiento Controles no repetibles en lanzamientos y tuberías Software Assurance Lifecycle

La elección del control depende de lo que realmente ha cambiado: código, comportamiento expuesto, nube, arquitectura o proceso de desarrollo. Antes del go-live conviene delimitar ese perímetro y verificar el riesgo efectivo sobre la aplicación.

¿Has creado una aplicación con herramientas de IA y debes conectarla a datos reales, usuarios o pagos? ISGroup puede ayudarte a verificar código, API, autorizaciones, secretos, dependencias, nube y superficies expuestas antes de la publicación.

Evidencias a preparar antes de la revisión

Prepara el repositorio o proyecto, URL de los entornos, lista de partes generadas con IA, roles de usuario, API, proveedores de autenticación, bases de datos, almacenamiento, servicios en la nube, dependencias añadidas, variables de entorno, registros disponibles, tuberías, decisiones de remediación y riesgos ya aceptados. Estas evidencias hacen que la verificación sea más rápida y concreta, porque permiten distinguir errores de aplicación de configuraciones erróneas, problemas de código de riesgos en la nube, hallazgos bloqueantes de mejoras planificables.

Preguntas frecuentes

  • ¿Las pruebas automáticas bastan antes del go-live?
  • No. Son necesarias, pero no demuestran por sí solas que las autorizaciones, el aislamiento de inquilinos, la lógica de negocio, las API y las configuraciones sean seguras en el comportamiento real.
  • ¿Debo hacer siempre WAPT?
  • Si la aplicación o las API están expuestas online, el WAPT es el control más directo sobre el comportamiento externo. Si, por el contrario, el riesgo está en el código no expuesto todavía, puede ser más coherente empezar por una Code Review.
  • ¿Una aplicación no-code o low-code generada con IA es más segura?
  • No automáticamente. Aunque el código esté oculto o gestionado parcialmente por el proveedor, siguen existiendo configuraciones, autenticación, roles, bases de datos, almacenamiento, claves API, callbacks y datos reales que verificar.
  • ¿Qué hallazgos bloquean el go-live?
  • Acceso no autorizado a datos, escalada de privilegios, secretos expuestos, bases de datos o buckets públicos no previstos, API sin autenticación, pagos manipulables y configuraciones en la nube demasiado permisivas.
  • ¿Cuándo hace falta el Cloud Security Assessment?
  • Cuando la aplicación usa nube, BaaS, bases de datos gestionadas, almacenamiento, IAM, cuentas de servicio, CI/CD, IaC o despliegues configurados rápidamente con la ayuda de la IA.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

In

, , ,