Incidentes de seguridad recurrentes: prevención de intrusiones y minimización de daños en sistemas web

Desde que comenzó 2026, especialmente en los últimos meses, los reportes de accesos no autorizados y filtraciones de información dirigidos a sistemas web de empresas nacionales se han multiplicado.
El 8 de octubre, JPCERT/CC publicó una "alerta sobre accesos no autorizados consecutivos en organizaciones nacionales recientemente" y al día siguiente, IPA también hizo un llamado a medidas de emergencia en respuesta a filtraciones de información por acceso no autorizado.

Al ver estos incidentes, es fácil enfocarse en los problemas de sistemas antiguos o software sin actualizar.
Por supuesto, estos representan riesgos significativos, pero no es una cuestión tan simple como que modernizar el sistema garantice la seguridad.

Creo que es importante implementar medidas exhaustivas para prevenir intrusiones y, en caso de que ocurra un problema de seguridad a pesar de todo, contar con un diseño de defensa en profundidad que minimice el impacto.

Esta vez examinamos la seguridad web del futuro usando como ejemplos Cloudflare, Supabase y EmDash, que se lanzó oficialmente en septiembre de 2026.

El acceso no autorizado no es algo que solo afecte a empresas especiales

Lo que JPCERT/CC destaca en esta alerta no son solo ataques dirigidos a vulnerabilidades conocidas, sino que las técnicas de ataque son diversas: búsqueda de archivos de configuración y archivos de respaldo, solicitudes no autorizadas a API, abuso de claves API robadas e intrusión interna aprovechando servidores web públicos.

Lo que es particularmente preocupante es que además de servicios para usuarios generales, sistemas de gestión para empleados y herramientas de BI también se han convertido en objetivos de ataque.
Con los avances recientes en IA, el concepto de antaño de "si no está indexado en Google, está bien" ha desaparecido, y los sistemas publicados en internet pueden estar expuestos a exploración automatizada y ataques continuos de manera inmediata.

La idea de "un sistema pequeño como el nuestro no será atacado" ya no es válida.

¿Es seguro si se utiliza tecnología moderna?

Es evidente que PHP antiguo, frameworks cuyo soporte ha finalizado y CMS que no se actualizan desde hace años representan riesgos.
Entonces, ¿es seguro construir con Next.js o Astro y utilizar servicios en la nube?

Desafortunadamente, no necesariamente. 😭

Incluso los frameworks más modernos tienen vulnerabilidades descubiertas, y si hay defectos en la autorización del API, existe la posibilidad de acceder a datos que no deberían estar disponibles.
Si se cometen errores al gestionar las credenciales de autenticación o las claves de API, incluso un servicio en la nube robusto puede sufrir brechas de seguridad, por lo que la novedad de la tecnología y la seguridad del sistema son cuestiones completamente diferentes.

Implementar defensas en Cloudflare delante de la aplicación

Cloudflare es conocido como CDN, pero también juega un papel importante en la seguridad de aplicaciones web.
Por ejemplo, el WAF (Web Application Firewall) puede detectar y bloquear solicitudes sospechosas, y los límites de tasa pueden contener accesos masivos. Además, con Cloudflare Access se puede restringir el acceso a paneles de administración internos solo a usuarios autenticados específicos.

Sin embargo, esto no es en absoluto perfecto. 😭
El riesgo está en permitir que cualquiera acceda a paneles de administración que no deberían estar públicamente disponibles.

El WAF no puede prevenir todos los ataques; se requieren medidas adicionales contra manipulaciones no autorizadas que abusan de solicitudes en formato válido y defectos de autorización específicos de la aplicación.
Cloudflare es un mecanismo que implementa defensas delante de la aplicación, no garantiza la seguridad de la aplicación en sí.

Controlar el acceso en Supabase también desde el lado de la base de datos

Lo que queremos considerar aquí es RLS (Row Level Security) disponible en Supabase.
RLS es una característica de PostgreSQL que permite controlar el alcance de acceso a nivel de fila en la base de datos. Por ejemplo, en un sistema de gestión empresarial utilizado por múltiples empresas, puede configurarse una regla en la base de datos donde los usuarios de la empresa A solo pueden ver datos de la empresa A.
Incluso si hay errores en la lógica de autorización del lado de la aplicación, un RLS correctamente configurado funciona como una defensa adicional.

