Cómo Asegurar tu App en 5 Minutos con Data Hogo — Caso de Estudio

El escaneo de seguridad que "voy a hacer después" es el que nunca ocurre. Este post es un walkthrough real de lo que pasa cuando conectas un repo típico de Next.js + Supabase a Data Hogo — con los hallazgos reales, los tiempos reales, y los fixes concretos. Asegurar tu app en 5 minutos no es marketing: es literalmente lo que tarda el scan.

El repo de este caso de estudio es una app SaaS pequeña: dashboard de analytics para creadores de contenido, stack Next.js 14 con App Router, Supabase como base de datos y auth, deploy en Vercel. El desarrollador tenía 3 meses shippeando features sin un escaneo de seguridad formal. Exactamente el escenario más común.

Minuto 0-1: Conectar el repo

El proceso de conexión es OAuth con GitHub. Autorizas la GitHub App de Data Hogo, seleccionas el repo, y presionas "Escanear". No hay YAML que configurar, no hay token que copiar, no hay CI/CD que tocar.

El scanner puede acceder al repo privado a través de la GitHub App. El código se clona temporalmente para el análisis — no se almacena.

Minuto 1-4: El escaneo corre

Data Hogo corre seis engines en paralelo:

• Gitleaks + patrones regex contra el historial completo de commits (secretos)
• npm audit + base de datos OSV contra el package.json (dependencias)
• Más de 250 reglas Semgrep contra el código fuente (patrones inseguros)
• Análisis de archivos de configuración (.env.example, next.config.js, etc.)
• Request HTTP a la URL de producción analizando security headers
• Parser de las políticas RLS de Supabase

Todo en paralelo. El repo de este caso de estudio tiene ~12,000 líneas de código y 87 dependencias. El análisis completo tomó 4 minutos y 12 segundos.

Los resultados: 18 hallazgos

El security score llegó en 47/100. No es un desastre, pero tampoco es bueno para una app con usuarios reales.

El desglose:

Los hallazgos críticos son los que importan hoy. Los demás son reales pero no urgentes.

Hallazgo crítico #1: API key de OpenAI en el historial de Git

Este es el hallazgo que más duele encontrar y el más importante arreglar.

Data Hogo encontró una API key de OpenAI commiteada hace 6 semanas en un commit con mensaje "wip: testing". La key fue borrada en el siguiente commit, pero el historial de Git es permanente.

# MAL: el commit de hace 6 semanas incluía esto
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
# Aunque el archivo ya no tenga la key, el historial la conserva
git log --all -p | grep "sk-proj"
# Output: aparece en el commit abc123f

La solución inmediata es rotar la key. No importa que ya no esté en el código activo — si alguien hizo scraping del repo antes de que la borraran, ya la tienen. Los bots que escanean GitHub activamente son rápidos.

1. Ve a la consola de OpenAI
2. Genera una key nueva
3. Actualiza las variables de entorno en Vercel
4. Revoca la key anterior

El historial de Git se puede limpiar con git filter-branch o BFG Repo-Cleaner, pero rotar la key es lo urgente — la limpieza del historial puede hacerse después sin riesgo adicional.

Hallazgo crítico #2: Política RLS ausente en tabla de analytics

El segundo hallazgo crítico es más sutil pero igual de serio. La tabla analytics_events en Supabase no tiene ninguna política RLS definida.

En Supabase, cuando habilitas RLS en una tabla pero no defines ninguna política, el comportamiento por defecto es denegar todo acceso. Eso suena seguro. El problema está en el código:

// MAL: usando el cliente con service role key desde el frontend
// Este patrón bypassea RLS completamente
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // nunca en el cliente
);

El developer usó el service role key para esquivar el problema de RLS y no lo resolvió correctamente. Ahora la service role key está expuesta en el bundle del cliente — lo que significa que cualquier usuario puede hacer queries directas a Supabase con permisos de admin.

La solución correcta tiene dos partes:

-- BIEN: definir la política RLS apropiada
-- Los usuarios solo pueden ver sus propios eventos
create policy "users_own_analytics"
  on analytics_events
  for select
  using (auth.uid() = user_id);

