Vibe Coding: Posicionamiento Web, Analítica e Inteligencia Digital con IA

El mundo del marketing digital y el desarrollo de software están convergiendo en un punto sin precedentes. Hoy en día, es posible construir una plataforma empresarial completa de posicionamiento web, análisis de métricas e inteligencia digital sin escribir una sola línea de código manualmente (vibe coding).

Precisamente, esto es posible gracias al Vibe Coding, una metodología que está redefiniendo quién puede crear software y cómo se hace. De hecho, usando Google AI Studio como motor de inteligencia artificial, un equipo de la Universidad Central construyó NexusAI: una plataforma SaaS que no solo centraliza herramientas como Google Search Console, Google Analytics, Google Ads, GTM, SEMrush, WooRank y Google My Business, sino que también las integra en un único panel de control empresarial impulsado por IA.

Este artículo documenta qué es el Vibe Coding, cómo funciona, qué herramientas se usaron y, finalmente, cómo se construyó OptiPulse Nexus y Nexus AI desde cero mediante prompts en lenguaje natural.

¿Qué es el Vibe Coding y por qué está cambiando el desarrollo de software?

El Vibe Coding es una metodología de desarrollo de software basada, esencialmente, en la generación automática de código mediante instrucciones en lenguaje natural. En lugar de escribir cada línea de código, el usuario describe qué quiere construir y un modelo de inteligencia artificial lo genera.

El término fue acuñado en febrero de 2025 por Andrej Karpathy, cofundador de OpenAI y exdirector de IA en Tesla. Su impacto fue inmediato: en noviembre de 2025, el Diccionario Collins lo eligió como palabra del año, reconociendo su relevancia cultural y tecnológica a nivel global.

En este enfoque, el rol del creador cambia radicalmente. Ya no es necesario dominar lenguajes de programación como React, TypeScript o Python. La función principal del usuario es guiar, describir y refinar los resultados que produce la IA. Como señaló el propio Karpathy: “No es realmente programar; simplemente veo cosas, digo cosas, ejecuto cosas y copio cosas”.

Figura 1. Vibe coding

La relevancia del Vibe Coding se puede entender en tres dimensiones:

1. Democratización del software: Profesionales de marketing, comunicación, administración y otras áreas pueden transformar ideas en productos digitales funcionales sin depender de un equipo de desarrollo.
2. Aceleración del ciclo de creación: Lo que antes tomaba semanas de planificación técnica y desarrollo puede generarse, probarse y refinarse en horas.
3. Cambio de paradigma: El Vibe Coding no solo cambia cómo se hace el software; también cambia quién puede hacerlo. La barrera para convertir una idea en una aplicación real se reduce casi a cero.

Según Y Combinator, en marzo de 2025 el 25% de sus startups ya tenía bases de código generadas casi por completo mediante IA. Garry Tan, CEO de Y Combinator, afirmó que diez ingenieros pueden realizar hoy el trabajo que antes requería equipos de hasta cien personas.

Ventajas y desventajas del Vibe Coding aplicado a plataformas empresariales

Aplicar Vibe Coding para construir una plataforma SaaS empresarial como OptiPulse Nexus o Nexus AI tiene implicaciones concretas, tanto positivas como negativas, que vale la pena documentar.

Ventajas:

• Velocidad de prototipado: La arquitectura completa de OptiPulse Nexus, incluyendo su sistema de autenticación, dashboard principal, módulos SEO y panel administrativo, fue generada en una fracción del tiempo que hubiera requerido un equipo de desarrollo tradicional. Esto demuestra que, en efecto, el Vibe Coding no solo acelera el proceso, sino que democratiza el acceso a soluciones de software de alto nivel.
• Accesibilidad técnica: Ningún integrante del equipo necesitó dominar Next.js, TypeScript ni TailwindCSS para obtener un resultado de nivel profesional. Es decir, el conocimiento del negocio fue suficiente para guiar a la IA.
• Iteración sin fricción: Cuando un módulo no se comportaba como se esperaba, en lugar de depurar código, se ajustaba el prompt y se regeneraba la solución. Esto redujo significativamente los tiempos de corrección.
• Reducción de costos iniciales: El Vibe Coding permitió validar la arquitectura completa de la plataforma antes de invertir en desarrollo técnico especializado.

Desventajas:

• Calidad y mantenibilidad del código: El código generado por IA puede ser difícil de mantener a largo plazo. Ampliar funcionalidades sobre una base generada automáticamente requiere revisión técnica especializada.
• Vulnerabilidades de seguridad: La rapidez del proceso puede llevar a omitir controles de seguridad críticos. Aceptar código sin revisión expone datos sensibles si no se implementa una auditoría posterior.
• Limitaciones en proyectos de alta complejidad: El Vibe Coding es especialmente efectivo para prototipos, MVPs y plataformas de gestión. Sistemas con lógica de negocio muy compleja aún requieren supervisión técnica profunda.
• Dependencia del modelo de IA: Los resultados dependen directamente de las capacidades y limitaciones del modelo utilizado. En este caso, Google AI Studio con Gemini fue la herramienta central, lo que implica, por tanto, dependencia de su disponibilidad y actualizaciones.

Herramientas para hacer Vibe Coding: el ecosistema que usamos

El ecosistema de herramientas de Vibe Coding se organiza en diferentes categorías según el perfil del usuario y el tipo de proyecto. Para construir OptiPulse Nexus se utilizó principalmente Google AI Studio, pero es importante entender el panorama completo de opciones disponibles en 2025-2026.

Figura 2. Google Ai Studio

Plataformas Full-Stack (sin código o bajo código)

Ideales para construir aplicaciones completas desde cero usando prompts en lenguaje natural:

• Lovable.dev: Una de las más amigables para perfiles no técnicos. Permite construir y desplegar aplicaciones completas, conectar repositorios de GitHub y trabajar con bases de datos mediante Supabase. En 2025 alcanzó una valoración de 6.600 millones de dólares y procesa más de 100.000 proyectos por día.
• Bolt.new: Creada por Stackblitz, permite importar diseños de Figma y convertirlos directamente en código. Incluye un IDE completo en el navegador e integración con GitHub y Supabase.
• Replit: Es una plataforma en la nube que, en esencia, combina entorno de desarrollo y despliegue en una sola interfaz. Gracias a ello, resulta ideal para construir aplicaciones funcionales con persistencia de datos listas para producción.
• Vercel v0: Evolucionó de generador de UI a plataforma completa de desarrollo frontend. En ese proceso, se enfocó en la calidad del código y la seguridad, incorporando además un modo de diseño visual que permite ajustar colores, espaciados y layouts sin perder la estructura del código.

Editores de código con IA (para perfiles técnicos)

• Cursor: Uno de los pioneros del espacio que, además, superó el millón de usuarios en 2025 y permite hacer cambios directamente en archivos del proyecto con soporte para servidores MCP.
• Windsurf: Fork de VS Code que, a diferencia de otras alternativas, ofrece una mejor experiencia de usuario que Cursor y la posibilidad de previsualizar la aplicación directamente desde el editor.
• GitHub Copilot: Integrado en Visual Studio Code y JetBrains, ofrece sugerencias de código en contexto, chat conversacional y, adicionalmente, un modo agente para tareas de múltiples pasos.
• Claude Code: Herramienta de línea de comandos de Anthropic. Lee y comprende la base de código completa al inicio de cada sesión y puede modificar docenas de archivos simultáneamente.

Google AI Studio: la herramienta central de NexusAI

