En resumen
Qué se comprueba
si se exponen el servidor y su versión, el gestor de contenidos y su versión, y el lenguaje o marco de trabajo que hay detrás.
Cuándo falla
cuando alguno de los tres aparece; el resultado distingue si se ve solo la tecnología o también la versión concreta.
Por qué importa
MDN advierte de que ese detalle puede facilitar la detección de vulnerabilidades conocidas.
Severidad en Wakaris
Importante. Falla en el 95 % de las páginas analizadas.
Qué es y qué comprueba este hallazgo
Este hallazgo salta cuando tu web publica detalles sobre su propia tecnología sin necesidad. No es un fallo de configuración que rompa nada: es información de más.
Wakaris mira tres cosas. La primera es el servidor y su versión, que viaja en la cabecera Server de la respuesta. MDN la define como la que describe el software del servidor de origen que atendió la petición, y su ejemplo es tan explícito como Apache/2.4.1 (Unix). La segunda es el gestor de contenidos y su versión, que suele delatarse dentro del HTML, en la etiqueta meta con nombre generator: MDN la define como el identificador del software que generó la página. La tercera es el marco de trabajo o lenguaje, que aparece en cabeceras no estándar como X-Powered-By, cuyo contenido MDN describe como una cadena con la aplicación o el marco del servidor.
Cómo se detecta
Wakaris pide tu URL, lee las cabeceras de la respuesta y el HTML de la página, y te dice cuál de los tres puntos está revelando algo y qué revela exactamente, con el fragmento que lo respalda. Todo lo que comprueba es público: cualquiera que abra tu web recibe lo mismo.
El resultado no es un sí o un no. Distingue el grado: una cosa es que se sepa que usas un servidor determinado y otra que se lea la versión exacta. Esa diferencia es la que importa, y es la que separa un dato de contexto de un dato accionable para quien busca objetivos vulnerables.
Conviene entender el límite de la comprobación. Wakaris mira dónde la información aparece escrita de forma explícita. La documentación de MDN reconoce que caracterizar el software de un servidor es posible por otras vías aunque se oculte la cabecera, así que un resultado limpio significa que no lo estás publicando, no que sea imposible averiguarlo.
Por qué importa
Importa por una razón concreta y conviene no exagerarla.
MDN es claro en su aviso: la presencia de esa cabecera, sobre todo cuando lleva detalles finos de la versión, puede hacer que las vulnerabilidades conocidas sean más fáciles de detectar. La guía de pruebas de seguridad de OWASP lo cuenta desde el otro lado: descubrir con precisión el tipo de servidor sobre el que corre una aplicación permite determinar si es vulnerable a un ataque, porque los servidores con versiones antiguas y sin parches recientes son susceptibles a exploits ligados a esa versión.
Ahora la parte honesta. Ocultar el dato no arregla nada por sí solo: la propia MDN dice que es discutible cuánto beneficio aporta, y que el enfoque robusto es mantener el software actualizado y parcheado frente a vulnerabilidades conocidas. Por eso este hallazgo es Importante y no Crítico: quita un atajo al que va buscando objetivos fáciles, pero el trabajo de fondo está en actualizar.
Causas comunes
La causa dominante es que viene así de fábrica. Los servidores anuncian su nombre y su versión en la configuración por defecto, y los marcos de trabajo añaden su propia cabecera al instalarse. Nadie lo eligió: el hallazgo salta en casi todas las páginas analizadas justamente por eso.
La segunda es la etiqueta del gestor de contenidos. Los gestores insertan la etiqueta generator con su nombre y su número de versión al publicar cada página, sin preguntar.
La tercera son las capas intermedias: una red de distribución, un balanceador o un proxy que añaden sus propias cabeceras encima de las del servidor de origen, de modo que la respuesta acaba describiendo toda la pila.
La cuarta es la configuración a medias: alguien quitó la cabecera del servidor hace años y quedaron la del marco de trabajo y la etiqueta del gestor, que viven en sitios distintos y se retiran por separado.
Cómo solucionarlo
Empieza por el informe de Wakaris, que te dice cuál de los tres puntos revela algo y qué revela; el orden sensato es quitar primero la versión y después, si procede, el nombre.
En el servidor, la configuración permite recortar la cabecera Server para que no incluya el número de versión ni los módulos. MDN desaconseja el exceso de detalle también por latencia, no solo por seguridad, así que recortarla no tiene contrapartida.
En el marco de trabajo, las cabeceras del tipo X-Powered-By no son estándar y no aportan nada al navegador: se pueden eliminar sin efecto sobre la página.
En el gestor de contenidos, quita la etiqueta generator desde la configuración o desde la plantilla, y comprueba que no se reponga al actualizar.
Y sobre todo, haz lo que de verdad cierra el riesgo: mantén actualizado ese software. Después vuelve a pasar la página por Wakaris para confirmar que los tres puntos quedan limpios.
Tabla con los tres puntos de exposición, dónde se configura cada uno y el grado de información que revela, desde solo la tecnología hasta la versión concreta
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla con los tres puntos de exposición, dónde se configura cada uno y el grado de información que revela, desde solo la tecnología hasta la versión concreta. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: exposición, información, técnica, tabla, puntos, dónde, configura, grado
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Exposición de información técnica. Mi web publica datos sobre el software que la sirve —el servidor y su versión, el gestor de contenidos y su versión, o el lenguaje o marco de trabajo que hay detrás— en las cabeceras de la respuesta o dentro del HTML. Referencia: lo deseable es que no aparezca la versión concreta de nada, y a poder ser tampoco el nombre del producto. Pega aquí el resultado de Wakaris: qué se está exponiendo (servidor, gestor de contenidos, marco de trabajo), con qué grado de detalle y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya comprobado. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿Qué se está exponiendo según el informe: el servidor, el gestor de contenidos, el marco de trabajo, o varios de ellos? b) ¿Aparece solo el nombre del producto o también un número de versión? c) ¿Qué servidor o servicio sirve tu web? (Apache, Nginx, IIS, alojamiento gestionado, plataforma en la nube; o no lo sé) d) ¿Tienes acceso a la configuración del servidor o solo a un panel de control? e) ¿Hay algo delante de tu servidor: una red de distribución, un proxy, un cortafuegos de aplicación? f) Y la más importante: ¿está ese software actualizado y con los parches al día, o hace tiempo que nadie lo toca? g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes comprobar, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me vendas el ocultamiento como si fuera una solución de seguridad. Déjame claro que quitar estos datos reduce la exposición pero no corrige ninguna vulnerabilidad, y que lo que de verdad protege es tener el software actualizado. 6. No me propongas cambios de configuración de servidor irreversibles o de riesgo sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 7. Si necesitas un dato que solo se obtiene comprobando la web (qué se expone de verdad, con qué detalle, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 8. La decisión final es mía, no tuya. Si el arreglo excede lo que puedo hacer yo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/exposicion-de-informacion-tecnica Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Exposición de información técnica. Consiste en que mi web publica, en las cabeceras de la respuesta o dentro del HTML, qué servidor la sirve y en qué versión, con qué gestor de contenidos está hecha o qué marco de trabajo hay detrás. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se COMPRUEBA leyendo la respuesta real de mi servidor y el HTML de la página, y tú no puedes pedirlos desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Con qué está hecha tu web: un gestor de contenidos conocido, un constructor visual, desarrollo a medida? ¿O no lo sabes? b) ¿Alguien ha tocado alguna vez la configuración del servidor para endurecerla, o la web se publicó tal cual salió de la instalación? c) ¿Quién administra el servidor: tú, una agencia, un alojamiento gestionado? d) ¿Hay una red de distribución o un proxy delante de la web? e) ¿Está el software al día, o hay actualizaciones pendientes desde hace meses? f) ¿Ha pasado la web alguna auditoría de seguridad? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de cuál de los tres puntos sería el sospechoso, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá qué se está exponiendo en cada uno de los tres puntos y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Sé honesto sobre el alcance: dime que ocultar esta información reduce la exposición pero no corrige ninguna vulnerabilidad, y que lo que de verdad protege es tener el software actualizado. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/exposicion-de-informacion-tecnica Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Ocultar la versión del servidor me hace más seguro? +
Reduce la exposición, no la vulnerabilidad. MDN dice que es discutible cuánto beneficio aporta ocultarlo, porque el software del servidor puede caracterizarse por otras vías, y que el enfoque robusto es mantenerlo actualizado y parcheado. Quita un atajo al atacante; no cierra ningún agujero.
¿Por qué es Importante y no Crítico? +
Porque por sí solo no permite entrar en ningún sitio: es información, no un fallo explotable. Se queda en Importante porque facilita el trabajo previo del atacante, que según la guía de pruebas de OWASP consiste en determinar si la aplicación es vulnerable a partir del tipo y la versión del servidor.
¿Qué es la etiqueta generator y por qué la lleva mi web? +
Es una etiqueta meta dentro del HTML que MDN define como el identificador del software que generó la página. La insertan automáticamente los gestores de contenidos y los constructores visuales al publicar, normalmente con su número de versión, sin que nadie lo pida.
Si quito estas cabeceras, ¿se romperá algo? +
No en la página. La cabecera del servidor es informativa y las del tipo X-Powered-By ni siquiera son estándar: el navegador no las necesita para pintar nada. El único efecto lateral posible es sobre herramientas internas que dependan de leer esos valores.
Fuentes citadas
- developer.mozilla.orgServer, MDN Web Docs: qué describe la cabecera, el aviso de que el detalle fino facilita detectar vulnerabilidades conocidas, y por qué actualizar es el enfoque robusto.
- developer.mozilla.orgX-Powered-By, MDN Web Docs: qué contiene la cabecera y su carácter no estándar.
- developer.mozilla.orgStandard metadata names, MDN Web Docs: definición de
generatorcomo identificador del software que generó la página. - owasp.orgFingerprint Web Server, OWASP Web Security Testing Guide: por qué el tipo y la versión del servidor permiten determinar si una aplicación es vulnerable.
Actualizado: 7 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.