Volver al blog
29 de mayo de 20269 min de lectura

Auditoría Web Sin Acceso al Servidor: Procedimiento Generalizable

Cómo auditar una web en caja negra usando sólo herramientas públicas, documentar hallazgos reproducibles y proponer una migración — sin tocar el servidor ni el código fuente.

#Auditoría#Seguridad#Rendimiento#Astro#curl#Lighthouse

Auditoría Web Sin Acceso al Servidor: Procedimiento Generalizable

Este post documenta un procedimiento de auditoría web aplicable a cualquier sitio en producción cuando no se dispone de acceso al servidor, al repositorio ni a credenciales internas. Todo el análisis se realiza desde fuera, en caja negra, usando herramientas públicas. El objetivo es entregar al cliente un informe técnico reproducible con hallazgos, severidades y una propuesta de migración accionable.

Nota: este artículo describe el método. No se identifica al cliente ni al sitio analizado.

1. Premisa: trabajar sólo con lo observable

Sin acceso al servidor, lo único que se puede medir es lo que el sitio expone públicamente:

  • Respuestas HTTP (status, cabeceras, redirecciones).
  • HTML inicial servido y recursos cargados (JS/CSS/imágenes/fuentes).
  • Comportamiento del navegador en condiciones controladas (Lighthouse, WebPageTest).
  • Políticas de seguridad declaradas (CSP, HSTS, cookies, CORS).
  • Señales de SEO (meta tags, structured data, sitemap, robots).
  • Capas de accesibilidad expuestas en el DOM.
  • Fingerprinting de stack (Wappalyzer, BuiltWith, cabeceras de servidor).
  • DNS y registro de dominio (dig, whois).

Esta restricción obliga a un enfoque disciplinado: cada hallazgo se acompaña del comando exacto que lo reproduce, para que el cliente pueda verificarlo en su entorno.

2. Caja de herramientas

Sólo herramientas públicas, gratuitas y reproducibles:

CategoríaHerramientaPara qué
HTTPcurl -I -L, curl -svCabeceras, redirecciones, TLS handshake
RendimientoLighthouse (CLI/Chrome), PageSpeed Insights, WebPageTestLCP, CLS, TBT, waterfall
SeguridadMozilla Observatory, securityheaders.comCSP, HSTS, X-Frame-Options, cookies
AccesibilidadWAVE, axe DevToolsContraste, ARIA, foco, landmarks
SEOLighthouse SEO, Rich Results Test, sitemap fetchMeta tags, structured data, indexación
StackWappalyzer, BuiltWithCMS, librerías, hosting
Reddig, whois, nslookupDNS, TTLs, registrador

Para CMS conocidos (WordPress, Joomla, Drupal) se documenta también la versión visible — sin tocar endpoints administrativos.

3. Flujo de análisis

3.1 Reconocimiento inicial

# Cabeceras de respuesta + cadena de redirecciones
curl -I -L https://ejemplo.com/
 
# Detalle del handshake TLS y certificado
curl -sv https://ejemplo.com/ 2>&1 | head -n 40
 
# DNS y TTLs
dig +short ejemplo.com A AAAA CNAME NS

Salida típica útil: server: ..., x-powered-by: ..., ausencia de strict-transport-security, cookies sin flags Secure / HttpOnly / SameSite, falta de content-security-policy.

3.2 Rendimiento

  • Lighthouse en modo mobile + desktop, 3 ejecuciones, mediana.
  • WebPageTest con perfil "Cable" y "4G".
  • Cuantificar: LCP, CLS, TBT, transferencia total, número de requests, peso del JS de terceros.

Los hallazgos típicos son: imágenes no optimizadas (JPEG/PNG en lugar de WebP/AVIF), bloqueo de render por scripts síncronos, fuentes sin font-display: swap, ausencia de cache HTTP, y JavaScript de terceros sin diferir.

3.3 Seguridad

Mozilla Observatory y securityheaders.com puntúan en segundos, pero el detalle se construye a mano sobre las cabeceras:

  • Strict-Transport-Security — ¿existe? ¿includeSubDomains? ¿preload?
  • Content-Security-Policy — ¿definida? ¿unsafe-inline? ¿unsafe-eval?
  • X-Frame-Options o frame-ancestors.
  • Referrer-Policy, Permissions-Policy.
  • Cookies: flags Secure, HttpOnly, SameSite.
  • Mixed content y redirecciones HTTP → HTTPS.

3.4 Accesibilidad