Para la construcción de NexusAI , el equipo utilizó Google AI Studio como plataforma principal de Vibe Coding. Esta elección no fue casual: Google AI Studio ofrece una combinación única de accesibilidad, potencia del modelo Gemini y capacidad de despliegue directo en Google Cloud Run sin configuración adicional.

Herramienta	Nivel	Función clave
Google AI Studio	Principiante / Intermedio	Generación de apps con una sola instrucción y despliegue sin fricciones
Gemini Code Assist	Intermedio / Avanzado	Asistente dentro del IDE: genera, explica y prueba código
Gemini CLI	Intermedio / Avanzado	Agente open-source para flujos en terminal con soporte MCP
Google Antigravity	Todos los niveles	Agentes autónomos que planifican, ejecutan y verifican tareas completas

Google AI Studio fue especialmente útil para este proyecto porque permitió al equipo describir módulos completos en lenguaje natural y obtener código funcional en Next.js, React y TypeScript sin necesidad de configurar un entorno de desarrollo local desde cero. Cada prompt generaba no solo el código sino también la estructura de carpetas, los componentes reutilizables y los estilos en TailwindCSS.

Figura 3. Desarrollo Nexus

Las herramientas de SEO y analítica integradas en NexusAI

NexusAI no es simplemente un dashboard bonito. Su valor real está en la cantidad y calidad de fuentes de datos que centraliza. A continuación se documenta cada herramienta integrada en la plataforma, qué es, para qué sirve y cómo aparece dentro del sistema.

Google Search Console

Google Search Console (GSC) es la herramienta gratuita de Google que permite monitorear cómo aparece un sitio web en los resultados de búsqueda. Entre sus funciones principales, muestra qué palabras clave generan impresiones y clics, en qué posición promedio aparece el sitio, qué páginas tienen mejor rendimiento orgánico y, por último, qué errores técnicos afectan la indexación.

Dentro de NexusAI, los datos de GSC alimentan el módulo de Auditoría SEO, donde el operador puede ver en tiempo real la posición media de sus páginas, el CTR orgánico, las impresiones totales y las keywords con mayor potencial de mejora. A partir de ello, la plataforma cruza estos datos con las recomendaciones del Asesor NexusAI para sugerir, de manera concreta, acciones de optimización.

Google Analytics 4

Google Analytics 4 (GA4) es la versión más reciente de la plataforma de analítica web de Google. A diferencia de su versión anterior, GA4 está basado en eventos, lo que permite un seguimiento más preciso del comportamiento del usuario a lo largo de toda su experiencia en el sitio.

En NexusAI, GA4 alimenta el Panel Nexus con métricas como usuarios activos, sesiones totales, tasa de rebote, tiempo de permanencia, conversiones y fuentes de tráfico. El dashboard distingue entre tráfico orgánico, tráfico pago, tráfico directo y tráfico referido, permitiendo al operador entender de dónde vienen sus visitantes y qué hacen dentro del sitio.

Google Tag Manager

Google Tag Manager (GTM) es una plataforma que permite gestionar etiquetas de seguimiento y snippets de código en un sitio web sin necesidad de modificar directamente el código fuente. Gracias a ello, con GTM se pueden activar píxeles de conversión, configurar eventos personalizados, integrar herramientas de terceros y, además, gestionar scripts de analítica desde un único panel.

Dentro de NexusAI, el módulo de GTM permite visualizar qué etiquetas están activas en cada página, detectar conflictos entre scripts y validar que los eventos de conversión se estén disparando correctamente. Esto es especialmente útil para equipos de marketing que gestionan múltiples campañas simultáneas con diferentes píxeles de seguimiento.

Google Ads

Google Ads es la plataforma de publicidad pagada de Google que, en términos generales, permite crear campañas de búsqueda, display, shopping y video. Asimismo, facilita la segmentación de audiencias, el establecimiento de presupuestos y la medición del retorno de inversión publicitaria (ROAS).

En NexusAI, el módulo de Comando Campañas integra los datos de Google Ads para mostrar el rendimiento de cada campaña activa: impresiones, clics, CTR, costo por clic (CPC), conversiones y costo por conversión. El operador puede comparar el rendimiento de campañas pagas versus tráfico orgánico en el mismo panel, lo que facilita decisiones de inversión más informadas.

Google My Business

Google My Business (GMB), ahora llamado Google Business Profile, es la herramienta que permite a las empresas gestionar su presencia en Google Maps y en los resultados de búsqueda local. Entre sus principales funciones, incluye información del negocio, reseñas de clientes, fotos, horarios y, finalmente, métricas de visibilidad local.

NexusAI integra Google My Business para mostrar métricas de visibilidad local: cuántas veces apareció el perfil en búsquedas, cuántos usuarios solicitaron indicaciones, cuántas llamadas se generaron y cómo evolucionan las reseñas en el tiempo. Este módulo es especialmente relevante para empresas con presencia física que dependen del posicionamiento local.

Google PageSpeed Insights

Google PageSpeed Insights es una herramienta que analiza el rendimiento técnico de una página web tanto en móvil como en escritorio. Genera una puntuación de rendimiento y proporciona recomendaciones específicas para mejorar la velocidad de carga, la experiencia del usuario y las métricas Core Web Vitals.

Dentro de NexusAI, PageSpeed Insights alimenta el módulo de auditoría técnica SEO. A partir de esta integración, la plataforma muestra la puntuación de rendimiento de cada URL auditada, identifica los problemas más críticos y los prioriza, además, según su impacto en el posicionamiento orgánico.

SEMrush

SEMrush es una de las plataformas de SEO y marketing digital más completas del mercado. Entre sus múltiples funcionalidades, ofrece análisis de palabras clave, auditorías de sitio, seguimiento de posiciones, análisis de backlinks, inteligencia competitiva y, por último, datos de tráfico estimado para cualquier dominio.

En NexusAI, SEMrush potencia el módulo de Inteligencia de Mercado y Competidores. Gracias a esta integración, el operador puede comparar el perfil SEO de su dominio frente al de sus competidores directos, identificar las keywords en las que la competencia supera a su sitio y, adicionalmente, detectar oportunidades de contenido con alto volumen de búsqueda y baja dificultad.

WooRank

WooRank es una herramienta de auditoría SEO y análisis de sitios web que evalúa más de 70 criterios técnicos, de contenido y de usabilidad. Genera reportes detallados con puntuaciones por categoría y recomendaciones priorizadas para mejorar el posicionamiento.

Dentro de NexusAI, WooRank complementa el módulo de Auditoría SEO con un análisis más granular de factores on-page: estructura de encabezados, densidad de palabras clave, metaetiquetas, compatibilidad móvil, velocidad, accesibilidad y presencia en redes sociales. Su puntuación global aparece como un indicador adicional dentro del SEO Score del dashboard.

Tabla comparativa de herramientas integradas en NexusAI

Herramienta	Tipo	Datos que aporta a NexusAI
Google Search Console	SEO orgánico	Posiciones, impresiones, CTR, keywords
Google Analytics 4	Analítica web	Sesiones, usuarios, conversiones, fuentes de tráfico
Google Tag Manager	Gestión de etiquetas	Estado de scripts, eventos, píxeles activos
Google Ads	Publicidad paga	Campañas, CPC, ROAS, conversiones pagas
Google My Business	Visibilidad local	Búsquedas locales, reseñas, llamadas, maps
PageSpeed Insights	Rendimiento técnico	Core Web Vitals, velocidad, puntuación móvil
SEMrush	Inteligencia competitiva	Keywords, backlinks, tráfico estimado, competidores
WooRank	Auditoría SEO	Score on-page, usabilidad, factores técnicos

