Durante años, la página web de una entidad o empresa peruana se trató como un folleto digital: información institucional, algunos comunicados y un formulario de contacto. Esa idea quedó atrás. Hoy detrás del dominio funcionan mesas de partes virtuales, sistemas de matrícula, intranets, pasarelas de pago y conexiones con otras instituciones. Y cada una de esas piezas es una puerta que alguien, en algún lugar, está intentando abrir.
La página web dejó de ser una vitrina
Cuando una aplicación web recibe datos del usuario, consulta una base de datos o se conecta con otro sistema mediante una API, se convierte en un blanco. No importa si la organización es un ministerio, una universidad o una empresa mediana: el atacante no distingue tamaños, busca fallas.
El problema es que muchas de estas aplicaciones se construyeron hace años, con proveedores distintos y sin un inventario claro. Un portal de consultas que nadie actualiza desde 2019 sigue siendo accesible desde cualquier parte del mundo, las 24 horas.
Lo que muestran las cifras en el Perú
El volumen de ataques en el país no es menor. Según datos difundidos por el diario Expreso, en el primer semestre de 2025 se registraron más de 748 millones de intentos de ciberataque en el Perú, con el sector público como principal objetivo. En lo que va de 2026, El Comercio reportó más de 350 mil detecciones de amenazas hasta mayo, correspondientes a 1 337 familias distintas de malware.
A nivel regional, el foco se desplazó hacia las aplicaciones. Un informe de la industria sobre el estado de internet, difundido en marzo de 2026, señala que los ataques a aplicaciones web aumentaron 73 % entre 2023 y 2025. Y según cifras publicadas por medios especializados de la región, el 89 % de las organizaciones latinoamericanas reportó al menos un incidente de seguridad en sus API durante el último año, con un impacto económico promedio superior a los 700 mil dólares por caso.
Un caso reciente que muestra lo que está en juego
En junio de 2026, La República e Infobae informaron que ciberdelincuentes vulneraron servidores de la Dirección Antidrogas de la Policía Nacional del Perú y pusieron a la venta en la dark web unas 300 mil carpetas con información personal y operativa de agentes. El paquete, de 7,8 GB, se ofrecía por apenas 700 dólares.
No es un hecho aislado. Colectivos hacktivistas se han atribuido en los últimos meses la alteración de portales estatales y la filtración de documentos. El patrón se repite: aplicaciones expuestas, poca visibilidad sobre el tráfico que reciben y una reacción que llega cuando el daño ya es público.
Qué hace un WAF y qué detiene
Un firewall tradicional controla qué puertos y direcciones pueden comunicarse con la red. Un web application firewall trabaja en otra capa: se ubica entre internet y la aplicación e inspecciona cada petición web antes de que llegue al servidor.
En la práctica, un WAF bloquea intentos de inyección SQL, scripts maliciosos (XSS), explotación de vulnerabilidades conocidas, bots automatizados y ataques de denegación de servicio dirigidos a la aplicación. También permite algo muy valioso para organizaciones con sistemas antiguos: el parcheo virtual, es decir, bloquear el aprovechamiento de una falla mientras el proveedor publica la actualización o el área de TI logra aplicarla. Si quiere el detalle técnico de cada capa, lo desarrollamos en la guía sobre qué es un WAF y cómo protege a una empresa.
Un Web Application Firewall no exige reescribir el código ni migrar la aplicación, por eso suele ser la forma más rápida de proteger portales que no se pueden tocar de un día para otro.
Un WAF mal configurado se puede burlar con un solo carácter
Tener un WAF no es lo mismo que estar protegido. Lo demostró una campaña documentada esta semana a partir de una investigación de Mandiant, contra servidores de Oracle PeopleSoft, una plataforma usada para gestionar planillas, recursos humanos y registros estudiantiles.
Los atacantes aprovecharon la vulnerabilidad CVE-2026-35273, con una puntuación de 9.8 sobre 10, que permite ejecutar código de forma remota sin autenticarse. Muchas organizaciones habían bloqueado la ruta vulnerable en su WAF escribiendo una regla literal. Los atacantes simplemente codificaron una letra de la dirección: la P se convirtió en "%50". El WAF no reconoció la ruta, pero el servidor sí la interpretó correctamente y ejecutó la petición maliciosa.
Entre las víctimas hubo instituciones de educación superior, entidades de gobierno y organizaciones de salud, con programas espía instalados en decenas de sistemas y amenazas de publicar la información robada si no se pagaba un rescate. La lección es clara: un WAF con reglas estáticas y sin revisión da una sensación de seguridad que no corresponde con la realidad.
Por qué el sector público y las universidades están en la mira
Entidades públicas y universidades comparten tres características que las vuelven atractivas: manejan grandes volúmenes de datos personales (DNI, planillas, historiales académicos, datos familiares), dependen de sistemas heredados difíciles de actualizar y tienen equipos de TI reducidos frente a la cantidad de aplicaciones que deben mantener.
En ese escenario, el WAF cumple una función que va más allá del bloqueo: gana tiempo. Mientras se prioriza qué parchear primero con una estrategia de gestión de vulnerabilidades, el tráfico que intenta explotar esas fallas se detiene antes de llegar al servidor.
Lo que exige la Ley 29733 cuando el portal es vulnerado
Desde el 30 de marzo de 2025 rige el nuevo reglamento de la Ley 29733, aprobado por el Decreto Supremo 016-2024-JUS. Entre sus obligaciones, exige notificar a la Autoridad Nacional de Protección de Datos Personales dentro de las 48 horas de conocido un incidente de seguridad, comunicarlo a los titulares afectados cuando corresponda y, si ocurrió en un entorno digital, reportarlo también al Centro Nacional de Seguridad Digital.
Cumplir ese plazo exige saber qué pasó, cuándo y qué datos se vieron comprometidos. Los registros de un WAF bien operado son, muchas veces, la única fuente confiable para reconstruir un ataque web en tan poco tiempo.
Cómo implementar un WAF que realmente proteja
La diferencia entre un WAF útil y uno decorativo está en la operación. Estas prácticas marcan esa diferencia:
- Inventario primero. No se puede proteger lo que no se conoce. Identifique todos los portales, subdominios y API expuestos, incluidos los que administran terceros.
- Aprendizaje antes del bloqueo. Un periodo inicial en modo monitoreo permite ajustar las reglas al tráfico real y evitar bloquear a usuarios legítimos.
- Reglas que interpretan, no que comparan texto. El WAF debe normalizar las peticiones antes de evaluarlas, justamente para evitar evasiones como la del caso PeopleSoft.
- Monitoreo con personas. Alguien tiene que revisar alertas, ajustar reglas y reaccionar cuando aparece una vulnerabilidad nueva. Es la misma diferencia entre tener la herramienta instalada y tener a alguien revisándola.
- Complemento, no reemplazo. El WAF compra tiempo, pero las aplicaciones igual deben actualizarse.
Conclusión
El portal institucional dejó de ser una vitrina y pasó a ser la puerta principal de la organización. Detrás de él hay trámites, expedientes y datos de ciudadanos, y del otro lado hay tráfico automatizado buscando una falla las 24 horas.
Un WAF es la forma más rápida de poner un filtro delante de aplicaciones que no se pueden reescribir mañana. Pero el caso de PeopleSoft deja la advertencia: instalarlo y olvidarlo se parece bastante a no tenerlo. Lo que protege no es el producto, sino alguien revisando sus reglas y sus alertas con regularidad.
