"A mí quién me va a atacar, si tengo una tienda de barrio." Lo oímos bastante, y se entiende: uno se imagina a alguien eligiendo a quién atacar.
No funciona así. Lo que hay ahí fuera son programas que recorren miles de webs al día probando las mismas cuatro cosas en todas. No saben si eres una peluquería o un banco, ni les importa. Solo buscan una puerta abierta.
Y lo que duele de verdad no es que entren, es lo que viene después. Cuando Google detecta que una web está comprometida, la marca como sitio engañoso: al que entra le sale un aviso rojo a pantalla completa, y desapareces de los resultados de búsqueda. Volver cuesta meses, y mientras tanto tu competencia ocupa tu sitio.
Estas son las cuatro puertas por las que se cuelan y cómo se cierran. La parte del medio es técnica, para que se la puedas pasar a quien te lleve la web; el principio y el final valen para cualquiera.
Por dónde empezar: entender antes de probar
La tentación es lanzar un escáner y ver qué sale. Es la forma más lenta de auditar y la que más falsos positivos genera.
El primer paso es hacer el mapa del proyecto:
- —Qué formularios existen, en qué archivo, con qué campos y contra qué endpoint escriben.
- —Qué endpoints tiene el backend, con qué método HTTP, cuáles llevan guard de autenticación y cuáles validan el cuerpo de la petición.
- —Qué rutas del frontend suenan a zona privada: cualquier cosa con "admin", "dashboard", "panel", "interno".
- —Si existe una página 404 propia o se está usando la de serie.
Con ese mapa, las pruebas van dirigidas. Sin él, estás disparando a ciegas contra tu propia web.
1. Inyección y XSS en formularios
El riesgo es siempre el mismo: un dato que escribe el usuario acaba interpretado como código en lugar de tratado como texto. Hay tres variantes y cada una se arregla en un sitio distinto, así que conviene distinguirlas:
| Tipo | Qué pasa | Dónde se arregla |
|---|---|---|
| Reflejado | El dato vuelve en la respuesta sin escapar | Salida del backend y renderizado |
| Almacenado | Se guarda en base de datos y aparece después en otra vista | Validación de entrada + escapado en la salida |
| En el DOM | El frontend inserta HTML crudo del usuario | El componente que lo inserta |
Qué revisar en el frontend
React escapa el contenido por defecto, y eso cubre la mayoría de los casos. El agujero aparece cuando alguien se salta ese comportamiento a propósito: dangerouslySetInnerHTML, manipulación directa de innerHTML, o inyección de HTML devuelto por una API.
La forma más fiable de encontrarlo no es probando desde fuera, es buscándolo en el código: un grep de esos patrones da el listado completo en segundos. Para cada aparición, la pregunta es si el contenido puede provenir de un usuario. Si puede, o se sanea con una librería dedicada, o se elimina el HTML crudo — que casi siempre es la opción correcta, porque en la mayoría de los casos no hacía falta.
Qué revisar en el backend
Que los DTOs validen de verdad. Un DTO que acepta cualquier cadena de cualquier longitud no está validando nada. Con class-validator en Nest.js: reglas por campo (formato de email, longitud máxima, patrón permitido) y el ValidationPipe global con whitelist: true y forbidNonWhitelisted: true, para que cualquier campo no declarado se descarte en lugar de llegar a la lógica de negocio.
Y una cabecera que hace mucho por poco: una Content-Security-Policy restrictiva en la configuración de Next.js. No sustituye a sanear la entrada, pero convierte muchos XSS explotables en intentos fallidos.
2. Login: fuerza bruta y filtración de información
Esta es la vulnerabilidad que más veces encontramos abierta, porque el login "funciona" perfectamente. Cuatro comprobaciones:
¿Hay límite de intentos? Sin rate limiting, un bot puede probar contraseñas indefinidamente. La prueba es trivial: seis o diez intentos con contraseña incorrecta. Si nunca aparece un 429 ni un bloqueo temporal, el fallo está confirmado. No hace falta un diccionario para demostrarlo.
¿El mensaje de error distingue casos? "Este usuario no existe" frente a "contraseña incorrecta" es una diferencia útil para el usuario y un regalo para el atacante: permite enumerar qué correos están registrados sin acertar ni una contraseña. El mensaje debe ser el mismo en ambos casos: credenciales incorrectas.
¿Cómo se guardan las contraseñas? Con bcrypt o argon2, siempre. Nunca en texto plano, nunca con MD5 o SHA-1 pelados.
¿Cómo se guarda la sesión? Si son cookies: HttpOnly (para que el JavaScript no pueda leerlas), Secure (solo por HTTPS) y SameSite. Si es un JWT: el secreto en variables de entorno — nunca en el repositorio — y una expiración razonable.
El arreglo
En Nest.js, un throttler en el endpoint de login con un límite del orden de cinco intentos por minuto por IP y usuario, mensajes de error homogéneos, y helmet para las cabeceras de seguridad si no está ya. Es media tarde de trabajo y cierra el vector de ataque automatizado más común que existe.
3. Rutas de administración expuestas
Un panel de administración accesible sin autenticación es el fallo más grave y también el más fácil de comprobar. Lo importante no es si la ruta existe, sino qué devuelve a alguien que no ha iniciado sesión:
| Respuesta | Veredicto |
|---|---|
| 200 con contenido real | Crítico |
| 401 / 403 | Correcto |
| Redirección al login | Correcto |
| 404 limpio | Correcto |
La lista de rutas a probar sale de dos sitios: las sospechosas por convención (/admin, /dashboard, /panel, /api/docs, /swagger, /.env, /.git, /backup) y las reales del proyecto cuyo nombre sugiera zona privada. Las segundas son las que importan, porque son las que existen de verdad.
Tres cosas que se olvidan siempre:
- —La documentación de la API en producción. Un Swagger público es un mapa completo de tus endpoints. En producción, o se protege o se desactiva.
- —Archivos de configuración accesibles.
.envo.gitservidos por el servidor web son una filtración directa de credenciales e historial. - —
robots.txty sitemap listando rutas privadas. Aunque la ruta esté protegida, estás publicando dónde buscar. Bloquear conDisallowes lo correcto, pero recuerda que eso no protege nada: solo evita el indexado. La protección es el guard.
El arreglo es el guard de autenticación y roles que falta — en el backend en el controlador, en el frontend en el middleware o en el layout de la zona privada. Y protegerlo en los dos lados: ocultar el enlace del menú no es seguridad, la ruta sigue ahí.
4. La página 404: seguridad y SEO a la vez
Una 404 parece un detalle de diseño. Tiene dos implicaciones reales.
Seguridad: una página de error por defecto puede filtrar información técnica — el framework, la versión, rutas del servidor, trazas de error. Es información gratis para quien está buscando por dónde entrar. Una 404 propia no revela nada.
SEO: los enlaces que apuntan a páginas que ya no existen se pierden si el visitante se va. Una 404 con la navegación del sitio, un enlace al inicio y quizá a los servicios principales convierte un callejón sin salida en una segunda oportunidad. Y debe devolver el código de estado 404 real, no un 200 con un mensaje de error: si devuelve 200, Google indexa la página de error como contenido válido.
En Next.js con App Router basta un archivo not-found.tsx, usando los colores y el logo que ya tiene el proyecto. Es una hora de trabajo, aparece en cada enlace roto de por vida, y no hay excusa para no tenerla.
Cómo priorizar los hallazgos
No todo lo que sale en una auditoría tiene el mismo peso:
| Severidad | Ejemplos | Plazo |
|---|---|---|
| Crítica | Panel de admin sin auth, credenciales en el repositorio, contraseñas sin hashear | Inmediato |
| Alta | XSS almacenado, login sin rate limiting, .env accesible | Esta semana |
| Media | Cookies sin HttpOnly, sin CSP, Swagger público, enumeración de usuarios | Este mes |
| Baja | 404 por defecto, cabeceras informativas, dependencias desactualizadas sin CVE conocido | Este trimestre |
Y algo importante sobre el informe: si documentas vulnerabilidades sin corregir con todo el detalle, ese documento pasa a ser tan sensible como el propio agujero. No lo dejes en un repositorio público ni en una carpeta compartida.
Higiene continua, no auditoría única
Una auditoría es una foto. Lo que mantiene la web segura es la rutina:
- —
npm auditde vez en cuando, y actualizar lo que tenga vulnerabilidad conocida. - —Secretos siempre en variables de entorno, nunca en el código. Y si alguno se ha subido al repositorio alguna vez, rotarlo — el historial de Git no olvida.
- —Copias de seguridad que alguien haya restaurado al menos una vez. Una copia que nunca se ha probado es una suposición, no una copia.
- —Repetir las cuatro comprobaciones de esta guía después de cada cambio grande: nuevo formulario, nuevo endpoint, cambio en el login.
Preguntas frecuentes
Mi web es pequeña, ¿de verdad me van a atacar? No te van a atacar a ti: van a atacar a todo el mundo a la vez. Los escaneos son automáticos e indiscriminados. Que el negocio sea pequeño no reduce la probabilidad, solo reduce lo que el atacante consigue si entra — y aun así, perder la web o salir de Google unas semanas duele bastante.
¿Un certificado SSL no me protege ya? HTTPS cifra el tránsito entre el navegador y el servidor. No valida formularios, no limita intentos de login y no protege rutas. Es necesario y no es suficiente.
¿Con qué frecuencia hay que auditar? Una revisión completa al año, y las comprobaciones puntuales después de cada cambio relevante. Si hay login o formularios que escriben en base de datos, cada seis meses es más razonable.
¿Esto ralentiza la web? No de forma perceptible. Validar un formulario y comprobar un límite de intentos son operaciones de microsegundos. Si te preocupa el rendimiento, el problema está en otro sitio: mira cómo llegar a 100 en PageSpeed.
Conclusión
Las cuatro comprobaciones de esta guía cubren la mayor parte de lo que un atacante automatizado intenta contra una web de negocio: colar código por un formulario, reventar el login a base de intentos, entrar por una ruta que nadie protegió y leer lo que un error revela de más.
Ninguna requiere semanas de trabajo. Requieren revisarlas una vez, arreglar lo que salga y volver a comprobarlo. Y como la seguridad, el rendimiento y el SEO técnico se auditan sobre el mismo código, tiene sentido hacerlo en la misma pasada: el checklist de auditoría SEO local cubre el otro frente.
Si prefieres que lo revisemos nosotros, auditamos tu web y te entregamos los hallazgos por severidad, con el arreglo aplicado en el código, no solo señalado en un PDF.
Solicitar auditoría de seguridad · Ver servicio de consultoría
¿Quieres que tu negocio aparezca en Google?
Hablamos de tu negocio, tu competencia y lo que realmente necesitas. Sin compromiso. Te respondemos en menos de 48 horas con orientación clara y un presupuesto cerrado.
Agendar Consulta Gratuita