Análisis de Sentimientos y de Mercado en NexusAI

Dos de los módulos más diferenciadores de NexusAI frente a las herramientas tradicionales de SEO son el análisis de sentimientos y la inteligencia de mercado y competencia. Mientras que plataformas como GSC o SEMrush responden a la pregunta ¿cómo está posicionado mi sitio?, estos módulos responden preguntas más profundas: ¿qué siente mi audiencia sobre mi marca? y ¿qué está haciendo mi competencia que yo no estoy viendo?

Análisis de Sentimientos

El análisis de sentimientos es una técnica de inteligencia artificial que procesa texto —comentarios, reseñas, menciones en redes sociales, respuestas de formularios— y lo clasifica según la emoción predominante: positivo, negativo o neutral. Más allá de simplemente contar menciones, permite entender, en consecuencia, el tono con el que los usuarios hablan de una marca, un producto o una campaña.

Dentro de NexusAI, el módulo de IA de Sentimiento procesa múltiples fuentes de texto simultáneamente y, como resultado, genera un dashboard emocional con las siguientes métricas:

• Índice de satisfacción general: Porcentaje de menciones positivas versus negativas en un período determinado.
• Tendencias emocionales: Evolución del sentimiento a lo largo del tiempo, con alertas automáticas cuando se detecta un pico de menciones negativas.
• Análisis por fuente: Diferencia entre el sentimiento en reseñas de Google My Business, comentarios de redes sociales y respuestas directas de usuarios.
• Palabras clave emocionales: Las palabras más frecuentes asociadas a emociones positivas y negativas, útiles para ajustar el tono del contenido y la comunicación de marca. Reportes automáticos: El Asesor NexusAI genera reportes periódicos con un resumen del estado emocional de la marca y recomendaciones de acción.

Este módulo es especialmente valioso para equipos de marketing que gestionan campañas activas, ya que permite detectar en tiempo real si una acción publicitaria está generando reacciones negativas antes de que escale a una crisis de reputación.

Análisis de Mercado y Competencia

El módulo de Inteligencia de Mercado de NexusAI va más allá del monitoreo interno. Permite a los operadores entender el ecosistema competitivo en el que opera su marca, identificar oportunidades que la competencia no está aprovechando y anticipar movimientos del mercado antes de que impacten el posicionamiento.

Este módulo integra datos de SEMrush y fuentes externas para construir una vista 360° del mercado:

• Mapa de competidores: Visualización de los principales competidores por dominio, con comparación de tráfico estimado, autoridad de dominio y cantidad de keywords en común.
• Gap de keywords: Palabras clave por las que la competencia aparece en los primeros resultados pero el sitio propio no tiene presencia. Cada gap representa una oportunidad de contenido.
• Análisis de backlinks: Comparación del perfil de enlaces entrantes del sitio propio frente al de los competidores. Un competidor con más backlinks de calidad generalmente tiene mayor autoridad y mejor posicionamiento.
• Tendencias de mercado: Evolución del volumen de búsqueda de las keywords más relevantes para el sector, útil para anticipar cambios en la demanda. Benchmarking de rendimiento: Comparación directa del SEO Score, velocidad de carga y métricas de engagement entre el sitio propio y los principales competidores.

El corazón de NexusAI es su Panel Nexus, el dashboard principal donde convergen todas las fuentes de datos en una vista unificada. Desde allí, el operador empresarial tiene acceso inmediato al estado completo de su presencia digital sin necesidad, por tanto, de abrir múltiples herramientas.

El Dashboard de NexusAI: métricas en tiempo real

El dashboard está organizado en dos niveles de métricas:

KPIs principales (fila superior):

• Resonancia Orgánica: total de visitas provenientes de búsqueda orgánica que, en la versión documentada, alcanzó 12.450 con un crecimiento del +14,2%.
• Posición Media: posición promedio en los resultados de búsqueda de Google, con un valor de 4,8.
• Eficiencia de CTR: porcentaje de usuarios que hacen clic al ver el sitio en resultados, el cual se sitúa en un 2,4%.
• Tasa de Rebote: porcentaje de sesiones de una sola página que, en este caso, corresponde al 42,1%.

Figura 4. Dashboard

KPIs secundarios (fila inferior):

• Usuarios Activos: 1.204
• Sesiones Totales: 5,6k
• Conversiones: 342
• Alcance Neural: 450k (métrica de alcance total estimado incluyendo impresiones orgánicas y pagas)

La tabla de Páginas con Mejor Rendimiento complementa los KPIs mostrando el detalle por URL: visitas individuales, CTR por página, posición media y tendencia de crecimiento. Esto permite identificar qué contenido está funcionando y replicar su estrategia en otras secciones del sitio.

El dashboard incluye además filtros temporales (30 días, 90 días, 12 meses), botón de exportación de reportes y acceso directo al módulo de Desplegar Auditoría, que lanza un análisis SEO completo del dominio con un solo clic.

Figura 5. El Dashboard de NexusAI: métricas en tiempo real

El sistema de autenticación y la experiencia de usuario de NexusAI

Antes de acceder a cualquier módulo, el operador pasa por el sistema de autenticación de NexusAI, diseñado con un estilo futurista y empresarial que refleja desde el primer contacto el nivel premium de la plataforma.

La pantalla de inicio de sesión presenta los siguientes elementos:

La identidad visual incorpora el logo Nexus junto con el subtítulo “Sistema de Inteligencia Central”, estableciendo desde el primer momento el posicionamiento de marca de la plataforma.

Asimismo, los campos de autenticación —Correo del operador y Código de Encriptación— utilizan una terminología técnica deliberada que refuerza la percepción de seguridad empresarial.

Por otro lado, el botón principal “ENTRAR AL NODO” reemplaza el genérico “Iniciar sesión” con un lenguaje alineado con el universo conceptual de la plataforma.

De igual manera, los protocolos externos permiten el acceso mediante Google y Microsoft OAuth, facilitando que las organizaciones autentiquen a sus operadores con credenciales corporativas existentes sin necesidad de crear contraseñas adicionales.

Finalmente, el enlace “Recuperar llave” integra la recuperación de contraseña directamente dentro del formulario de acceso.

El diseño dark mode con fondo azul profundo, bordes sutiles y tipografía en mayúsculas genera una experiencia visual coherente con plataformas SaaS de nivel enterprise como Datadog o Vercel Dashboard.

Figura 6. Login Nexus

Los módulos especializados de NexusAI en detalle

SEO Technical Audit

El módulo de Auditoría SEO Técnica es uno de los más potentes de NexusAI, ya que permite ingresar cualquier dominio y lanzar, con tan solo un clic, un análisis técnico completo.

En el ejemplo documentado con el dominio https://niixer.com/, la auditoría arrojó los siguientes resultados:

• Technical Score: 77/100 — clasificado como “Optimizable”, lo que indica que el sitio funciona pero tiene margen de mejora significativo.
• Load Time: 2.28 segundos — por encima del umbral recomendado de 2 segundos para experiencia óptima.
• Backlinks: 8.019 enlaces entrantes indexados.
• Domain Authority: 52/100 — autoridad media, competitiva en nichos específicos.
• LCP Metric: 0.58 segundos — métrica de Core Web Vitals que mide la velocidad de carga del elemento visual más grande de la página.

Deficiencias críticas detectadas:

• Estructura del sitio compleja detectada
• Múltiples etiquetas H1 en páginas profundas
• Optimización necesaria para el dominio principal

Advertencias secundarias:

• Imágenes sin atributos alt
• Bundle CSS superior a 200kb
• Scripts externos bloqueando el hilo principal

Este nivel de detalle técnico, generado automáticamente por NexusAI, equivale a lo que un especialista SEO senior tardaría varias horas en producir manualmente usando múltiples herramientas por separado.

Figura 7. SEO Technical Audit

Site Crawler

El módulo Site Crawler realiza un rastreo profundo del sitio y, al mismo tiempo, simula el comportamiento de los bots de Google para identificar problemas de indexación, errores HTTP y estructura de navegación.

En el análisis documentado:

• Health Score: 82% — el sitio presenta buena salud general con algunos problemas técnicos corregibles.
• Páginas indexadas: 332 URLs rastreadas exitosamente.
• Velocidad promedio de carga: 2.18 segundos por página.
• Árbol de crawl: Visualización jerárquica de todas las URLs del sitio con su código de estado HTTP (200 OK, 301 Redirect, 403 Forbidden, 500 Server Error).

Problemas técnicos detectados:

• /api/v1/data — Error 403 Forbidden Access — Prioridad Alta
• /old-page — Error 301 Redirect Loop — Prioridad Media

La detección de estos errores es crítica para el SEO porque los bots de Google penalizan los sitios con errores de servidor no resueltos, reduciendo la frecuencia de rastreo e indexación de contenido nuevo.

Figura 8. Site Crawler

Keyword Strategy

El módulo de Estrategia de Keywords reúne en una única vista el seguimiento del posicionamiento orgánico, así como el volumen de búsqueda y la dificultad de las palabras clave.

Las métricas principales del módulo muestran:

• Domain Authority: 58/100 con crecimiento del +2.4%
• Total Backlinks: 14.200 con crecimiento del +12.5%
• Posición Promedio: 4.2 con variación de -0.5

La gráfica de Keyword Position Trend muestra la evolución de las posiciones de las keywords rastreadas durante el mes de octubre, con una tendencia de mejora progresiva que, en consecuencia, indica que las acciones de optimización implementadas están generando resultados medibles.

Figura 9. Keyword Strategy

Analytics y Executive Dashboard

El Executive Dashboard integra todas las fuentes de datos en una vista ejecutiva diseñada para facilitar la toma de decisiones de manera rápida.

Los KPIs principales del dashboard muestran:

• Health Score: 84/100 con crecimiento del +4% versus el mes anterior
• Total Traffic: 1.2 millones de visitas con crecimiento del +12%
• Active Keywords: 450 keywords posicionadas activamente con +24 nuevas
• Site Speed: 98/100 — rendimiento técnico excelente

La gráfica de Performance Trends (30 días) muestra la evolución diaria y semanal del tráfico, con picos identificables que permiten correlacionar, de manera directa, las acciones de marketing con los resultados de visibilidad. Por ejemplo, en el caso documentado, el jueves registró un tráfico de 18.000 visitas, dato visible en el tooltip interactivo de la gráfica.

Figura 10. Analytics y Executive Dashboard

El panel de AI Sentiment Analysis visible en el costado derecho del dashboard muestra simultáneamente el análisis emocional de la marca, convirtiendo así el Executive Dashboard en una vista verdaderamente unificada de rendimiento técnico, tráfico y percepción de marca.

Figura 11. Interactividad del dashboard

Cómo se construyó NexusAI: los prompts usados en Google AI Studio

Esta sección documenta el proceso real de construcción de NexusAI mediante Vibe Coding con Google AI Studio. Al igual que en cualquier proyecto de Vibe Coding profesional, el proceso siguió un ciclo iterativo: prompt inicial para establecer la arquitectura general, seguido de prompts de refinamiento para desarrollar cada módulo en detalle.

El conocimiento del negocio fue el activo principal, puesto que ningún integrante del equipo necesitó dominar Next.js, TypeScript o TailwindCSS para obtener una plataforma de nivel empresarial. Lo que sí fue indispensable, en cambio, fue la capacidad de describir con precisión qué debía construirse, cómo debía comportarse y qué problema real debía resolver.

Estructura de los prompts utilizados

Los prompts de NexusAI siguieron una estructura de cinco elementos que, además, resultó coherente con las mejores prácticas documentadas para el Vibe Coding profesional:

• Contexto del producto: Descripción del tipo de plataforma, su propósito y el perfil del usuario que la operará.
• Stack tecnológico: Especificación explícita de las tecnologías a utilizar para evitar que la IA elija frameworks incompatibles.
• Módulos requeridos: Lista numerada y detallada de cada funcionalidad esperada.
• Requisitos de diseño: Estilo visual, modo oscuro, responsive, animaciones y componentes de UI específicos.
• Arquitectura de carpetas: Estructura de directorios esperada para garantizar modularidad y escalabilidad del código generado.

Lecciones clave del proceso de construcción de NexusAI

El caso de NexusAI ilustra varias buenas prácticas del Vibe Coding aplicado a plataformas empresariales reales:

• El rol del negocio sobre el rol técnico: El equipo no necesitó saber programar para definir una arquitectura enterprise. En cambio, el conocimiento de qué métricas necesita un equipo de marketing digital fue suficiente para guiar a Google AI Studio hacia una solución funcional y específica.
• Del prompt general al específico: El primer prompt estableció la arquitectura y el estilo visual. El segundo prompt refinó la lógica de negocio, los módulos avanzados y los estándares enterprise. Esta secuencia evitó que la IA generara código inconsistente entre módulos.
• Las reglas de diseño deben hacerse explícitas: Especificar dark mode, mobile-first, Framer Motion para animaciones y Shadcn UI para componentes no fue opcional; de hecho, sin estas instrucciones, la IA habría elegido sus propios criterios visuales, produciendo resultados genéricos.
• El stack tecnológico debe declararse desde el inicio: Indicar Next.js con App Router, TypeScript y TailwindCSS en el primer prompt garantizó que todos los módulos generados en prompts posteriores fueran compatibles entre sí. En consecuencia, omitir esta especificación es una de las causas más frecuentes de incompatibilidades en proyectos de gran escala.
• Vibe Coding. Iterar, no regenerar: Cuando un módulo no se comportaba exactamente como se esperaba, el equipo ajustó el prompt de ese módulo específico en lugar de regenerar la plataforma completa. Este principio preservó el trabajo acumulado y redujo significativamente los tiempos de corrección.

Conclusiones

NexusAI representa algo más que una plataforma de posicionamiento web. Es, ante todo, la demostración práctica de que el Vibe Coding, aplicado con criterio y conocimiento del negocio, puede producir soluciones de nivel enterprise sin que el equipo creador domine lenguajes de programación.

El recorrido documentado en este artículo, desde los conceptos fundamentales del Vibe Coding hasta los prompts reales utilizados en Google AI Studio, demuestra que la barrera entre tener una idea y convertirla en un producto digital funcional se ha reducido drásticamente. Lo que antes requería un equipo de desarrolladores senior trabajando durante meses, hoy, en cambio, puede estructurarse en días mediante instrucciones precisas en lenguaje natural.

Sin embargo, el caso de NexusAI también deja lecciones importantes sobre los límites de esta metodología:

El Vibe Coding amplifica el conocimiento, no lo reemplaza. La razón por la que NexusAI tiene módulos coherentes y métricas relevantes no es la IA: es que el equipo sabía exactamente qué necesita un profesional de marketing digital para tomar decisiones. Google AI Studio no podría haber generado un módulo de análisis de sentimientos útil si el equipo no hubiera sabido describir qué es el sentimiento de marca y para qué sirve medirlo.