WAVE + axe sobre las páginas más relevantes (home, listados, detalle, formularios). Se reportan: contraste insuficiente, imágenes sin alt, ausencia de landmarks, foco no visible, formularios sin labels asociados, jerarquía de encabezados rota.

3.5 SEO

  • Meta title y description por plantilla.
  • Open Graph y Twitter Cards.
  • sitemap.xml y robots.txt.
  • Structured data (JSON-LD) — validación con Rich Results.
  • Canonicals y hreflang en sitios multiidioma.

4. Documentar hallazgos con rigor

Cada hallazgo del informe sigue la misma plantilla:

  1. Título corto y descriptivo.
  2. Severidad estandarizada: Crítico / Alto / Medio / Bajo.
  3. Evidencia — captura o salida de comando.
  4. Comando reproducible — el cliente debe poder repetirlo.
  5. Impacto — qué se rompe o qué riesgo introduce.
  6. Recomendación — acción concreta, no genérica.

Este formato convierte el informe en algo auditable: cualquier técnico del cliente puede verificar los hallazgos sin confiar en la palabra del consultor.

5. Aceleración con agentes de IA

El análisis manual lleva tiempo. Para acelerar la verificación cruzada se configuran agentes y skills específicos:

  • Un agente que parsea salidas de curl y resume desviaciones respecto a un baseline de cabeceras seguras.
  • Un skill que compara puntuaciones de Lighthouse entre ejecuciones para detectar regresiones por variabilidad de red.
  • Plantillas de prompt para clasificar hallazgos por severidad con criterios fijos.

La IA no sustituye la verificación humana — cada hallazgo crítico se valida a mano antes de entrar al informe.

6. Propuesta de migración

Cuando la auditoría revela problemas estructurales (stack obsoleto, ausencia total de cabeceras de seguridad, dependencia de un CMS sin mantenimiento), la propuesta acompaña al informe.

Stack recomendado por defecto, ajustable al caso:

  • Framework: Next.js o Astro según la naturaleza del sitio (app vs. contenido estático).
  • Lenguaje: TypeScript estricto.
  • Estilos: Tailwind CSS + design tokens en CSS variables.
  • Despliegue: Vercel (Edge functions, CDN, certificados automáticos).
  • Imágenes: optimización en build (Sharp → WebP/AVIF).
  • Seguridad: CSP estricta, HSTS con preload, cookies hardened, headers vía middleware Edge.
  • A11y: componentes accesibles desde el diseño.
  • Observabilidad: Vercel Analytics + Speed Insights.

La propuesta incluye estimación de esfuerzo, ruta de migración por fases y métricas objetivo (LCP < 2.5s, score Observatory A+).

7. Entrega: informe técnico privado

El informe se publica como un sitio Astro 6 SSG (TypeScript estricto, Tailwind 4, Content Collections) desplegado en Vercel. Estructura:

  • 8 secciones (metodología, stack, rendimiento, seguridad, accesibilidad, SEO, propuesta, informe final).
  • Tabla de hallazgos con severidades y enlaces internos.
  • Capturas integradas como evidencias.

Acceso restringido

El informe contiene análisis crítico sobre infraestructura del cliente. Sólo el destinatario debe poder verlo. El acceso se restringe mediante:

  • Middleware Edge fail-closed: si la variable ACCESS_TOKEN no está definida, el sitio responde 503. Mejor caerse que servir contenido sin protección.
  • Token HMAC en la URL inicial.
  • Cookie httpOnly de 2 horas tras validación (no 90 días — la sesión debe expirar pronto).
  • Headers no-store en la respuesta autenticada para evitar caché intermedia.
  • robots.txt con Disallow: / y meta noindex, nofollow.
  • Repositorio privado.

La cookie corta no es paranoia: un informe técnico no necesita persistir 90 días en el navegador del receptor.

8. Por qué este proceso funciona

  • Reproducibilidad: cada hallazgo se puede repetir. Cero magia.
  • Trazabilidad: severidades estandarizadas, no opinión.
  • Privacidad por defecto: el informe nace cerrado, no se "asegura después".
  • Caja negra como ventaja: si lo veo desde fuera, el atacante también.
  • IA como acelerador, no como oráculo: la verificación final es humana.

El resultado es un artefacto que un equipo técnico puede usar para priorizar trabajo real, no un PDF genérico de checklist.

Si necesitas una auditoría con este enfoque, escríbeme desde el footer.

Si te ha sido útil, puedes apoyarlo aquí→
Volver al blog