// BIEN: usar el cliente anon desde el frontend
// RLS se aplica automáticamente con auth.uid()
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // key pública, RLS protege los datos
);

Para profundizar en cómo funciona RLS y los errores más comunes, revisa la guía completa de seguridad en Supabase RLS.

Hallazgos altos: security headers faltantes

Los tres security headers de mayor impacto que faltaban:

Strict-Transport-Security (HSTS) — Le dice al navegador que solo se conecte a tu app por HTTPS. Sin este header, un atacante en la misma red puede hacer downgrade a HTTP.

Content-Security-Policy (CSP) — Define qué scripts, estilos e iframes son válidos. Previene ataques de XSS donde el atacante inyecta código malicioso.

X-Frame-Options — Previene que tu app sea embebida en un iframe de otro dominio. Sin esto, un ataque de clickjacking puede engañar a tus usuarios.

En Next.js, se agregan en next.config.js:

// next.config.js
const nextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          {
            key: "Strict-Transport-Security",
            // BIEN: HSTS con 1 año y preload
            value: "max-age=31536000; includeSubDomains; preload",
          },
          {
            key: "X-Frame-Options",
            value: "SAMEORIGIN",
          },
          {
            key: "X-Content-Type-Options",
            value: "nosniff",
          },
        ],
      },
    ];
  },
};

El resultado: de 47 a 81 en el re-escaneo

Después de rotar la API key de OpenAI, arreglar el problema de RLS + service role key, y agregar los security headers, corrimos un segundo escaneo.

Security score: 81/100.

Los 5 hallazgos restantes son medios y bajos — cosas como un header adicional de Permissions-Policy faltante y una dependencia en versión minor sin CVE activo pero con actualizaciones disponibles. No son urgentes para una app en producción.

El tiempo total del proceso: el primer scan tomó ~4 minutos, los fixes tomaron ~45 minutos (la mayoría en entender el problema del service role key y testearlo correctamente), y el segundo scan tomó otros ~4 minutos.

Lo que este caso de estudio muestra

Tres patterns que vemos en casi todos los repos de apps jóvenes:

1. Un secreto en el historial — Casi siempre es una key que alguien puso "temporalmente" para testear y nunca limpió
2. RLS parcialmente configurado — Tablas con RLS habilitado pero sin políticas, o políticas que se skippean con el service role key
3. Security headers ausentes — No es falta de conocimiento sino que nadie los configuró porque la app "funciona" sin ellos

Los tres son fáciles de arreglar cuando sabes dónde están. El problema es encontrarlos antes de que los encuentre alguien más.

Escanea tu repo gratis — ve qué encuentra →

Preguntas frecuentes

¿Cuánto tiempo tarda un escaneo de seguridad con Data Hogo?

El escaneo completo tarda entre 3 y 6 minutos dependiendo del tamaño del repo. Corre seis análisis en paralelo: detección de secrets, escaneo de dependencias, análisis estático de código, revisión de configuración, security headers y análisis de reglas de base de datos.

¿Qué hace Data Hogo con mi código después del escaneo?

Data Hogo clona tu repo temporalmente para correr el análisis y no almacena tu código fuente. Solo se guardan los resultados del escaneo — los hallazgos, el security score y los metadatos del scan.

¿Puedo arreglar las vulnerabilidades directamente desde Data Hogo?

En el plan Pro ($39/mes), Data Hogo genera el código de fix con IA y abre el pull request en tu repo de GitHub automáticamente. En el plan Free y Basic, recibes la descripción del hallazgo, el archivo y la línea afectada, y las instrucciones de cómo arreglarlo.

¿Qué pasa si el security score de mi app es bajo?

Un score bajo no significa que tu app sea inoperable — significa que tienes hallazgos pendientes de resolver. El reporte prioriza por severidad: empieza por los críticos antes de los medios. Con los hallazgos críticos resueltos, el score sube significativamente.

¿Data Hogo detecta vulnerabilidades en el historial de Git?

Sí. La detección de secrets busca en el historial completo de commits, no solo en el código actual. Si alguien hizo commit de una API key hace 6 meses y la borró en el siguiente commit, Data Hogo lo detecta y te avisa que esa credencial necesita ser rotada aunque ya no esté en el código activo.