La calidad del prompt determina la calidad del resultado. Los dos prompts documentados en este artículo no fueron escritos en cinco minutos, sino que fueron el resultado de un proceso de estructuración deliberada: definir el contexto, especificar el stack, listar los módulos, describir el diseño y declarar la arquitectura de carpetas. Cada uno de esos elementos fue, además, una decisión consciente que redujo la ambigüedad para la IA y mejoró la coherencia del código generado.

El Vibe Coding es especialmente poderoso para plataformas de datos. NexusAI integra Google Search Console, Google Analytics, Google Ads, GTM, Google My Business, PageSpeed Insights, SEMrush y WooRank en un único panel. Asimismo, este tipo de plataforma, donde el valor está en centralizar y visualizar datos de múltiples fuentes, es exactamente el escenario donde el Vibe Coding ofrece el mayor retorno, ya que la lógica de negocio es clara, los componentes son reutilizables y el diseño puede describirse con palabras.

La seguridad y el mantenimiento siguen requiriendo supervisión humana. Como en cualquier proyecto de Vibe Coding, el código generado por IA debe ser auditado antes de pasar a producción. La velocidad de desarrollo no puede sacrificar la revisión de vulnerabilidades, especialmente en una plataforma que maneja datos analíticos y credenciales de acceso a herramientas empresariales.

El futuro del marketing digital y el posicionamiento web estará cada vez más mediado por plataformas de inteligencia centralizada como NexusAI. La pregunta ya no es si las empresas necesitan este tipo de soluciones: es quién las construirá primero. Y gracias al Vibe Coding, la respuesta ya no está reservada exclusivamente para equipos con presupuestos millonarios de desarrollo.

Links de Optipulse Nexus y NexusAI

https://optipulse-seo-empresarial-378768403291.us-west2.run.app

https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app/

Vídeo

---

Auditoría de Seguridad: Pentesting

En este apartado se presenta una revisión inicial de seguridad sobre la aplicación NexusAI SEO Analytics. Para ello, se realizaron pruebas básicas de reconocimiento, validación de servicios expuestos y revisión general frente a las categorías OWASP Top 10. Además, el análisis se planteó desde un enfoque académico y controlado, sin explotación agresiva ni afectación del servicio.

Reconocimiento de red

Primero, se ejecutaron pruebas de reconocimiento para identificar información pública del dominio, infraestructura utilizada, resolución DNS, puertos visibles y configuración SSL/TLS. De esta manera, fue posible obtener una visión general del entorno antes de revisar los riesgos de seguridad.

PING

Traceroute

Salto	IP	Tiempo aprox.	Análisis
1	10.100.35.102	3–5 ms	Primer salto interno. Es una IP privada
2	186.121.143.57	5–6 ms	Ya sales a una red pública. Puede ser ISP
3	190.131.207.2	5–6 ms	Nodo del proveedor
4	190.131.207.4	4–5 ms	Nodo del proveedor
5	190.242.157.13	5–9 ms	Salto intermedio hacia la red de Google
6	34.143.77.2	5–6 ms	Llegada al destino en Google Cloud..

Consulta WHOIS

La consulta WHOIS permitió revisar información pública asociada al dominio de la aplicación. En este caso, el resultado confirma que la aplicación se encuentra alojada sobre infraestructura cloud administrada por Google.

Además, no se evidenció exposición de información sensible del propietario de la aplicación, ya que el dominio forma parte de la plataforma administrada run.app. Por lo tanto, la información visible corresponde principalmente a la infraestructura del proveedor cloud y no a datos privados del responsable del sitio.

Resolución DNS

Posteriormente, se validó la resolución DNS del dominio. La presencia de varias direcciones IP indica que el sitio utiliza infraestructura distribuida, posiblemente con balanceo de carga y alta disponibilidad.

Esto es normal en servicios cloud como Google Cloud Run. Asimismo, este comportamiento ayuda a distribuir el tráfico y mejorar la disponibilidad de la aplicación, especialmente cuando el servicio recibe múltiples solicitudes.

Escaneo de puertos con Nmap

Después, se realizó un escaneo de puertos con Nmap para identificar los servicios visibles desde el exterior. Esta prueba permite conocer qué puertos responden y, además, ayuda a detectar posibles superficies de exposición.

El escaneo identificó tres puertos abiertos o protegidos:

Puerto	Servicio	Análisis
25/tcp	tcpwrapped	Posible servicio filtrado o protegido. No se identificó versión.
80/tcp	tcpwrapped	Puerto HTTP, probablemente usado para redirección hacia HTTPS.
443/tcp	tcpwrapped	Puerto HTTPS, usado para el tráfico seguro de la aplicación.

En general, el resultado no muestra versiones expuestas de servicios. Sin embargo, la presencia de puertos protegidos indica que existe una capa de filtrado o control que limita la identificación directa de los servicios.

Validación HTTP

También se revisó la respuesta HTTP inicial de la aplicación. La aplicación responde correctamente desde infraestructura de Google y realiza una redirección HTTP 302 Found.

Sin embargo, en la respuesta inicial no se evidenciaron algunos headers de seguridad recomendados. Por esta razón, este punto se relaciona directamente con la categoría A05 — Security Misconfiguration de OWASP.

Validación SSL/TLS

Finalmente, dentro del reconocimiento técnico se validó la configuración SSL/TLS del sitio. La configuración observada es adecuada, ya que no se evidenciaron errores de certificado, problemas de confianza ni desajustes entre el dominio y el certificado.

Además, el uso de HTTPS permite proteger la comunicación entre el navegador del usuario y la aplicación. En consecuencia, este punto representa un aspecto positivo dentro de la revisión inicial.

Consultar registros DNS (A, MX, NS, TXT)

~ Tipo A de registro DNS  (IPv4)

En el registro A se observa que el dominio sí existe y apunta a varias direcciones IP públicas de Google Cloud (34.143.x.x). Esto es normal en servicios como Google Cloud Run, porque usan balanceo de carga y múltiples servidores para alta disponibilidad. La “respuesta no autoritativa” significa que la respuesta vino desde el DNS de tu red (192.168.10.1) y no directamente del servidor oficial del dominio.

~ Tipo MX de registro DNS  (correo)

El registro MX normalmente muestra servidores de correo, pero aquí realmente aparece información SOA (Start of Authority) de run.app. Eso indica que este subdominio no tiene correo configurado, algo totalmente normal porque Cloud Run está pensado para aplicaciones web y APIs, no para email. También confirma que Google administra el DNS del dominio.

~ Tipo NS de registro DNS (Name Servers)

El registro NS muestra que los servidores DNS responsables del dominio pertenecen a Google (ns1.google.com). En otras palabras, Google controla la resolución DNS de run.app. Los valores de refresh, retry y TTL indican cada cuánto tiempo los DNS sincronizan la información y cuánto tiempo guardan la caché.

~ Tipo TXT de registro DNS 

El registro TXT tampoco devuelve textos específicos para ese subdominio, por eso vuelve a mostrar información general del dominio run.app. Esto significa que no hay verificaciones TXT personalizadas configuradas allí (como SPF, DKIM, verificaciones de Google, etc.). Es normal en endpoints automáticos de Cloud Run.

Evaluación OWASP Top 10

A continuación, se presenta la revisión de las categorías OWASP Top 10 aplicadas al sitio. Esta evaluación no reemplaza una auditoría profunda con acceso al código fuente, pero sí permite identificar riesgos visibles desde el exterior.

A01 — Broken Access Control

