Respira CRM: Del Vibe Coding al Pentesting usando Hacking Ético
¿Qué pasa cuando un equipo de estudiantes de ingeniería construye una aplicación web completa usando inteligencia artificial, la despliega en producción y, acto seguido, la somete a una auditoría de seguridad profesional para encontrar sus propias vulnerabilidades?
Eso fue exactamente lo que hicimos con RespiraCRM: un CRM full-stack para dispositivos médicos respiratorios, disponible en producción en https://web-production-ff1b5.up.railway.app, construido desde cero mediante la metodología del Vibe Coding y luego auditado con el OWASP Top 10 2021 en el marco de la asignatura Hacking Ético de la Universidad Central.
Este artículo cuenta esa historia completa:
- qué herramientas de IA
- usamos, cómo organizamos el código, qué construimos fase a fase, cómo
- lo desplegamos en la nube y, finalmente, qué vulnerabilidades críticas
- descubrimos al hackearlo nosotros mismos. Una historia de construcción
- y destrucción controlada que cualquier desarrollador debería leer.
Primero debemos entender algo fundamental, a partir de lo cual parte todo ¿Qué es el Vibe Coding y por qué lo usamos?
El Vibe Coding es una metodología de desarrollo de software en la que
la mayor parte del código es generado y refinado por inteligencia
artificial, mientras el desarrollador actúa como director de orquesta:
define la visión, los requerimientos, corrige errores y guía a la IA
para obtener el resultado deseado. Es como tener un programador virtual
disponible las 24 horas del día que conoce todas las tecnologías
modernas y escribe código a la velocidad del pensamiento.
Para este proyecto utilizamos cinco herramientas de IA en paralelo,
cada una con un rol específico:
- OpenAI (GPT-4): generación y corrección de código backend y frontend.
- Groq (Llama 3.3 70B): integración de funcionalidades de IA dentro del CRM, como el resumen semanal de ventas.
- Google Gemini: asistencia en procesamiento inteligente y optimización de consultas a la base de datos.
- Codex: apoyo principal para la generación de módulos completos.
- Antigravity: complemento para funcionalidades y soporte en la arquitectura del sistema.
Gracias a este enfoque, pasamos de cero a un MVP (Producto Mínimo
Viable) funcional en días, no semanas. Pero como descubriríamos más
adelante, la velocidad de desarrollo no garantiza la seguridad del
producto.
El Stack Tecnológico de RespiraCRM
Antes de ver el proceso de construcción, es importante entender las
tecnologías que forman el corazón de la plataforma, porque estas
decisiones técnicas también influirían en los hallazgos de seguridad.
- Next.js: framework React para el frontend, con App Router y renderizado híbrido.
- NestJS: framework Node.js para el backend, con arquitectura modular orientada a módulos de negocio.
- PostgreSQL: base de datos relacional para toda la persistencia del sistema.
- Prisma: ORM que conecta el backend con la base de datos mediante consultas type-safe.
- Docker: contenedores que garantizan que el entorno de desarrollo sea reproducible en cualquier máquina.
- JWT + cookies httpOnly: sistema de autenticación seguro que almacena los tokens en cookies inaccesibles desde JavaScript.
- hCaptcha: protección anti-bot en el formulario de login.
- Railway.app: plataforma cloud (PaaS) para el despliegue en producción.
La arquitectura fue un monorepo con tres carpetas principales: apps/web
(frontend), apps/api (backend) y packages/shared (código compartido).
El primer prompt que le dimos a la IA fue exactamente eso: generar esta
estructura con docker-compose.yml y README incluidos.
Construcción Fase a Fase: Cómo Creamos RespiraCRM con IA
Fase 1: Base de Datos y Backend
El diseño de datos fue el primer paso real. Le pedimos a la IA que generara un esquema de Prisma para las entidades principales: Empresa, Contacto, Producto, Oportunidad, Propuesta, Venta, Orden de Servicio, Factura, Reseña, Usuario y Rol. El prompt especificaba relaciones, soft delete (campo deletedAt), timestamps automáticos e índices de rendimiento.
Con el esquema generado, ejecutamos las migraciones y arrancamos el
desarrollo del backend. Los módulos más críticos que construimos con
asistencia de la IA fueron:
- Autenticación: login con JWT almacenado en cookies httpOnly, verificación de hCaptcha, refresh token y endpoint /auth/me. El guard de roles (ADMIN, SALES, OPERATOR) protege cada controlador.
- CRUDs de negocio: empresas, contactos, productos, oportunidades y más, cada uno con controlador, servicio y DTOs validados con class-validator.
- Dashboard de métricas: endpoint GET /metrics/dashboard que devuelve conteos, sumas y agrupaciones directamente desde la base de datos vía Prisma.
Fase 2: Frontend con Next.js
El frontend se construyó consumiendo la API del backend. Las pantallas
más relevantes fueron:
- Login con hCaptcha: formulario seguro con manejo de sesión en un AuthContext global.
- Dashboard principal: tarjetas con métricas en tiempo real y un gráfico de ventas por unidad de negocio con Recharts.
- Pipeline Kanban: tablero drag-and-drop de oportunidades de venta usando @dnd-kit, con actualización en el backend en tiempo real.
- Propuestas con PDF: formulario de propuestas comerciales con generación de PDF profesional mediante @react-pdf/renderer.
- Facturación y órdenes de servicio: gestión de estados con permisos por rol.
- Calendario y registro rápido: FullCalendar integrado con un modal global para registrar llamadas, notas y reuniones desde cualquier pantalla.
- Panel de administración: reportes avanzados con gráficos de conversión, forecast ponderado y estado del sistema.
Fase 3: Despliegue en Railway con Docker y GitHub
El despliegue fue el último paso del desarrollo. Le pedimos a la IA
que generara Dockerfiles multi-etapa para el frontend y el backend, un
entrypoint que ejecutara migraciones de Prisma al arrancar, y las
instrucciones para conectar el repositorio de GitHub con Railway para
CI/CD automático.
El proceso fue el siguiente: creamos el repositorio en GitHub, lo vinculamos a Railway, configuramos las variables de entorno (DATABASE_URL, JWT secrets, etc.) y Railway construyó y desplegó los contenedores automáticamente. La aplicación quedó accesible en: https://web-production-ff1b5.up.railway.app
RespiraCRM quedó con autenticación segura, gestión completa de
clientes y ventas, dashboard en tiempo real, pipeline Kanban, PDF de
propuestas, exportación a Excel, calendario de actividades y panel de
administración completo.
PETENSTING PAGINA WEB RESPIRACRM
El presente documento corresponde al informe de Auditoría de Seguridad Web del sitio: https://web-production-ff1b5.up.railway.app/login. Cuyo principal objetivo es el identificar y documentar las vulnerabilidades presentes en dicho sitio creado y diseñado por nosotros a través del vibe coding para poder corregirlas y solucionarlas con el fin de garantizar la seguridad e integridad de la misma y de sus usuarios.
Esta Auditoría se estructura en tres grandes módulos: (1) Reconocimiento de Red, (2) Análisis DNS, WHOIS y Certificados SSL, y (3) Aplicación de la Metodología OWASP Top 10 – 2021. Para cada módulo se describen los objetivos, conceptos clave, procedimiento paso a paso, herramientas utilizadas, hallazgos obtenidos y mejores prácticas recomendadas.
El Contrato de Autorización: El Paso Legal antes del Hackeo
Antes de ejecutar cualquier prueba de penetración sobre RespiraCRM, el equipo firmó un contrato de autorización formal. En Colombia, la Ley 1273 de 2009 tipifica como delito el acceso no autorizado a sistemas informáticos, con penas de hasta ocho años de prisión. La única diferencia entre un auditor ético certificado y un ciberdelincuente es ese documento: firmado, con alcance definido y responsabilidades claras para todas las partes.
El contrato especificaba que las pruebas se realizarían exclusivamente sobre el dominio https://web-production-ff1b5.up.railway.app, con fines académicos, sin modificar ni eliminar datos y sin afectar sistemas de terceros. Esto es un requisito no negociable en cualquier ejercicio profesional de pentesting, independientemente de que el sistema sea propio.
RespiraCRM fue desarrollado como una plataforma CRM full-stack utilizando la metodología de Vibe Coding, donde gran parte del código fue generado y refinado mediante inteligencia artificial. El sistema fue construido con tecnologías modernas como NestJS, Next.js, PostgreSQL y Docker, permitiendo una arquitectura modular, escalable y mantenible.
La aplicación se ejecutó en un entorno basado en Docker Compose, donde el frontend, backend y base de datos funcionaban en contenedores independientes para facilitar el desarrollo y despliegue. El control de versiones y trabajo colaborativo se realizó mediante GitHub, permitiendo integrar funcionalidades desarrolladas en paralelo por los integrantes del proyecto.
Se utilizaron múltiples herramientas de inteligencia artificial para acelerar la construcción del sistema y automatizar gran parte de la generación de código. Las principales IAs utilizadas fueron:
- OpenAI mediante modelos orientados a generación y corrección de código.
- Groq para la integración de funcionalidades de inteligencia artificial dentro del CRM, utilizando el modelo Llama 3.3 70B.
- Google con integración de Gemini para tareas de asistencia y procesamiento inteligente.
- Codex como herramienta principal de apoyo al desarrollo y generación de módulos completos.
- Antigravity como herramienta complementaria de vibe coding para generación de funcionalidades y soporte en arquitectura.
Estas herramientas permitieron generar estructuras backend y frontend, resolver errores, crear módulos completos, optimizar arquitectura y acelerar significativamente el tiempo de desarrollo del proyecto.
Objetivos
Realizar un análisis de seguridad sobre la plataforma desarrollada mediante Vibe Coding, aplicando metodologías de reconocimiento, análisis de infraestructura y criterios basados en OWASP Top 10, con el fin de identificar posibles vulnerabilidades de configuración, autenticación, exposición de servicios y seguridad del sistema.
Objetivos Específicos
- Reconocimiento e infraestructura:
Analizar la infraestructura de la aplicación identificando servicios expuestos, puertos abiertos, rutas de acceso y tecnologías utilizadas en el Frontend y Backend del sistema. - Análisis DNS, hosting y certificados:
Evaluar la configuración DNS, registros del dominio, certificados SSL/TLS y características del hosting utilizado para verificar la seguridad de las comunicaciones y la exposición de información sensible. - Evaluación basada en OWASP Top 10:
Identificar posibles vulnerabilidades relacionadas con autenticación, control de acceso, validación de entradas, manejo de sesiones, exposición de datos y configuraciones inseguras, tomando como referencia las categorías de OWASP Top 10. - Pruebas y análisis de seguridad:
Utilizar herramientas de análisis y pruebas controladas para detectar riesgos de seguridad en la aplicación, documentando hallazgos técnicos y posibles escenarios de explotación.
Fase 1 del Pentest: Reconocimiento de Red (OSINT)
Ping
Se realizó una prueba de conectividad hacia el servidor donde se encuentra desplegada la aplicación RespiraCRM utilizando el protocolo ICMP mediante el comando ping desde Kali Linux. Durante el análisis se identificó que el dominio web-production-ff1b5.up.railway.app resuelve correctamente a la dirección IP pública 66.33.22.152, confirmando que el servidor se encuentra activo y accesible desde Internet. Además, se observaron tiempos de respuesta entre aproximadamente 88 ms y 251 ms, evidenciando variaciones de latencia propias de una infraestructura cloud desplegada en Railway. También se analizó el valor TTL=56, lo que sugiere que el servidor utiliza un entorno basado en Linux (suele iniciar TTL en 64) eso sugiere que el paquete atravesó alrededor de 8 saltos de red. Este procedimiento permitió validar la disponibilidad del sistema y obtener información inicial sobre la infraestructura y conectividad de la plataforma antes de realizar pruebas de seguridad más avanzadas.
Se realizó una prueba de trazado de ruta utilizando el comando traceroute desde Kali Linux hacia el servidor de RespiraCRM alojado en Railway.
Traceroute
- Dominio analizado: web-production-ff1b5.up.railway.app
- Dirección IP: 66.33.22.152
- Primer salto detectado: 10.0.2.2
- Estado de los siguientes saltos: * * *
- El primer salto corresponde al gateway o router interno de la red local.
- Los asteriscos (* * *) indican que los dispositivos intermedios no respondieron a las solicitudes de traceroute.
- Esto ocurre porque muchos servidores y proveedores cloud bloquean respuestas ICMP/UDP por motivos de seguridad.
Este comando realiza un trazado de ruta (traceroute) hacia el servidor donde está alojada la aplicación RespiraCRM, pero en lugar de usar paquetes ICMP o UDP tradicionales, utiliza conexiones TCP sobre el puerto 80.
- traceroute → Permite identificar los saltos o rutas que siguen los paquetes hasta llegar al servidor.
- -T → Indica que se utilizarán paquetes TCP.
- -p 80 → Define el puerto 80, correspondiente al protocolo HTTP.
- web-production-ff1b5.up.railway.app → Dominio del servidor analizado.
salto dirección descripción
1 10.0.2.2 Gateway del MV
2 66.33.22.152 Servidor donde se encuentra el aplicativo
A diferencia del traceroute tradicional, este método sí logró llegar al servidor porque utilizó tráfico TCP permitido por el servicio web. Esto demuestra que:
- El servidor se encuentra activo y accesible desde Internet.
- El puerto 80 (HTTP) está habilitado y responde correctamente.
- La infraestructura cloud de Railway permite conexiones TCP hacia la aplicación.
- Existen pocas rutas visibles entre el cliente y el servidor, probablemente debido a la abstracción de red utilizada por el proveedor cloud.
Obtención Ip Pública
Se puede identificar al usar el condado curl ifconfig.me podemos obtener la ip publica.
Escaneo de Puertos
Nmap -F (dominio)
Se realizó un escaneo de puertos utilizando la herramienta Nmap mediante el comando nmap -F, con el objetivo de identificar los principales servicios expuestos públicamente por el servidor donde se encuentra desplegada la aplicación RespiraCRM. Durante el análisis se confirmó que el host se encuentra activo y accesible desde Internet, presentando una latencia aproximada de 0.093 segundos.
El escaneo permitió identificar los puertos 22/tcp, 80/tcp y 443/tcp abiertos. El puerto 22 corresponde al servicio SSH, utilizado para administración remota del servidor, mientras que los puertos 80 y 443 corresponden a los servicios HTTP y HTTPS utilizados para el funcionamiento de la aplicación web. La presencia del puerto HTTPS indica que la plataforma utiliza cifrado SSL/TLS para proteger la comunicación entre el cliente y el servidor.
Adicionalmente, se detectaron puertos altos abiertos como 10000, 32768 y el rango 49152–49157, algunos identificados por Nmap como servicios desconocidos. Estos puertos podrían pertenecer a servicios internos de la infraestructura cloud utilizada por Railway, aunque requieren un análisis más detallado para determinar si representan una exposición innecesaria de servicios.
Finalmente, el escaneo indicó que 89 puertos se encontraban filtrados o sin respuesta, lo cual sugiere la existencia de mecanismos de seguridad y reglas de firewall implementadas para limitar el acceso externo y reducir la superficie de ataque del sistema.
nmap -sV
Durante el escaneo, Nmap detectó una cantidad inusualmente alta de puertos abiertos categorizados como tcpwrapped (por ejemplo: 10000, 10001, 50006, 58080, entre otros).
Nota: El estado tcpwrapped indica que el firewall o un balanceador de carga del lado del objetivo cerró la conexión inmediatamente después de que Nmap completara el handshake de tres vías TCP. Esto suele ser un indicativo de la presencia de un mecanismo de defensa activo (como un WAF o un sistema de mitigación/DDoS de Railway) diseñado para ofuscar el verdadero estado de la red e invalidar técnicas tradicionales de escaneo.
Posibles Vectores de Ataques:
Fuzzing Web: Concentrar los esfuerzos de intrusión sobre el puerto 443/TCP, ya que el puerto 80 es únicamente un puente de redirección utilizado herramientas como gobuster o ffuf. Posible vulnerabilidad en el OWASP TOP 10 : A01 Control de Acceso Vulnerable
Nmap -A
Puerto 21 SSH:
se realizó una investigación profunda en las bases de datos globales de vulnerabilidades, logrando identificar y validar los siguientes registros de seguridad:
- Investigación en el Repositorio de Vulnerabilidades de Go: Se realizó una consulta técnica en la base de datos oficial de seguridad del lenguaje Go bajo el identificador GO-2025-3487. A través del enlace público pkg.go.dev/vuln/GO-2025-3487, se identificó que el paquete afectado corresponde al componente criptográfico central del lenguaje (golang.org/x/crypto/ssh).
La clasificación oficial de plataformas afectadas (CPE – Common Platform Enumeration) establece que el riesgo compromete de forma generalizada a los despliegues construidos con dicha librería, aplicando un límite estricto hasta (pero excluyendo) la versión 0.35.0 del paquete de SSH. Se recomienda validar la versión del archivo SSH y generar la actualización en caso que sea pertinente.
Puerto 80 HTTP:
Nos indica que re dirige de forma exitosa al protocolo HTTPS Esto confirma que el puerto 80 no expone contenido directamente, sino que actúa como un túnel de reenvío.
PUERTO 443 TCP:
El puerto 443/TCP se encuentra abierto y expone el servicio web principal protegido mediante cifrado SSL/TLS. El análisis demuestra que está correctamente configurado:
Al interactuar con la raíz, el servidor responde con un código controlado HTTP/1.0 404 Not Found Esto denota que el sistema está sanitizando las peticiones y no revela información sensible del backend
Fase 2 del Pentest: DNS, WHOIS y Certificados SSL/TLS
Análisis DNS: Infraestructura al Descubierto
Registro A (IPv4) del subdominio de la aplicación
Registros MX (servidores de correo) del dominio padre railway.app
Registros TXT (SPF, DKIM, verificaciones)
Registros NS (nameservers autoritativos)
Las consultas DNS sobre el dominio objetivo y su dominio padre
railway.app entregaron información valiosa. El registro A confirmó la
IP 66.33.22.152 sin balanceo de carga ni CDN visible, lo que facilita
la identificación del servidor de origen. Los registros MX revelaron
que railway.app usa Google Workspace como plataforma de correo
(aspmx.l.google.com). Los registros TXT expusieron la política SPF
configurada como v=spf1 include:_spf.google.com ~all, que con su
parámetro ~all (softfail en lugar de -all) deja la puerta teóricamente
abierta a la suplantación de correo, agravado por la ausencia de una
política DMARC. Los nameservers (NS) pertenecen a Foundation DNS
(blue.foundationdns.com), no a Cloudflare, lo que descarta protección
DNS adicional de ese proveedor.
WHOIS: El Dominio Bien Gestionado
La consulta WHOIS sobre railway.app (realizada vía ip2whois.com, ya que
la herramienta local de Sysinternals falló al no poder resolver el
servidor WHOIS del TLD .app) confirmó que el dominio fue registrado en
agosto de 2019, tiene expiración en 2028 y su registrador es Namecheap
Inc. Los datos personales del propietario están ocultos por privacidad,
y el estado clientTransferProhibited bloquea transferencias no
autorizadas. No se detectaron riesgos de domain takeover.
### Certificado SSL/TLS: TLS 1.3 y Resistencia Post-Cuántica
El análisis del certificado con openssl s_client mostró una
configuración criptográfica sólida: protocolo TLSv1.3, cifrador
TLS_AES_128_GCM_SHA256 y un intercambio de claves X25519MLKEM768 con
resistencia post-cuántica. El certificado es de tipo wildcard
(*.up.railway.app) emitido por Let’s Encrypt con vigencia de solo tres
meses, una buena práctica que reduce la ventana de exposición ante
una posible filtración de la clave privada. Sin embargo, el escaneo
de headers de seguridad reveló la ausencia completa de HSTS, CSP,
X-Frame-Options y X-Content-Type-Options: cuatro escudos que el
servidor nunca activó. La enumeración de subdominios pasiva mediante
Certificate Transparency (crt.sh) descubrió miles de subdominios de
railway.app, incluyendo jenkins, gitlab, kibana y mysql, lo que
evidencia la amplia superficie de ataque del proveedor cloud.
Descomprimimos la carpeta, copiamos el whois.exe en la carpeta C:\Windows\System32 y ejecutamos el comando desde PowerShell:Descomprimimos la carpeta, copiamos el whois.exe en la carpeta C:\Windows\System32 y ejecutamos el comando desde PowerShell:
Segunda Opción – Desde la pagína Web:
Inspección manual con OpenSSL
Instalamos y configuramos las variables de entorno:
Ejecutamos el comando de OpenSSL
Verificación de cabeceras de seguridad relacionadas con SSL
Verificar HSTS (Strict-Transport-Security)
Verificar CSP (Content-Security-Policy) – buscando upgrade-insecure-requests
Verificar X-Content-Type-Options
Verificar X-Frame-Options
Verificar compresión HTTP (BREACH)
Fase 3 del Pentest: OWASP Top 10 2021 — Los Hallazgos Reales
Esta fue la fase más crítica. Se aplicaron las 10 categorías del
OWASP Top 10 2021 sobre la aplicación en producción con una combinación
de herramientas automatizadas (Nikto, Nmap, curl, Gobuster) y pruebas
manuales controladas.
A01 — Control de Acceso Roto
Las pruebas con curl.exe revelaron que las rutas sensibles como
/dashboard y /.env devuelven respuestas 307 (redirección temporal),
lo que indica protección correcta. Sin embargo, el endpoint /api/users
respondió con HTTP 401 (Unauthorized), lo que confirma la existencia
del recurso y facilita la enumeración de usuarios. Esta es una
vulnerabilidad de severidad media que puede orientar ataques de fuerza
bruta hacia cuentas reales.
A02 — Fallos Criptográficos
El servidor redirige correctamente de HTTP a HTTPS (código 301) y los
cifrados TLS son todos calificados como A por Nmap (AES-256-GCM,
ChaCha20-Poly1305, Perfect Forward Secrecy). Sin embargo, la ausencia
de la cabecera Strict-Transport-Security (HSTS) representa una
vulnerabilidad de severidad media: en la primera conexión HTTP, un
atacante con posición Man-in-the-Middle puede interceptar el tráfico
antes de la redirección a HTTPS (ataque SSL stripping). La compresión
HTTP no está activa, lo que descarta el ataque BREACH.
A03 — Inyección SQL y XSS
Se enviaron payloads clásicos de SQL injection (admin’ OR ‘1’=’1) y
XSS (<script>alert(‘XSS’)</script>) en el formulario de login y
registro, tanto por GET como por POST. En todos los casos el servidor
respondió con 200 OK y la página de login sin ejecutar los scripts ni
devolver errores de base de datos. El uso de Prisma como ORM (que
genera consultas parametrizadas automáticamente) y el escaping nativo
de Next.js parecen mitigar los vectores básicos. Sin embargo, no se
utilizaron herramientas avanzadas como SQLMap ni fuzzing extensivo,
por lo que no se puede descartar vulnerabilidades complejas.
A04 — Diseño Inseguro: El Hallazgo Más Crítico
Este fue el hallazgo de mayor severidad de toda la auditoría. Se
ejecutaron 30 intentos consecutivos de login con credenciales
incorrectas usando métodos HEAD y POST. En ningún caso el servidor
devolvió un código 429 (Too Many Requests), bloqueó la IP, activó un
CAPTCHA, introdujo un retardo progresivo ni mostró un código 401
Unauthorized —en su lugar siempre respondió 200 OK—. Esto confirma
la ausencia total de rate limiting y mecanismos anti-fuerza bruta.
Un atacante puede automatizar miles de intentos por segundo con
herramientas como Hydra usando diccionarios como rockyou.txt, sin que
el sistema lo detecte ni lo bloquee.
A05 — Configuración Incorrecta de Seguridad
Un script que verificó cinco cabeceras HTTP críticas marcó todas como
[FALTA]: Strict-Transport-Security, X-Frame-Options,
X-Content-Type-Options, Content-Security-Policy y X-XSS-Protection.
Adicionalmente, las cabeceras del servidor revelan X-Powered-By:
Next.js y Server: railway-edge, exponiendo la tecnología subyacente
y el proveedor cloud. Estas cabeceras ausentes habilitan ataques
conocidos: clickjacking (sin X-Frame-Options), MIME sniffing (sin
X-Content-Type-Options) y mayor superficie para XSS (sin CSP).
A06 al A10: Resumen
Para A06, la exposición de X-Powered-By: Next.js y la versión de la
librería SSH de Go permiten a un atacante identificar componentes y
buscar CVEs específicos. Para A07, el endpoint /api/users expuesto
con 401 facilita la enumeración de cuentas, y la falta de rate
limiting en el login (analizada en A04) expone directamente la
autenticación a fuerza bruta.
Para A08
los directorios internos no
revelan información privilegiada: acceso correcto y protegido.
Para A09, la infraestructura de Railway bloqueó herramientas
automatizadas como Nikto, lo que sugiere monitoreo básico activo;
no se evidenció un SIEM centralizado ni alertas de seguridad
configuradas. Para A10 (SSRF), no se identificaron funcionalidades
que permitan al usuario suministrar URLs externas en las rutas
públicas analizadas (/login y /register): no se detectaron vectores
SSRF explotables.
[→ Cómo implementar rate limiting en Next.js y NestJS en producción]
(enlace interno Niixer)
Para más información consultar el siguiente documento:
## Conclusiones: Lo que Aprendemos al Hackearnos a Nosotros Mismos
El ejercicio de construir y luego auditar el mismo sistema dejó
lecciones que ningún tutorial puede enseñar:
**Fortalezas confirmadas:** La configuración TLS es robusta (solo
TLSv1.2/1.3 con cifrados A, sin versiones obsoletas). La redirección
HTTP a HTTPS funciona correctamente. El uso de Prisma previene
inyecciones SQL básicas. El certificado tiene vida corta (3 meses) como
buena práctica. No se detectaron vectores SSRF explotables en las rutas
públicas.
**Vulnerabilidades críticas a remediar de inmediato:**
1. Implementar rate limiting: máximo 5 intentos de login por minuto,
bloqueo temporal por IP tras 10 fallos, y CAPTCHA después de 3
intentos fallidos.
2. Agregar las cabeceras HTTP faltantes: HSTS (max-age=31536000),
X-Frame-Options (DENY), X-Content-Type-Options (nosniff) y una
CSP básica (default-src ‘self’).
3. Ocultar la cabecera X-Powered-By para no revelar el framework.
4. Verificar y actualizar golang.org/x/crypto/ssh a la versión ≥0.35.0.
5. Cambiar la respuesta del endpoint /api/users de 401 a 404 para
evitar la enumeración de usuarios.
**La lección más importante:** el Vibe Coding acelera dramáticamente el
desarrollo, pero la velocidad no reemplaza la revisión de seguridad.
Construir rápido con IA es posible; construir rápido y seguro requiere
integrar la seguridad desde el primer prompt, no al final del proyecto.
[→ Checklist de seguridad para aplicaciones Next.js antes de ir a
producción] (enlace interno Niixer)
[→ Cómo agregar headers de seguridad en Next.js con next.config.js]
(enlace interno Niixer)
