La seguridad web no empieza cuando aparece una vulnerabilidad grave. Empieza mucho antes, en detalles aparentemente pequeños: una ruta olvidada, un endpoint legado, una carpeta accesible por error o una respuesta HTTP que confirma demasiado. En ese terreno se mueve la enumeración de directorios y endpoints, una práctica básica en cualquier evaluación de seguridad web autorizada y, al mismo tiempo, una fuente constante de aprendizaje para desarrolladores que quieren reducir superficie de ataque.

Cuando hablamos de enumeración, hablamos de descubrir qué rutas existen realmente en una aplicación. Algunas serán públicas y estarán pensadas para ser visibles. Otras requerirán autenticación. Y otras, aunque no deberían revelar nada, pueden delatar su existencia por cómo responde el servidor. Esa diferencia entre “ser accesible” y “ser descubrible” marca muchas veces el primer paso de una auditoría. El artículo de referencia parte precisamente de ese enfoque: un laboratorio con Express.js, rutas públicas y protegidas, herramientas de descubrimiento y lectura de códigos de estado para interpretar qué está expuesto.

Qué es realmente la enumeración de rutas

La enumeración de directorios y endpoints consiste en probar nombres de rutas posibles para identificar recursos existentes en una aplicación web o API. No siempre busca “entrar” en un sistema; muchas veces basta con confirmar qué existe, qué devuelve contenido, qué redirige y qué responde como acceso denegado para construir un mapa bastante útil de la superficie expuesta.

Desde el punto de vista defensivo, esta práctica es valiosa porque obliga a hacerse preguntas incómodas pero necesarias. ¿Hay rutas administrativas accesibles aunque estén protegidas? ¿Existen endpoints viejos que nadie usa pero siguen respondiendo? ¿Una API devuelve 403 y, sin querer, confirma a cualquiera que el recurso está ahí? ¿Hay archivos estáticos o copias de respaldo que revelan estructura interna?

En aplicaciones pequeñas esto ya importa. En entornos reales, con varias versiones, documentación dispersa, paneles internos, pruebas A/B y microservicios, importa todavía más.

Preparar un laboratorio controlado para entender el problema

La mejor forma de aprender esto no es apuntando herramientas contra sistemas ajenos, sino montando un entorno propio y observando cómo se comporta. Un laboratorio simple con Node.js y Express es más que suficiente.

La idea no es construir una API completa, sino una aplicación mínima con tres tipos de recursos:

Rutas públicas

Son rutas que pueden responder sin autenticación y cuya exposición está prevista. Por ejemplo:

• /
• /about
• /api/public

Rutas protegidas

Existen y cumplen una función legítima, pero sólo deben responder a usuarios autenticados o autorizados:

• /api/profile
• /admin
• /admin/users

Recursos sensibles que no deberían estar visibles en producción

Aquí entran rutas de pruebas, ficheros de configuración expuestos, dumps temporales o endpoints antiguos que nadie ha eliminado:

• /config.json
• /backup.zip
• /old-api

Un ejemplo simple en Express podría ser este:

const express = require('express');const app = express();const PORT = 3000;app.use(express.json());app.get('/', (req, res) => {  res.json({ message: 'API de ejemplo funcionando' });});app.get('/about', (req, res) => {  res.json({ service: 'demo', version: '1.0' });});app.get('/api/public', (req, res) => {  res.json({ message: 'Endpoint público' });});app.get('/api/profile', (req, res) => {  const token = req.headers.authorization;  if (token === 'Bearer demo-token') {    return res.json({ user: 'toni', role: 'user' });  }  return res.status(401).json({ error: 'No autenticado' });});app.get('/admin', (req, res) => {  const token = req.headers.authorization;  if (token === 'Bearer admin-token') {    return res.send('Panel de administración');  }  return res.status(403).json({ error: 'Acceso denegado' });});app.get('*', (req, res) => {  res.status(404).send('Recurso no encontrado');});app.listen(PORT, () => {  console.log(`Laboratorio escuchando en http://localhost:${PORT}`);});

Este tipo de laboratorio permite ver rápidamente cómo una herramienta de descubrimiento interpreta distintos comportamientos del servidor. El enfoque coincide con el artículo base: una API pequeña, pensada para observar qué rutas son detectables y qué información filtran las respuestas.

Conceptos clave antes de escanear

Antes de lanzar cualquier herramienta en un entorno autorizado, hay tres ideas que conviene tener claras.

Wordlists

Una wordlist no es más que un fichero con posibles nombres de rutas o directorios. La calidad del descubrimiento depende bastante de esa lista. Si tu aplicación usa rutas convencionales, una lista genérica puede encontrar mucho. Si usa nombres específicos del negocio, necesitarás listas más adaptadas al contexto.

Respuestas HTTP

La enumeración no sólo busca rutas; también interpreta respuestas. Y ahí es donde muchos equipos filtran más información de la que creen.

Un 200 OK suele indicar que el recurso existe y responde correctamente. Un 301 Moved Permanently suele aparecer cuando hay redirecciones, algo común en contenido estático o rutas que fuerzan una barra final. Un 403 Forbidden suele confirmar algo importante: el recurso existe, pero el cliente no tiene permiso. Un 404 Not Found indica que el recurso no existe o, en algunos diseños defensivos, que el servidor ha decidido no revelar su presencia. El artículo de referencia se apoya precisamente en esa distinción para mostrar cómo cambia la visibilidad de un endpoint protegido cuando pasa de responder 403 a responder 404.

Interpretar, no sólo recolectar