Esta categoría evalúa si un usuario puede acceder a recursos o información sin tener permisos. Por ejemplo, se revisa si una ruta privada puede abrirse directamente sin iniciar sesión.

Prueba realizada

Se intentó acceder directamente a la siguiente ruta:

/user/1

Resultado

La aplicación redirigió al login. Por lo tanto, no se evidenció acceso directo a información privada mediante esta prueba básica.

A02 — Cryptographic Failures

Esta categoría revisa fallos relacionados con cifrado y protección de datos sensibles. En este caso, la revisión se enfocó en el certificado SSL/TLS, la confianza del dominio y la solidez de la configuración criptográfica del servidor.

Prueba realizada

Se analizó el certificado SSL/TLS del sitio mediante la herramienta Qualys SSL Labs (ssllabs.com/ssltest), que evalúa de forma exhaustiva la configuración de cifrado, los protocolos soportados, la cadena de confianza del certificado y la presencia de vulnerabilidades conocidas en la capa de transporte.

Resultado

El análisis arrojó una calificación de grado A en los 16 servidores que conforman la infraestructura de balanceo de carga de la aplicación, tanto en direcciones IPv4 (34.143.72.2 — 34.143.79.2) como IPv6 (2600:1901:...). El certificado es válido, confiable y emitido por Google Trust Services, no se observaron errores de confianza durante la validación, la configuración de cifrado cumple con los estándares actuales de seguridad, y la calificación fue uniforme en todos los servidores, lo que evidencia una configuración consistente a nivel de infraestructura.

No se identificaron fallos criptográficos en la capa de transporte. La implementación de HTTPS con certificado de grado A representa una protección adecuada para los datos en tránsito entre el usuario y el servidor.

A03 — Injection

Esta categoría analiza riesgos como SQL Injection, XSS, command injection o inyección en parámetros. Para esta revisión inicial, se aplicó una prueba básica con un payload de XSS reflejado en la URL.

Prueba realizada

Se probó el siguiente payload en la URL:

/<script>alert(1)</script>

Resultado

El script no se ejecutó. Por consiguiente, no se evidenció una ejecución directa de XSS reflejado con este payload básico. No obstante, sería recomendable complementar esta prueba con validaciones sobre formularios, parámetros y entradas reales de usuario.

A04 — Insecure Design

Esta categoría evalúa fallos en el diseño de la lógica del sistema. Es decir, no se enfoca solamente en errores técnicos, sino también en decisiones de diseño que podrían permitir abuso de funcionalidades.

Resultado

No se observaron fallos lógicos visibles desde el exterior. Además, la aplicación muestra un flujo de autenticación antes de permitir acceso a funcionalidades internas.

Prueba — Acceso a rutas privadas sin login

https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app/dashboard

https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app/settings

https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app/users

Prueba	URL intentada	Resultado
1	/dashboard + /settings (pegadas juntas)	Redirigió al login
2	/settings	Redirigió al login
3	/users	Redirigió al login

Se intentó acceder directamente a las rutas /dashboard, /settings y /users sin haber iniciado sesión previamente; en los tres casos la aplicación interceptó la solicitud y redirigió automáticamente a la pantalla de login sin exponer contenido interno ni datos sensibles, lo que confirma que el sistema implementa correctamente un middleware de autenticación que protege todas las rutas privadas. Adicionalmente, se observó que al ingresar URLs malformadas (como la concatenación accidental de múltiples rutas), el sistema respondió de igual manera redirigiendo al login en lugar de generar un error visible, lo cual representa un comportamiento seguro y consistente.

Aunque el comportamiento observado es positivo, esta categoría requiere una revisión más profunda de reglas de negocio, roles, permisos y flujos internos. Por lo tanto, con pruebas externas solo se puede emitir una conclusión parcial.

A05 — Security Misconfiguration

Esta categoría revisa configuraciones inseguras, encabezados HTTP ausentes, archivos sensibles expuestos, errores visibles o permisos mal definidos. En esta auditoría, fue la categoría con mayor oportunidad de mejora.

Pruebas realizadas

Se ejecutaron tres validaciones. La primera consistió en analizar los headers HTTP de respuesta del servidor mediante el comando curl -I https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app. La segunda se realizó desde las herramientas de desarrollo del navegador (F12 → Network → Response Headers), complementando y contrastando los resultados obtenidos en terminal. La tercera consistió en intentar acceder directamente al archivo de configuración .env mediante la URL https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app/.env.

curl -I https://nexusai-seo-analytics-platform-20646856843.us-east1.run.app

La segunda se realizó desde las herramientas de desarrollo del navegador (F12 → Network → Response Headers), lo que permitió complementar y contrastar los resultados obtenidos en terminal.

También se intentó acceder al archivo .env para comprobar si existía exposición de variables sensibles.

Esta categoría revisa configuraciones inseguras, encabezados HTTP ausentes, archivos sensibles expuestos, errores visibles o permisos mal definidos. En esta auditoría, fue la categoría con mayor oportunidad de mejora.

Resultados

La ejecución del comando curl arrojó una respuesta HTTP/1.1 200 OK en la que se identificaron dos hallazgos de exposición de información: el header x-powered-by: Express revela que el backend está construido sobre Node.js con Express, y el header server: Google Frontend expone la infraestructura subyacente de Google Cloud Run; ambos datos podrían ser aprovechados por un atacante para orientar ataques dirigidos a esas tecnologías específicas. La inspección desde el navegador confirmó estos resultados y permitió identificar que el header Referrer-Policy sí está presente pero únicamente en respuestas de recursos estáticos, no en la respuesta principal del servidor. Finalmente, el intento de acceso al archivo .env no expuso ninguna variable de entorno, ya que el servidor redirigió automáticamente al login, lo cual representa un comportamiento seguro y esperado en un entorno de producción.

Headers auditados

Header	Estado
Content-Security-Policy	❌ Ausente
Strict-Transport-Security	❌ Ausente
X-Frame-Options	❌ Ausente
X-Content-Type-Options	❌ Ausente
Referrer-Policy	⚠️ Parcial — solo en recursos estáticos
Permissions-Policy	❌ Ausente
X-Powered-By: Express	⚠️ Presente — revela te

A06 — Vulnerable and Outdated Components

Esta categoría evalúa el uso de componentes vulnerables o desactualizados. Desde una revisión externa no siempre es posible identificar frameworks, librerías o versiones internas, ya que depende del nivel de exposición que el servidor permita hacia el exterior.

Prueba realizada

Se ejecutó un escaneo con Nmap 7.98 mediante Docker para intentar identificar versiones de servicios expuestos en el servidor:

docker run --rm -it instrumentisto/nmap -sV -Pn nexusai-seo-analytics-platform-20646856843.us-east1.run.app

Resultado

El escaneo completó el análisis de 1000 puertos TCP en 99.95 segundos, encontrando únicamente dos puertos abiertos: el puerto 80/tcp identificado como HTTP con el valor Google Frontend, y el puerto 443/tcp como SSL/HTTPS sin versión determinada. Los 998 puertos restantes aparecieron como filtrados sin respuesta. Nmap intentó identificar los servicios mediante fingerprinting pero no logró determinar versiones específicas de frameworks, librerías ni servicios internos, lo que indica que Google Cloud Run actúa como proxy inverso ocultando activamente la tecnología subyacente. Por lo tanto, no se evidenció exposición directa de componentes vulnerables o desactualizados desde el exterior.

Recomendación

