Identificar tecnología web sin JavaScript
En pocas palabras: El desarrollador Tim Kal creó una herramienta open source que identifica CMS, frameworks y CDNs analizando cabeceras HTTP y meta tags de un único request. Detecta 30 tecnologías en segundos sin usar navegadores headless, ofreciendo precisión al evitar falsos positivos.
Identificar tecnología web sin ejecutar JavaScript es posible gracias a una técnica de fingerprinting que analiza un único request HTTP. Esta solución, creada por el desarrollador Tim Kal, permite detectar CMS, frameworks y CDNs comparando metadatos contra firmas estáticas, evitando la sobrecarga de los navegadores headless.
En este artículo:
- En 30 segundos
- ¿Qué información revela un único request HTTP sobre el stack de una web?
- ¿Cómo funciona la técnica de signature matching sin headless browser?
- ¿Cuáles son las limitaciones reales de esta aproximación ligera?
- ¿Qué categorías de tecnología se pueden detectar fácilmente?
- ¿Cuándo conviene usar este método vs. un escaneo completo?
- Errores comunes al implementar fingerprinting HTTP
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- Detección pasiva: El sistema lee cabeceras HTTP y meta tags como
<meta name="generator">, sin renderizar la página ni ejecutar código del cliente. - Alcance limitado pero honesto: Cubre aproximadamente 30 tecnologías en 7 categorías (CMS, e-commerce, JS, etc.), devolviendo vacío si no hay coincidencia exacta para evitar falsos positivos.
- Rendimiento superior: Al ser una simple comparación de strings y regex sobre el HTML crudo, es órdenes de magnitud más rápido y ligero que herramientas basadas en Puppeteer o Playwright.
- Código abierto: La lógica se basa en una tabla de firmas escrita a mano, disponible en GitHub, lo que facilita su integración en pipelines de CI/CD o scripts de monitoreo.
El fingerprinting de la pila tecnológica de un sitio web desde una sola petición HTTP es una técnica de análisis pasivo que examina las cabeceras de respuesta y el contenido HTML inicial para identificar plataformas, librerías y servicios de infraestructura. A diferencia de los escaneos activos que requieren un navegador completo, este método depende exclusivamente de metadatos expuestos por el servidor, permitiendo una identificación rápida y escalable de tecnologías comunes como WordPress, Shopify o React mediante patrones predefinidos.
¿Qué información revela un único request HTTP sobre el stack de una web?
Ponele que le pedís a tu script que te diga qué usa un dominio y esperás magia. Lo que pasa es que el servidor web, al responder, deja migajas por todos lados. No hace falta correr JavaScript para ver que alguien usó un tema específico de WordPress o que el CDN tiene un header muy particular. El artículo detalla cómo extraer estas pistas sin levantar un navegador.
Las tres fuentes principales de datos son los headers HTTP, los meta tags y ciertos archivos estáticos accesibles públicamente. Por ejemplo, muchos CMS insertan automáticamente una etiqueta <meta name="generator" content="WordPress 6.x">. Si bien algunos administradores borran esto por seguridad, la mayoría lo deja ahí, facilitando la tarea. Además, los servidores como Nginx o Apache suelen incluir su versión en el header Server, aunque es común verlos oscurecidos en configuraciones modernas. Relacionado: configuración de DNS autoritativos.
La clave está en que todo esto llega en el primer byte de la respuesta. No tenés que esperar a que carguen los assets, ni interpretar el DOM dinámico. Es información cruda, servida tal cual al visitante. Esto reduce drásticamente el tiempo de ejecución porque eliminás la fase de renderizado, que suele ser el cuello de botella en herramientas tradicionales. (Y sí, funciona incluso con sitios que bloquean bots agresivos, siempre que respondan al user-agent estándar).
¿Cómo funciona la técnica de signature matching sin headless browser?
El proceso es casi insultantemente simple, y eso es lo bueno. Primero hacés un fetch HTTP GET a la URL objetivo usando una librería ligera (como requests en Python o axios en Node.js). Segundo, parseás el HTML resultante buscando cadenas específicas definidas en una tabla de firmas. Tercero, ejecutás funciones de validación para confirmar si la coincidencia es válida.
Aquí entra la inteligencia del diseño: cada firma es una función pequeña que verifica condiciones lógicas baratas. No hacen falta traversals complejos del árbol DOM. Se busca por presencia de strings, expresiones regulares simples o combinaciones de headers. Por ejemplo, para detectar Shopify, no necesitás ejecutar el código de checkout; basta con encontrar referencias a cdn.shopify.com en el HTML o headers específicos de su arquitectura edge.
Esta aproximación evita los problemas clásicos de los navegadores headless: consumo de memoria alto, necesidad de gestionar timeouts largos y la fragilidad ante cambios en el layout visual. Al trabajar solo con texto plano, la operación es determinista y rápida. Podés procesar miles de URLs por minuto en una máquina modesta. ¿Y qué pasa cuando el sitio cambia? Exacto, si la firma ya no coincide, el detector devuelve vacío. No intenta adivinar. Esa honestidad es preferible a tener un “85% de confianza” que resulta ser mentira. En integración continua con CI/CD profundizamos sobre esto.
¿Cuáles son las limitaciones reales de esta aproximación ligera?
Hay que decirlo claro: esto no reemplaza a Wappalyzer o BuiltWith para auditorías exhaustivas. La base de firmas mencionada en el repositorio de Tim Kal cubre apenas 30 tecnologías distribuidas en 7 categorías. Si el sitio usa un framework oscuro o una plataforma custom, el resultado será nulo. Y está bien. El autor prioriza la precisión sobre el recall (cobertura).
El compromiso es claro: se sacrifica cobertura a cambio de menor mantenimiento y mayor velocidad. En entornos donde necesitás saber rápidamente si un lote de 10.000 dominios usa WordPress o no, este enfoque gana. Pero si querés identificar cada plugin de SEO o analítica minoritaria, vas a necesitar un motor más pesado que ejecute JavaScript.
Otra limitación es la dependencia de la configuración del servidor. Muchos administradores avanzados eliminan los headers de versión o limpian los meta tags de generator. En esos casos, el fingerprinting pasivo falla silenciosamente. No es un bug, es una realidad de la seguridad web actual. Los sitios hardenados simplemente no dejan rastro fácil. Por eso, esta herramienta sirve mejor para el promedio de la web, no para los fortines corporativos con WAFs agresivos.
¿Qué categorías de tecnología se pueden detectar fácilmente?
La estructura de la solución divide el mundo en siete compartimentos estancos. Cada uno tiene sus propias reglas de detección basadas en artefactos conocidos. Esto se conecta con lo que analizamos en elección entre Jenkins y Actions.
| Categoría | Ejemplos detectables | Método principal |
|---|---|---|
| CMS | WordPress, Drupal, Joomla | Meta tags generator, rutas de admin (/wp-admin) |
| E-commerce | Shopify, WooCommerce, Magento | Referencias a CDN propios, estructuras de JSON-LD |
| Frameworks JS | React, Vue, Angular | Patrones de nombres de variables, divs root específicos |
| Analytics | Google Analytics, Matomo | IDs de tracking en scripts inline o src externos |
| CDN/Hosting | Cloudflare, AWS CloudFront | Headers HTTP (CF-RAY, x-amz-cf-id) |
| Pago | Stripe, PayPal | Scripts de checkout, data-attributes específicos |
| Live Chat | Intercom, Drift | Widgets flotantes, scripts de carga diferida |
Nota que muchas de estas detecciones cruzan categorías. Un sitio puede usar WordPress (CMS) con Cloudflare (CDN) y Stripe (Pago). La ventaja de tener firmas separadas es que podés combinarlas para crear perfiles de stack completos. Sin embargo, recordá que si una categoría no tiene coincidencia, queda vacía. No se infiere nada por proximidad.
¿Cuándo conviene usar este método vs. un escaneo completo?
La decisión depende puramente de tus objetivos y recursos. Si estás construyendo un dashboard de competencia que necesita refrescar datos cada hora para 50.000 URLs, usar un navegador headless te va a costar una fortuna en infraestructura y tiempo. Ahí, el fingerprinting HTTP es la única opción viable.
Por otro lado, si necesitás hacer una auditoría de seguridad técnica o analizar SEO on-page profundo, vas a necesitar ver cómo se comporta la página en tiempo real. Los errores de JavaScript, las redirecciones client-side y el contenido cargado dinámicamente son invisibles para un simple fetch. En esos casos, la lentitud es el precio de la profundidad.
Un escenario híbrido inteligente sería usar este método como filtro primario. Identificás primero los sitios que usan tecnologías conocidas y luego lanzás escaneos completos solo sobre ese subconjunto relevante. Así optimizás costos sin perder detalle crítico. Para hosting y despliegue de estas herramientas de monitoreo, servicios como donweb.com ofrecen la estabilidad necesaria para mantener scripts corriendo 24/7 sin dolores de cabeza.
Errores comunes al implementar fingerprinting HTTP
- Ignorar los User-Agent: Muchos servidores bloquean requests que parecen bots. Si tu script usa un UA genérico o vacío, recibirás códigos 403 o páginas de captcha, no el HTML real. Configura siempre un UA de navegador moderno.
- Confiar ciegamente en el header Server: Este dato es fácil de falsificar o eliminar. Úsalo como pista secundaria, nunca como prueba concluyente. Un sitio puede decir que usa Nginx mientras corre Apache detrás de un proxy inverso.
- No manejar timeouts: Un request HTTP puede colgarse si el servidor no responde. Sin un timeout explícito (ej. 5-10 segundos), tu script se congelará esperando una respuesta que nunca llega, matando el throughput del batch processing.
Preguntas Frecuentes
¿Se puede identificar la tecnología de un sitio web sin ejecutar JavaScript?
Sí, mediante el análisis de cabeceras HTTP y metadatos HTML estáticos como los tags de generator. Esta técnica permite detectar CMS populares, CDNs y frameworks básicos sin necesidad de renderizar la página, reduciendo significativamente el uso de recursos computacionales. Cubrimos ese tema en detalle en optimización SEO internacional.
¿Qué es el fingerprinting del tech stack mediante HTTP requests?
Es una metodología de reconocimiento pasivo que compara las respuestas de un servidor web contra una base de datos de firmas conocidas. Permite inferir qué software utiliza un sitio analizando artefactos visibles en el tráfico de red normal, sin interactuar activamente con la aplicación.
¿Cómo detectar si un sitio usa WordPress o Shopify desde los headers?
Busca referencias específicas en el cuerpo de la respuesta o en los headers personalizados. WordPress suele dejar rastros en rutas como /wp-content o meta tags, mientras que Shopify incluye headers de identidad como x-shopify-y o referencias a su CDN en el HTML inicial.
¿Por qué mi detector de tecnologías no encuentra nada?
Probablemente el sitio haya sido endurecido para ocultar sus metadatos, o utilice una tecnología no incluida en tu base de firmas. También puede deberse a bloqueos por parte de firewalls de aplicaciones web (WAF) que detectan tu patrón de solicitud como sospechoso y devuelven contenido genérico.
Conclusión
El fingerprinting HTTP representa un retorno a lo esencial: mirar los datos que ya están ahí antes de complicarnos con herramientas pesadas. Para equipos de desarrollo y DevOps que necesitan visibilidad rápida sobre stacks tecnológicos a gran escala, esta aproximación ofrece el mejor balance entre costo, velocidad y precisión aceptable. No es la herramienta perfecta para todo, pero para el problema específico de “identificar tecnología web” masivamente, es una solución elegante y pragmática. Si trabajás con APIs de detección, asegurate de mantener tus firmas actualizadas, porque la web cambia rápido y las viejas señales desaparecen.
