Cuidado: ¿robots.txt abre un vector de ataque?

Sí, robots.txt puede ser un vector de ataque significativo. Aunque no es un mecanismo de seguridad sino una guía para buscadores, los atacantes lo usan para mapear directorios sensibles, identificar tecnologías del sitio y enfocarse en blancos de penetración. Archivos con configuraciones mal pensadas exponen rutas privadas, backups y paneles administrativos sin protección.

¿Qué es robots.txt y por qué es público?

El archivo robots.txt es una convención web ubicada en la raíz del dominio (https://ejemplo.com/robots.txt) que indica a los buscadores y bots cuáles secciones del sitio pueden indexar. Es un archivo de texto plano, sin autenticación, sin encriptación, completamente accesible para cualquiera que lo busque directamente.

Acá viene lo importante: robots.txt NO es un mecanismo de seguridad. Nunca fue diseñado para proteger contenido. Es una herramienta de cortesía (ponele que así) para que los bots respetables no carguen innecesariamente contra tu servidor. Una “sugerencia” amable, nada más.

El problema es que la gente confunde “no indexar” con “no acceder”. Publicas un archivo robots.txt con Disallow: /private/ pensando que proteges /private/, y en realidad estás publicando un mapa que dice “acá hay algo importante que quiero esconder”.

Cómo usan los atacantes robots.txt para reconocimiento

Un penetration tester siempre revisa robots.txt. Es el primer paso. ¿Por qué? Porque actúa como un blueprint de la paranoia del administrador. Te dice cuáles directorios, versiones antiguas, APIs privadas y sistemas backend existen.

Ponele que ves esto en un robots.txt:

Disallow: /wp-admin/
Disallow: /backup/
Disallow: /api/v1/private/
Disallow: /old-portal/
Disallow: /.env.backup

En segundos, un atacante sabe: es WordPress, tiene un directorio de backups expuesto, hay una API privada que probablemente no está bien securizada, hay código legacy corriendo, y hay un archivo de backup con variables de entorno. Eso es material de oro.

Los bots maliciosos específicamente buscan robots.txt como primer paso. No respetan las directivas, pero usan la información para identificar qué atacar. Los scanners de vulnerabilidad, las herramientas de pentesting, los buscadores de exploits: todos comienzan por acá.

Exposición de directorios a través de Disallow

Cuando publicas Disallow: /admin/, confirmas que el directorio existe. No estás protegiéndolo; estás marcándolo con un cartel de neón que dice “ADMINISTRACIÓN POR AQUÍ”.

Los atacantes son creativos. Ven Disallow: /wp-admin/ y prueban variaciones: /wp-admin/admin.php, /wp-admin/index.php?redirect=, /wp-admin/admin-ajax.php. Ven Disallow: /backup/ e intentan /backup/database.sql, /backup/db_dump.tar.gz, /backup/.htaccess.

La información revela tecnología. Disallow: /wp-admin/ = WordPress. Disallow: /admin/ = probablemente Drupal, Magento o custom PHP. Disallow: /_next/ = Next.js. Con eso, los atacantes focalizan exploits conocidos para esa plataforma.

He visto (sí, en serio) empresas con Disallow: /credentials.txt, Disallow: /internal-ip-whitelist.txt, Disallow: /secret-api-keys.env. No es chiste. El archivo robots.txt revelaba la existencia de archivos con ese nombre, aunque no fuera posible acceder a ellos directamente. Bastaba eso para que alguien intentara encontrarlos por otros medios.

Path disclosure: mapeo automático de estructura web

Path disclosure es una vulnerabilidad de información donde se revela la estructura completa del sitio. robots.txt es una forma descontrolada de path disclosure.

Los atacantes compilan listas públicas de robots.txt de miles de sitios, buscan patrones, identifican cuáles directorios son comunes y cuáles son raros. Detectan tecnologías, frameworks, versiones de software. Si ves que 50 sitios WordPress tienen Disallow: /wp-json/wp/v2/users, sabes que esa ruta es un objetivo frecuente.

Hay herramientas que automatizan esto. Descargás el robots.txt, lo parseas, extraés todos los Disallow, y compilás una lista de directorios a probar. Luego les pegás fuzzing: intentás acceder a cada uno, probás variaciones, buscás respuestas 200, 403, 401, 302. Una respuesta 200 significa acceso público. Una 403 significa que la ruta existe pero estás bloqueado (útil de todas formas, porque confirma la estructura).

Google Dorks + robots.txt: búsquedas avanzadas para encontrar datos sensibles

Google Dorks es una técnica de búsqueda avanzada que combina operadores especiales: site:, inurl:, filetype:, intitle:. Un atacante combina directorios revelados en robots.txt con Google Dorks para encontrar exactamente lo que buscas.

Supongamos que ves en robots.txt: Disallow: /admin/, Disallow: /backup/, Disallow: /config/. El atacante corre:

site:ejemplo.com inurl:backup filetype:sql
site:ejemplo.com inurl:config filetype:ini
site:ejemplo.com inurl:admin filetype:php

Encuentra archivos SQL sin protección, archivos INI con contraseñas por defecto, scripts PHP abandonados. He visto casos donde una búsqueda simple encontraba credenciales de base de datos, API keys, contraseñas en comentarios de código.

El combo robots.txt + Google Dorks es devastador porque es automático. No requiere habilidad especial. No requiere herramientas sofisticadas. Es buscar en Google como lo hace cualquiera.

¿Allow es más seguro que Disallow? Desmitificando la diferencia

Mito común: “Si uso Allow en vez de Disallow, es más seguro”.

Falso. Allow y Disallow son igual de públicos. Ambos aparecen en el archivo robots.txt. Ambos son texto plano, accesible, legible.

La diferencia técnica es que Allow puede especificar excepciones dentro de un Disallow más amplio. Ejemplo:

Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Significa: bloquea todo /wp-admin/, excepto admin-ajax.php. Es útil para funcionalidad frontend que depende del endpoint AJAX. Pero nuevamente (si es que eso cuenta como mejora), ambas líneas son públicas. Un atacante ve exactamente dónde están tus endpoints JavaScript críticos. Relacionado: mejores prácticas de seguridad en la web.

Lo que importa no es la directiva. Lo que importa es que ni Allow ni Disallow protegen contra acceso directo si alguien conoce la URL. Si yo sé que existe /wp-admin/, puedo acceder a ella directamente si no hay autenticación en el servidor.

robots.txt NO es un firewall. NO es un control de acceso. Es una sugerencia. Los bots legítimos la respetan. Los bots maliciosos la ignoran completamente. ¿Alguien verificó esto? Sí, hace años, los investigadores demostraron que bots específicamente programados para hacking deliberadamente buscan directivas Disallow y las visitan primero.

Los límites de robots.txt como herramienta de seguridad

robots.txt funciona solo si el cliente (el bot) decide respetarlo. Los bots respetables de Google, Bing, DuckDuckGo respetan las reglas. Googlebot honra robots.txt. Bingbot honra robots.txt.

Pero hay miles de bots que no respetan nada. Bots de scraping, bots de hacking, malware, botnets, herramientas de pentesting: todos ignoran robots.txt completamente. Para ellos el archivo es información útil (qué no atacar, qué atacar primero), pero no es una restricción.

Entonces robots.txt es asimétrico: protege contra robots honestos (que no eran la amenaza), pero da información útil a robots maliciosos (que son la amenaza real).

Dicho esto, hay un caso donde robots.txt tiene un propósito legítimo: evitar que Googlebot indexe contenido que no querés en la búsqueda. Si tenés un directorio de staging, un admin panel, un endpoint de prueba: tiene sentido decirle a Google “no indexes esto”. Googlebot va a respetar la directiva. El problema es si confiás en robots.txt para proteger contra atacantes. Eso es ilusión de seguridad.

Métodos correctos para proteger información sensible

Si querés proteger de verdad, acá están las alternativas:

Autenticación básica HTTP

Cualquiera que intente acceder a /admin/ recibe un pop-up pidiendo usuario y contraseña. Sin credenciales válidas, no accede. Es simple, está en el estándar HTTP, y funciona.

Restricciones de servidor (.htaccess, nginx config)

En Apache: Deny from all en .htaccess. En nginx: reglas de bloqueo en la config. El servidor rechaza la solicitud antes de que llegue a tu aplicación. Es una barrera real.

Control de acceso en tu aplicación

Auténtica el usuario, valida el rol, controla qué puede ver. Si no pasó el login, devolvé 403 Forbidden. Es la forma correcta de hacerlo.

IP whitelisting

Solo IPs específicas pueden acceder a /admin/. Tu rango de oficina, tu VPN, IPs de staging. Nadie de afuera accede sin estar en la lista.

Encriptación y obfuscación

Si el contenido es sensible, encriptalo. Si querés esconder endpoints, no los dejes en robots.txt, no los dejes accesibles sin autenticación.

Noindex META tag y X-Robots-Tag

El header X-Robots-Tag: noindex previene que Googlebot indexe una página, pero NO previene que acceda a ella. Si tu contenido es sensible en serio, no confíes solo en noindex.

La regla es: autenticación para lo sensible, robots.txt solo para guiar buscadores legítimos.

Errores comunes en robots.txt

Error 1: Listar toda la estructura en Disallow

Publicar Disallow: /private/, /backup/, /admin/, /test/, /staging/, /old-api/ es como dejar un mapa. En vez de eso, autenticá esos directorios en el servidor.

Error 2: Asumir que robots.txt protege de scrapers

Si un scraper quiere tus datos, robots.txt no lo detiene. Necesitás rate limiting, detección de bots, o restringir acceso por token de API.

Error 3: Poner credenciales o secretos en Disallow

He visto Disallow: /backup-2026-01-15-SECRET-PASSWORD.sql. Publicaste el nombre exacto del archivo. ¿Cómo es que alguien lo encuentra? Probando la URL exacta que revelaste.

Error 4: Creer que Allow suprime Disallow

Disallow: /admin/ bloquea todo. Allow: /admin/admin-ajax.php es una excepción, pero /admin/ sigue siendo público en el archivo. El atacante ve ambas líneas.

Error 5: No versionar el archivo

Si cambias la estructura del sitio, asegurate de actualizar robots.txt. Dejar directorios viejos en Disallow cuando ya no existen es información obsoleta pero peligrosa. Un atacante intenta acceder a esos directorios imaginarios, los encontraría si no los eliminaste completamente.

Preguntas Frecuentes

¿Qué información sensible puede exponer un robots.txt mal configurado?

Ubicación de paneles administrativos, directorios de backup, APIs privadas, versiones de software, endpoints de testing, directorios legacy, archivos de configuración. Toda esa información sirve para reconnaissance, identificar vulnerabilidades conocidas y focalizados ataques dirigidos.

¿Los bots maliciosos realmente ignoran robots.txt?

Completamente. Los bots legítimos (Googlebot, Bingbot) respetan robots.txt porque están diseñados para ser “buenos ciudadanos”. Los bots de hacking, scrapers maliciosos y botnets ignoran el archivo porque no les importa la cortesía. robots.txt es honra entre ladrones: solo protege si el otro decide respetar.

¿Disallow es más seguro que Allow?

No. Allow y Disallow son igual de públicos. Allow puede ser más específico (permite excepciones dentro de bloques), pero ambas directivas aparecen en texto plano en robots.txt. Ni una ni la otra protegen contra acceso directo.

¿Puedo usar robots.txt para esconder información privada?

No. robot.txt es público. Si querés información privada, usá autenticación, restricciones de servidor, control de acceso en tu código. robots.txt es para guiar buscadores legítimos, no para esconder cosas.

¿Cómo se si mi robots.txt es vulnerable?

Abrí https://tupagina.com/robots.txt y revisá: ¿Revelás directorios de administración? ¿Listad backups o archivos de configuración? ¿Mencionás versiones de software? Si la respuesta es sí, no estás protegiendo; estás ayudando a los atacantes. Replicalo con autenticación en el servidor en lugar de confiar en robots.txt.

Conclusión

robots.txt es un vector de ataque porque asume un nivel de confianza que no existe en seguridad. Es una herramienta de cortesía diseñada en los 90, cuando Internet era un lugar más benigno. Hoy, publicar un robots.txt detallado es como dejar un plano del edificio en la puerta principal.

Eso no significa que no debas tener robots.txt. Deberías. Pero úsalo correctamente: para guiar a Googlebot y otros buscadores legítimos en qué indexar, no como mecanismo de seguridad.

Para proteger de verdad, implementá autenticación, restricciones en el servidor, control de acceso en tu código, IP whitelisting donde sea necesario. Eso sí bloquea a los atacantes. robots.txt solo les da un mapa.

Fuentes

• Baeldung — robots.txt Risk and Threat
• PortSwigger Web Security Academy — robots.txt file
• Google Search Central — Robots.txt Intro
• OWASP — Review Webserver Metafiles for Information Leakage
• SmartScanner — Is Your robots.txt File Vulnerable?