Se recomienda complementar esta revisión externa con auditorías internas mediante herramientas como npm audit para detectar dependencias con vulnerabilidades conocidas, revisión periódica del archivo package.json para mantener las librerías actualizadas, y análisis del pipeline de despliegue para garantizar que no se incluyan componentes con CVEs reportados en cada nueva versión publicada.

A07 — Identification and Authentication Failures

Esta categoría evalúa fallos en login, sesiones, contraseñas y recuperación de cuentas. La revisión se realizó observando el comportamiento de las rutas privadas, el formulario de autenticación y la respuesta del sistema ante intentos de acceso con credenciales incorrectas.

Pruebas realizadas

Se ejecutaron dos pruebas. La primera consistió en intentar acceder directamente a rutas privadas sin haber iniciado sesión. La segunda consistió en realizar múltiples intentos de inicio de sesión consecutivos con credenciales incorrectas sobre la cuenta admin@nexusai.local para evaluar si el sistema aplicaba algún mecanismo de protección ante fuerza bruta.

Resultado

Las rutas privadas redirigieron correctamente al login en todos los casos, confirmando que existe una barrera de autenticación activa. La aplicación ofrece además opciones de autenticación mediante Google y Microsoft como alternativas al formulario tradicional. Sin embargo, al realizar múltiples intentos fallidos de inicio de sesión, el sistema respondió en todos los casos únicamente con el mensaje “Credenciales inválidas.” sin aplicar ningún mecanismo de protección adicional: no se activó bloqueo temporal de la cuenta, no apareció captcha, no se limitó la cantidad de intentos permitidos ni se notificó al usuario legítimo sobre la actividad sospechosa. Esto indica que el endpoint POST /api/auth/login es vulnerable a ataques de fuerza bruta.

Recomendación

Se recomienda implementar rate limiting en el endpoint de login para limitar el número de intentos por IP, bloqueo temporal de cuentas tras un número definido de intentos fallidos, y opcionalmente un captcha como capa adicional de protección. Complementariamente, sería necesario evaluar las políticas de contraseña, la expiración de sesiones y la configuración de los proveedores OAuth para una revisión completa de esta categoría.

A08 — Software and Data Integrity Failures

Durante la evaluación externa se realizaron pruebas orientadas a identificar exposición de archivos sensibles y tecnologías relacionadas con el proceso de despliegue de la aplicación. A través de solicitudes HTTP utilizando curl, se observó que la aplicación se encuentra desplegada sobre Google Cloud Run y utiliza un entorno basado en Express/Node.js, evidenciado por encabezados como X-Powered-By: Express, Server: Google Frontend y X-Cloud-Trace-Context.

Adicionalmente, se intentó acceder a archivos potencialmente sensibles asociados a dependencias y configuración, tales como package-lock.json, yarn.lock y .env. Sin embargo, las respuestas obtenidas no expusieron directamente el contenido de dichos archivos, sino que redirigieron al frontend principal de la aplicación. Esto sugiere la existencia de mecanismos básicos de protección o configuración de rutas que impiden la exposición directa de información sensible desde el exterior.

También se identificó el uso de archivos estáticos versionados dentro de la carpeta /assets, lo cual puede indicar prácticas de empaquetado automatizado y control de versiones durante el despliegue. No obstante, debido a la falta de acceso al repositorio, pipeline CI/CD y configuraciones internas, no fue posible validar completamente controles relacionados con integridad de dependencias, protección de ramas, revisión de paquetes o verificación de artefactos antes del despliegue.

Por esta razón, se recomienda complementar la seguridad del ciclo de desarrollo mediante controles de validación de dependencias, análisis automático de vulnerabilidades, gestión segura de secretos y mecanismos de integridad dentro del pipeline de despliegue.

A09 — Security Logging and Monitoring Failures

Durante las pruebas externas se evaluó el comportamiento de la aplicación frente a solicitudes inválidas, rutas inexistentes y métodos HTTP no permitidos, con el objetivo de identificar posibles fallos de monitoreo, manejo de errores y exposición de información sensible.

Al realizar solicitudes hacia rutas inexistentes, como /prueba123, /admin y /api/test, la aplicación respondió redirigiendo nuevamente al frontend principal en lugar de exponer errores internos, stack traces o mensajes detallados del servidor. Esto evidencia un manejo controlado de rutas y errores desde el lado del frontend, reduciendo la exposición de información técnica sensible hacia usuarios externos.

También se ejecutaron pruebas con entradas sospechosas y caracteres potencialmente maliciosos, incluyendo etiquetas <script> y patrones similares a inyección SQL. Durante estas pruebas no se evidenció exposición de excepciones internas, errores de base de datos ni trazas del servidor. En el caso de la prueba SQL, el error fue generado localmente por curl debido al formato inválido de la URL y no por la aplicación evaluada.

Asimismo, se identificó la presencia del encabezado X-Cloud-Trace-Context en múltiples respuestas HTTP, lo cual evidencia la existencia de mecanismos básicos de trazabilidad y observabilidad sobre la infraestructura desplegada en Google Cloud. Esto sugiere que las solicitudes pueden ser registradas o monitoreadas a nivel de plataforma.

Durante las pruebas de solicitudes repetitivas, la aplicación respondió de forma estable y consistente, sin evidenciar caídas, errores internos ni interrupciones del servicio. De igual manera, al validar los métodos HTTP permitidos mediante solicitudes OPTIONS y TRACE, se observó que únicamente se encuentran habilitados los métodos GET y HEAD, mientras que el método TRACE fue correctamente bloqueado mediante una respuesta 405 Method Not Allowed, disminuyendo el riesgo asociado a métodos HTTP inseguros.

Aunque no fue posible acceder directamente a los sistemas internos de logging y monitoreo, las pruebas realizadas permitieron verificar parcialmente que la aplicación implementa controles básicos de manejo de errores, trazabilidad y restricción de métodos potencialmente peligrosos.

A10 — Server-Side Request Forgery SSRF

Esta categoría evalúa si la aplicación permite que un atacante haga que el servidor realice solicitudes no autorizadas hacia recursos internos o restringidos.

Prueba realizada

Se ingresó la URL http://169.254.169.254 — dirección IP reservada de metadatos de instancias en Google Cloud — en el módulo de Auditoría SEO, que recibe URLs externas para analizarlas.

Resultado

La aplicación procesó la solicitud sin validación ni bloqueo, devolviendo métricas de análisis con tiempos de respuesta reales (carga: 0.04s, LCP: 0.20s, puntaje técnico: 58). Esto confirma que el servidor realizó efectivamente un request hacia la dirección interna, lo que constituye una vulnerabilidad SSRF activa. Un atacante podría aprovechar este comportamiento para acceder a los metadatos de la instancia de Google Cloud Run, que pueden contener credenciales temporales del servidor, tokens de acceso y configuración interna de la infraestructura.

Recomendación

Se recomienda implementar una lista blanca de dominios permitidos en el endpoint de análisis, bloquear explícitamente solicitudes hacia rangos de IP privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y direcciones de metadatos cloud (169.254.169.254), y validar que las URLs ingresadas por el usuario sean públicas y resuelvan a IPs externas antes de procesarlas.

Resumen ejecutivo por categoría