Pero... RLS tampoco es una solución universal una vez configurado. 😭

La clave secreta de Supabase y la clave service_role tradicional tienen permisos potentes que pueden eludir RLS dependiendo de cómo se utilicen, por lo que si la gestión es incorrecta, la protección que proporciona RLS no será efectiva.
La configuración de permisos en la tabla y las pruebas de políticas son también esenciales.

Lo importante es no confiar solo en la autorización de la aplicación, sino también otorgar control independiente a la base de datos.

El modelo de seguridad de complementos de EmDash: no confiar desde el inicio

El 28 de septiembre de 2026, se lanzó EmDash 1.0, un CMS desarrollado con el apoyo de Cloudflare, y también se publicó el registro oficial de complementos.
Hemos estado siguiendo desde el lanzamiento e implementamos el sitio en una etapa temprana, así que es muy emocionante.

Cómo crear un blog multilingüe con EmDash: forma de reducir costos de API de traducción incluso con SSR
Migración de microCMS a EmDash + Cloudflare

Lo interesante de EmDash es su modelo de seguridad para complementos.
En los CMS tradicionales, los complementos a menudo se ejecutan con permisos similares al núcleo del CMS, y las vulnerabilidades en los complementos pueden afectar a todo el sistema, pero los complementos introducidos desde el registro oficial de EmDash se ejecutan dentro de un sandbox.
Al limitar las funciones y recursos que los complementos pueden utilizar y hacer explícitos los permisos necesarios, se reduce el alcance del impacto.

Por supuesto, EmDash también tiene complementos nativos que no utilizan sandbox, así que no significa que todos los complementos sean seguros. Además, EmDash es un CMS que acaba de lanzarse, por lo que es necesario seguir de cerca su historial operativo futuro y su respuesta de seguridad.

Aún así, la filosofía de diseño de no confiar plenamente en los complementos desde el inicio es un punto que merece atención al considerar los CMS del futuro.

Lo común es el enfoque de «no confiar en nada»

Cloudflare, Supabase y EmDash son servicios con roles diferentes, pero desde la perspectiva de la seguridad se observa un enfoque común.

• Cloudflare: controla el acceso sospechoso antes de que llegue a la aplicación
• Supabase: controla los permisos en el lado de la base de datos para el acceso desde la aplicación
• EmDash: aísla el entorno de ejecución sin otorgar permisos excesivos a los complementos

Todos ellos comparten una filosofía común: no confiar toda la seguridad a un único mecanismo, sino limitar el alcance de confianza. Esto se alinea con principios como el enfoque de confianza cero y el principio de menor privilegio, ¿no cree?

• Incluso si se burlan la autenticación, no se permiten todas las operaciones.
• Incluso si hay defectos en la API, no se pueden recuperar todos los datos.
• Incluso si hay una vulnerabilidad en el complemento, no se puede controlar todo el sistema.

Al establecer estos límites, se reduce el riesgo de que un problema individual provoque daños en todo el sistema.

Resumen: prevenir el acceso no autorizado y limitar los daños en caso de incidente

¡Pasamos a React! ¡Usamos Next.js! ¡Nos trasladamos a la nube!
Estas actualizaciones tecnológicas tienen sentido, pero (aunque a veces parezcan de hace mucho tiempo), reemplazar solo el framework o la infraestructura no es suficiente para una modernización verdadera. Lo importante es organizar las responsabilidades y permisos en autenticación, autorización, API, base de datos y servicios externos, y crear una estructura donde un compromiso en una área no se propague fácilmente a otras.

No existe seguridad absoluta.
Por eso es necesario implementar múltiples capas de defensa que prevengan intrusiones desde el principio y, incluso si surge un problema, minimicen el daño.

Aunque Cloudflare, Supabase y EmDash no son soluciones universales, estas tecnologías incluyen mecanismos para otorgar solo los permisos necesarios y establecer límites según cada función.

En Liberogic, al construir sistemas web no solo adoptamos tecnología nueva, sino que damos prioridad a la separación de responsabilidades y la defensa en profundidad.

Con los incidentes de seguridad cada vez más frecuentes, al considerar la modernización de sistemas web, es necesario prestar atención no solo a «qué tecnología usar», sino también a «qué nivel de confianza tiene el diseño».