El error típico de un perfil junior es ver una lista de rutas y quedarse en la superficie. Lo importante no es encontrar veinte respuestas distintas, sino entender qué implica cada una. Un 403 en /admin ya te está diciendo algo. Un 301 hacia una carpeta concreta también. Un 200 sobre un recurso que nadie recordaba puede ser el hallazgo más serio de toda la revisión.

Herramientas habituales de descubrimiento

En un laboratorio local o una auditoría con permiso, hay varias herramientas clásicas para este trabajo. El artículo que has pasado usa tres muy representativas: Gobuster, Dirb y ffuf. Las tres llegan a resultados parecidos en su ejemplo, pero con estilos de uso distintos.

Gobuster

Es rápida, directa y muy utilizada para enumeración de directorios. Su sintaxis es cómoda y suele ser una buena opción cuando quieres hacer una revisión ágil sobre rutas previsibles.

Ejemplo seguro, sólo sobre tu laboratorio local:

gobuster dir -u http://localhost:3000/ -w wordlists/common.txt

Dirb

Es un clásico. Menos “moderno” en sensación de uso, pero sigue siendo perfectamente válido para aprender, comparar resultados y entender el proceso de descubrimiento sin demasiada complejidad.

dirb http://localhost:3000/ wordlists/common.txt

ffuf

Destaca por su flexibilidad. La idea de usar FUZZ en la URL o en otros parámetros lo hace muy útil cuando necesitas más control sobre qué parte de la petición quieres probar.

ffuf -u http://localhost:3000/FUZZ -w wordlists/common.txt

No hace falta convertir esto en una competición entre herramientas. Para aprender, lo más útil es lanzar las tres contra un laboratorio propio y comparar qué encuentran, cómo presentan la salida y qué filtros te ayudan a separar ruido de señales relevantes.

Cómo leer los resultados sin engañarte

Aquí es donde la enumeración se vuelve realmente interesante. Imagina que, tras escanear tu laboratorio, encuentras algo así:

• /api/public devuelve 200
• /admin devuelve 403
• /backup.zip devuelve 200
• /old-api devuelve 301
• /noexiste devuelve 404

A nivel defensivo, no todos esos hallazgos pesan igual.

Si una ruta pública devuelve 200 y eso era esperado, no hay problema por sí mismo. Si un panel administrativo devuelve 403, quizá el control de acceso esté bien, pero el mero hecho de confirmar su existencia ya añade información útil para quien mapea la aplicación. Si una copia de seguridad devuelve 200, entonces no estás ante un detalle menor, sino ante una exposición seria. Y si una ruta antigua redirige, puede estar delatando herencia técnica o partes del sistema que no se han limpiado bien.

La regla práctica es sencilla: prioriza siempre el impacto real de cada respuesta. No todo endpoint descubierto es una vulnerabilidad, pero muchos hallazgos sí son síntomas de una arquitectura demasiado habladora.

Endurecimiento defensivo: reducir exposición sin romper la aplicación

Reducir superficie de ataque no consiste en esconder todo por sistema. Consiste en decidir qué debe ser visible, qué debe requerir autenticación y qué no debería dar ninguna pista adicional.

Una estrategia útil pasa por varios niveles.

Primero, autenticación y autorización bien aplicadas. Parece obvio, pero sigue siendo frecuente ver endpoints con controles inconsistentes según el método HTTP o según la versión del cliente.

Segundo, respuestas coherentes. Un 403 puede ser perfectamente correcto cuando el usuario ya está autenticado y simplemente no tiene permisos. Pero en algunos recursos sensibles, devolver 404 puede tener sentido para no confirmar la existencia del endpoint a clientes no autorizados. Esa idea aparece de forma explícita en el artículo de referencia: al cambiar un recurso protegido de 403 a 404, las herramientas dejan de listarlo como hallazgo visible.

Tercero, higiene de rutas. Muchas exposiciones no vienen de la lógica principal, sino de residuos: rutas de staging, documentación vieja, endpoints de pruebas, paneles internos, archivos exportados o copias de seguridad temporales.

Cuarto, observabilidad. Monitorizar patrones de escaneo y fuerza bruta de rutas ayuda a detectar actividad sospechosa antes de que se convierta en algo más serio. Un servidor que responde bien, pero no registra nada, está ciego.

Y quinto, criterio. No conviene convertir la seguridad en teatro. Devolver 404 a todo no sustituye una buena autorización. Es una capa adicional, no una solución mágica.

Buenas prácticas para desarrolladores

Si quieres reducir este tipo de exposición en proyectos reales, estas prácticas suelen aportar más que cualquier parche rápido:

Mantén inventario de rutas activas y elimina las que ya no se usan. No publiques archivos de configuración, backups ni artefactos de despliegue. Aplica autenticación y autorización en cada endpoint sensible, no sólo en la interfaz. Revisa qué respuestas HTTP está dando realmente tu aplicación en cada caso. Evita mensajes de error que revelen estructura interna o nombres de recursos. Documenta sólo lo necesario y separa documentación interna de pública. Incluye pruebas de seguridad básicas en CI/CD para detectar exposición accidental. Revisa periódicamente contenido estático, rutas legacy y configuraciones del servidor.

Conclusión

La enumeración de directorios y endpoints no es una técnica sofisticada, pero sí tremendamente efectiva para descubrir exposición innecesaria. Precisamente por eso conviene entenderla bien desde ambos lados: como ejercicio de laboratorio para aprender a leer una aplicación y como práctica defensiva para diseñar sistemas que hablen menos y protejan mejor.

Si desarrollas APIs, este tema no va sólo de herramientas. Va de criterio técnico. De saber qué muestras, qué confirmas y qué silencios ayudan a que una aplicación sea más robusta. Cuanto antes incorpores esa mirada a tu forma de construir software, menos sorpresas tendrás cuando llegue una auditoría real.

Toni Domenech