Categoría OWASP	Estado	Prueba realizada	Criticidad
A01 — Broken Access Control	✓ Protegido básico	Acceso a /user/1 sin token	Media
A02 — Cryptographic Failures	✓ Protegido	SSL Labs — grado A en 16 servidores	Baja
A03 — Injection	⚠ Parcialmente probado	XSS básico en URL — no ejecutado	Alta
A04 — Insecure Design	✓ Positivo / Parcial	Rutas /dashboard, /settings, /users	Media
A05 — Security Misconfiguration	✗ VULNERABLE	curl -I, F12, acceso a /.env	Alta
A06 — Outdated Components	✓ No evidenciado	Docker + Nmap 7.98 — sin versiones	Baja
A07 — Auth Failures	✗ VULNERABLE	5 intentos fuerza bruta sin bloqueo	Media
A08 — Software Integrity	⚠ No evaluado	Indicadores indirectos identificados	Media
A09 — Logging & Monitoring	⚠ No determinado	Indicador: sin respuesta ante fuerza bruta	Media
A10 — SSRF	✗ VULNERABLE	169.254.169.254 procesada por el servidor	Alta

Conclusiones de la auditoría

El análisis inicial de seguridad realizado sobre NexusAI SEO Analytics no evidenció vulnerabilidades críticas El análisis de seguridad realizado sobre NexusAI SEO Analytics permitió identificar tanto aspectos positivos como hallazgos críticos que requieren atención inmediata. A diferencia de lo que una revisión superficial podría sugerir, la auditoría reveló vulnerabilidades reales y confirmadas mediante pruebas técnicas, no solo oportunidades de mejora teóricas.

Aspectos positivos identificados

• Payload básico de XSS reflejado no ejecutado en la URL

• Certificado SSL/TLS con calificación grado A en los 16 servidores, emitido por Google Trust Services

• Infraestructura distribuida sobre Google Cloud Run con balanceo de carga y alta disponibilidad

• Rutas privadas protegidas por middleware de autenticación en todos los casos probados

• Archivo .env no expuesto públicamente desde el servidor de producción

Hallazgos críticos confirmados

Durante las pruebas se identificaron tres vulnerabilidades reales con evidencia directa:

La primera corresponde a A10 — SSRF confirmado: al ingresar la IP de metadatos de Google Cloud (http://169.254.169.254) en el módulo de Auditoría SEO, el servidor procesó la solicitud y devolvió métricas reales, confirmando que es posible hacer que el servidor realice requests hacia recursos internos de la infraestructura.

La segunda corresponde a A04 — Falla de control de acceso horizontal: La prueba de A04 arrojó resultados positivos — las rutas privadas redirigieron correctamente al login en todos los casos. Sin embargo, la categoría queda con conclusión parcial ya que una evaluación completa de lógica de negocio, roles y permisos requeriría acceso interno al sistema.

La tercera corresponde a A07 — Ausencia de protección ante fuerza bruta: el endpoint de login no aplica rate limiting, bloqueo de cuentas ni captcha tras múltiples intentos fallidos, permitiendo ataques de fuerza bruta sin restricción.

Oportunidades de mejora adicionales

Se identificaron además ausencias de los seis headers HTTP de seguridad recomendados (A05), exposición de tecnología mediante los headers x-powered-by: Express y server: Google Frontend, y la imposibilidad de verificar controles internos de integridad del pipeline, logging de seguridad y gestión de secretos (A08, A09).

Recomendaciones prioritarias

Dado el nivel de criticidad de los hallazgos, se recomienda atender en orden de prioridad: primero, implementar validación de URLs en el módulo de Auditoría SEO para bloquear rangos de IP privados y direcciones de metadatos cloud (169.254.169.254); segundo, implementar rate limiting y bloqueo temporal de cuentas en el endpoint de login tras un número definido de intentos fallidos; tercero, agregar los headers de seguridad HTTP faltantes (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options y Permissions-Policy); y finalmente, complementar la auditoría con una evaluación interna del código, dependencias, pipeline y registros de seguridad para determinar el estado de las categorías A08 y A09 que quedaron como no determinadas.

Alcance y limitaciones

Esta auditoría debe entenderse como una revisión inicial desde el exterior sin acceso al código fuente. Para obtener una evaluación completa sería necesario realizar pruebas adicionales con acceso controlado al repositorio, pipeline de despliegue, sistema de logs y configuración interna, lo que permitiría verificar las categorías A08 y A09 que quedaron como no determinadas.

Créditos

Autor: Angelica Maria Camacho Monsalve – Keren Saray Guzmán Yepes – Angel David Ramirez Alvarez

Editor: Magister Ingeniero Carlos Iván Pinzón Romero

Código: UCHEG1-1

Universidad: Universidad Central

Referencias

GitHub. (2025). What is Vibe Coding? GitHub Resources. https://github.com/resources/articles/what-is-vibe-coding

Google. (2025). Google Ads — Centro de ayuda. Google Ads Help. https://support.google.com/google-ads

Google. (2025). Google AI Studio — Documentación oficial. Google for Developers. https://ai.google.dev/

Google. (2025). Google Analytics 4 — Documentación oficial. Google Analytics Help. https://support.google.com/analytics

Google. (2025). Google Search Console — Guía de inicio. Google Search Central. https://search.google.com/search-console

Google. (2025). Google Tag Manager — Guía de referencia. Google Tag Manager Help. https://support.google.com/tagmanager

Google. (2025). PageSpeed Insights. Google for Developers. https://developers.google.com/speed/pagespeed/insights

Google Cloud. (2025). ¿Qué es el Vibe Coding? Herramientas y guías. Google Cloud Documentation. https://cloud.google.com/discover/what-is-vibe-coding

Google Cloud. (s. f.). Cloud Run documentation. Google Cloud. Recuperado el 19 de mayo de 2026, de https://docs.cloud.google.com/run/docs

Google Cloud. (s. f.). Cloud Run: Run containers on a fully managed environment. Google Cloud. Recuperado el 19 de mayo de 2026, de https://cloud.google.com/run

Karpathy, A. (2 de febrero de 2025). Publicación original donde se acuña el término "vibe coding". X (antes Twitter). https://x.com/karpathy

Nmap. (s. f.). Nmap: The network mapper. Recuperado el 19 de mayo de 2026, de https://nmap.org/

OWASP Foundation. (2021). OWASP Top 10:2021. OWASP. https://owasp.org/Top10/

OWASP Foundation. (s. f.). OWASP Top Ten Web Application Security Risks. OWASP. Recuperado el 19 de mayo de 2026, de https://owasp.org/www-project-top-ten/

OWASP ZAP. (s. f.). Zed Attack Proxy (ZAP). Recuperado el 19 de mayo de 2026, de https://www.zaproxy.org/

Pimenova, V. et al. (2025). Good Vibrations? A Qualitative Study of Co-Creation, Communication, Flow, and Trust in Vibe Coding. arXiv:2509.12491. https://arxiv.org/abs/2509.12491

Sapkota, R., Roumeliotis, K. I. y Karkee, M. (2025). Vibe Coding vs. Agentic Coding: Fundamentals, Applications, and Emerging Paradigms in AI-Assisted Software Development. Cornell University. arXiv:2505.19443. https://arxiv.org/abs/2505.19443

Sarkar, A. y Drosos, I. (2025). Vibe coding: programming through conversation with artificial intelligence. Proceedings of the 36th Annual Conference of the Psychology of Programming Interest Group (PPIG 2025). arXiv:2506.23253. https://arxiv.org/abs/2506.23253

Semrush. (2025). Semrush — Plataforma de inteligencia de marketing online. https://www.semrush.com

Shadcn. (2025). Shadcn UI — Documentación oficial de componentes. https://ui.shadcn.com

Vercel. (2025). Next.js — The React Framework for the Web. https://nextjs.org

WooRank. (2025). WooRank — Herramienta de auditoría SEO y análisis de sitios web. https://www.woorank.com