Lexnet, la seguridad y los permisos para acceder a contenido

Lexnet y la vulnerabilidad que expuso la justicia electrónica española

En julio de 2017, España descubrió que su sistema de justicia electrónica, Lexnet, adolecía de una vulnerabilidad crítica que permitía a cualquier usuario autenticado acceder a documentos judiciales de otros profesionales y ciudadanos con solo modificar un parámetro en la URL del navegador. Lo que debería haber sido un sistema seguro para el intercambio de escritos, notificaciones y documentos procesales entre abogados, procuradores y órganos judiciales se convirtió, de la noche a la mañana, en el ejemplo paradigmático de los problemas de seguridad de Lexnet y de lo que no debe ser la seguridad en la justicia electrónica.

Este artículo analiza en profundidad la vulnerabilidad de Lexnet, explica de forma accesible en qué consiste un fallo de tipo IDOR, reconstruye la cronología completa de la crisis de 2017, examina las implicaciones legales bajo el Esquema Nacional de Seguridad (ENS) y el Reglamento General de Protección de Datos (RGPD), y evalúa el estado actual del sistema en 2026. Si desea profundizar en otros aspectos de ciberseguridad y derecho tecnológico, le invitamos a consultar nuestros artículos especializados.

¿Qué es Lexnet? El sistema de justicia electrónica de España

Lexnet es la plataforma telemática del Ministerio de Justicia de España diseñada para la presentación de escritos y documentos, la recepción de notificaciones judiciales y la comunicación electrónica entre los operadores jurídicos (abogados, procuradores, graduados sociales) y los órganos judiciales. Su uso es obligatorio para la mayoría de los profesionales del ámbito judicial desde la entrada en vigor de la Ley 42/2015, de 5 de octubre, que reformó la Ley de Enjuiciamiento Civil para impulsar la tramitación electrónica.

El sistema gestiona información de extrema sensibilidad: escritos de demanda, documentos probatorios, sentencias, datos personales de víctimas y menores. Por ello, la seguridad de Lexnet no es un asunto meramente técnico, sino una cuestión de derechos fundamentales: tutela judicial efectiva, intimidad y protección de datos personales.

La vulnerabilidad: qué ocurrió y cómo funcionaba

La vulnerabilidad descubierta en Lexnet era de un tipo bien conocido en ciberseguridad: un fallo de Insecure Direct Object References (IDOR), es decir, una referencia directa insegura a objetos. En términos prácticos, el sistema asignaba a cada documento un identificador numérico secuencial y lo incluía como parámetro en la URL de acceso. Cuando un usuario legítimo —por ejemplo, un abogado— accedía a un documento de su caso, la URL contenía algo similar a:

https://lexnet.justicia.es/documento?id=123456

El problema radicaba en que el servidor no verificaba que el usuario autenticado tuviera autorización para acceder al documento solicitado. Bastaba con modificar manualmente el número identificador en la barra de direcciones del navegador —cambiar 123456 por 123457, 123458 o cualquier otro número— para acceder a documentos pertenecientes a otros procedimientos judiciales, de otros abogados, de otros procuradores y, en definitiva, de otros ciudadanos.

No se requería ningún conocimiento técnico avanzado. No hacía falta explotar ninguna vulnerabilidad sofisticada, utilizar herramientas de hacking ni superar barreras criptográficas. Cualquier persona con acceso legítimo a Lexnet podía, con un simple cambio de número en la URL, leer documentos judiciales ajenos.

¿Qué es una vulnerabilidad IDOR? Explicación para no técnicos

Para comprender la gravedad del fallo de Lexnet, conviene explicar qué es una vulnerabilidad IDOR (Insecure Direct Object Reference) de forma accesible para quienes no tienen formación técnica.

Imagine un hotel donde cada habitación tiene un número en la puerta: 101, 102, 103, y así sucesivamente. Usted recibe la llave de la habitación 101. En un hotel normal, su llave solo abre su habitación; si intenta abrir la 102, la cerradura no gira. En un hotel con un «fallo IDOR», todas las puertas se abren con cualquier llave: basta con saber el número de la habitación para entrar. Su llave le identifica como huésped del hotel (está autenticado), pero nadie comprueba si tiene derecho a entrar en esa habitación concreta (no hay autorización).

Esto es exactamente lo que ocurría en Lexnet. El sistema verificaba que el usuario fuera un profesional legítimo con certificado digital (autenticación), pero no comprobaba que ese profesional concreto estuviera autorizado a ver el documento concreto que solicitaba (autorización). La confusión entre autenticación y autorización es, de hecho, uno de los errores más frecuentes y peligrosos en el desarrollo de aplicaciones web.

IDOR en el contexto de OWASP

La vulnerabilidad IDOR está catalogada dentro de la categoría A01:2021 – Broken Access Control (Control de Acceso Roto) del OWASP Top 10, la lista de referencia mundial de las vulnerabilidades más críticas en aplicaciones web, elaborada por la Open Web Application Security Project. El control de acceso roto ha escalado hasta la primera posición de esta clasificación, lo que refleja su frecuencia y gravedad. En versiones anteriores del OWASP Top 10, la referencia directa insegura a objetos aparecía como categoría independiente (A4 en la edición de 2013).

Que un sistema judicial nacional presente exactamente la vulnerabilidad que encabeza la lista de fallos más críticos a nivel mundial da una idea de la magnitud del problema.

Cronología completa de la crisis de Lexnet en 2017

La crisis de seguridad de Lexnet en el verano de 2017 no fue un incidente aislado, sino una cascada de fallos que se sucedieron en pocas semanas y que pusieron en evidencia problemas estructurales de la plataforma.

Fase 1: Descubrimiento de la vulnerabilidad IDOR (julio de 2017)

A principios de julio de 2017, un profesional del ámbito jurídico detectó que, al modificar el identificador numérico de un documento en la URL de Lexnet, podía acceder a escritos y notificaciones de otros procedimientos judiciales. La noticia comenzó a circular en foros profesionales y redes sociales, generando una alarma creciente entre abogados y procuradores que, de repente, comprendían que la confidencialidad de los asuntos de sus clientes podía haber estado comprometida desde hacía tiempo.

Fase 2: Exposición del servidor y datos adicionales (julio de 2017)

Mientras la atención se centraba en la vulnerabilidad IDOR, se descubrió un segundo problema: un servidor asociado a Lexnet estaba accesible desde Internet sin las protecciones adecuadas, exponiendo información adicional del sistema. Este segundo fallo agravó la percepción de que la infraestructura tecnológica de la justicia electrónica española no había sido sometida a los controles de seguridad mínimos exigibles.

Fase 3: Desconexión de Lexnet (27-28 de julio de 2017)

Ante la presión mediática y profesional, el Ministerio de Justicia decidió desconectar Lexnet temporalmente para realizar una auditoría de seguridad y corregir los fallos detectados. La caída del sistema tuvo un impacto operativo enorme: miles de profesionales no pudieron presentar escritos ni recibir notificaciones durante el periodo de inactividad, con las consiguientes consecuencias procesales (vencimiento de plazos, imposibilidad de cumplir términos judiciales, etc.).

Fase 4: Respuesta del Ministerio de Justicia

El entonces Ministro de Justicia, Rafael Catalá, compareció públicamente para abordar la crisis. Su respuesta generó una controversia adicional, ya que restó importancia a la vulnerabilidad, equiparándola a problemas de seguridad que «ocurren en todas partes» y sugiriendo que no se había producido ningún acceso indebido a datos. Esta minimización fue criticada tanto por la comunidad de ciberseguridad como por los colegios profesionales de abogados y procuradores, que exigieron explicaciones más detalladas y garantías concretas.

La respuesta del Ministerio ilustró un problema recurrente en la gestión de incidentes de seguridad en el sector público: la tendencia a minimizar la gravedad de las vulnerabilidades en lugar de abordarlas con transparencia y rigor. En materia de ciberseguridad, la confianza de los usuarios se construye con información veraz y medidas correctivas demostrables, no con declaraciones tranquilizadoras carentes de sustento técnico.

Fase 5: Restablecimiento y consecuencias (agosto de 2017 en adelante)

Lexnet fue restablecido tras la aplicación de parches de seguridad, pero la confianza en el sistema quedó gravemente dañada. El incidente motivó:

• Solicitudes de información por parte de los colegios de abogados y procuradores.
• Preguntas parlamentarias sobre la seguridad de los sistemas judiciales.
• Un debate público sobre la necesidad de auditorías de seguridad independientes en los sistemas de la Administración de Justicia.
• Reclamaciones ante la Agencia Española de Protección de Datos (AEPD).

La respuesta del Ministro de Justicia: un caso de estudio en mala gestión de crisis

La reacción del Ministro Rafael Catalá constituye un ejemplo de lo que no debe hacerse al comunicar un incidente de seguridad: se minimizó el impacto de una vulnerabilidad que afectaba a millones de procedimientos, no se proporcionaron datos técnicos sobre el alcance de la brecha, no se asumieron responsabilidades concretas y no se comunicó un plan público de remediación ni se anunciaron auditorías independientes.

La gestión de un incidente de seguridad en un sistema público debe regirse por los principios de transparencia, proporcionalidad y rendición de cuentas. La minimización solo contribuye a erosionar la confianza ciudadana en las instituciones.

¿Cómo debería funcionar un sistema de control de acceso seguro?

Para dimensionar la gravedad de la vulnerabilidad de Lexnet, es útil comprender cómo debería haber funcionado el control de acceso del sistema. Un diseño seguro se basa en varios principios y mecanismos complementarios:

Control de Acceso Basado en Roles (RBAC)

El modelo RBAC (Role-Based Access Control) asigna permisos a roles, no directamente a usuarios individuales. En el contexto de Lexnet, esto significaría definir roles como «abogado del caso X», «procurador del caso X», «letrado de la Administración de Justicia del juzgado Y» o «fiscal de la causa Z», y otorgar a cada rol acceso exclusivamente a los documentos de los procedimientos en los que participa. Un abogado solo debería poder acceder a los documentos de los casos en los que está personado, nunca a los de otros procedimientos.

Principio de mínimo privilegio

El principio de mínimo privilegio (principle of least privilege) establece que cada usuario debe tener únicamente los permisos estrictamente necesarios para realizar su función, y nada más. En Lexnet, esto implicaría que un abogado no solo no debería poder ver documentos de otros casos, sino que tampoco debería poder acceder a funcionalidades administrativas del sistema, a estadísticas globales ni a cualquier recurso que exceda su necesidad operativa concreta.

Validación en el lado del servidor

Toda solicitud de acceso a un recurso debe ser validada en el servidor, nunca únicamente en el cliente (navegador). Cuando un usuario solicita un documento, el servidor debe verificar:

1. Autenticación: ¿Es este usuario quien dice ser? (verificación de identidad mediante certificado digital, contraseña, etc.)
2. Autorización: ¿Tiene este usuario concreto permiso para acceder a este documento concreto? (verificación de que el usuario está vinculado al procedimiento al que pertenece el documento)
3. Registro de auditoría: Debe quedar constancia del acceso para fines de trazabilidad y detección de anomalías.

El fallo fundamental de Lexnet fue la ausencia del segundo paso: se verificaba la identidad del usuario, pero no su autorización para acceder al recurso solicitado.

Identificadores no predecibles

Una buena práctica complementaria consiste en utilizar identificadores no secuenciales ni predecibles para los recursos. En lugar de asignar identificadores numéricos consecutivos (1, 2, 3...), se recomienda utilizar identificadores aleatorios de tipo UUID (por ejemplo, a7f3b2c1-4d5e-6f78-9a0b-c1d2e3f4a5b6). Aunque esto no sustituye la validación de autorización —que sigue siendo imprescindible—, dificulta significativamente la enumeración de recursos por parte de un atacante.

Pruebas de seguridad automatizadas y auditorías

Un sistema de la criticidad de Lexnet debería someterse a pruebas de penetración (pentesting) periódicas, análisis de código estático y dinámico, y auditorías de seguridad independientes antes de cada despliegue significativo. La vulnerabilidad IDOR es detectable mediante herramientas automatizadas de escaneo de seguridad, lo que sugiere que estas pruebas no se realizaron o no se realizaron con la rigurosidad exigible.

Divulgación responsable: cómo gestionó la comunidad de seguridad el hallazgo

Los problemas de seguridad de Lexnet también plantearon cuestiones relevantes sobre la divulgación responsable de vulnerabilidades (responsible disclosure). Este concepto, ampliamente aceptado en la comunidad de ciberseguridad, establece un protocolo para reportar fallos de seguridad que equilibra la protección de los usuarios con la necesidad de dar tiempo al responsable del sistema para corregir el problema.

¿Cómo funciona la divulgación responsable?

El proceso estándar sigue cuatro fases: descubrimiento de la vulnerabilidad, notificación privada al responsable del sistema, concesión de un plazo razonable de corrección (habitualmente entre 30 y 90 días), y publicación de los detalles una vez corregido el fallo para que la comunidad pueda aprender del incidente.

El problema de la divulgación en el sector público español

En 2017, España carecía de un marco formal para la divulgación responsable de vulnerabilidades en sistemas públicos. No existía un canal oficial del Ministerio de Justicia para reportar fallos de seguridad, ni un programa de bug bounty o recompensas por hallazgos. Esta ausencia dificultó la comunicación entre quienes descubrieron los fallos y la Administración, y contribuyó a que la información circulara por canales informales antes de que el Ministerio pudiera reaccionar.

En la actualidad, iniciativas como la del Centro Criptológico Nacional (CCN-CERT) y la transposición de la Directiva NIS 2 han mejorado parcialmente esta situación, estableciendo canales de notificación de incidentes y promoviendo la colaboración entre el sector público y la comunidad de seguridad. No obstante, aún queda camino por recorrer para alcanzar la madurez de otros países europeos en esta materia.

Implicaciones legales: ENS y RGPD

La vulnerabilidad de Lexnet tenía implicaciones jurídicas significativas bajo dos marcos normativos fundamentales: el Esquema Nacional de Seguridad y el Reglamento General de Protección de Datos.

Esquema Nacional de Seguridad (ENS)

El Real Decreto 311/2022 (que actualizó el anterior Real Decreto 3/2010) regula el Esquema Nacional de Seguridad, de obligado cumplimiento para todos los sistemas de información de las Administraciones Públicas españolas. El ENS establece requisitos de seguridad organizados en categorías (BÁSICA, MEDIA, ALTA) según la criticidad del sistema.

Un sistema como Lexnet, que gestiona información judicial con datos especialmente protegidos (categorías especiales del artículo 9 del RGPD, datos de menores, víctimas, etc.), debería clasificarse en la categoría ALTA del ENS, lo que exige controles de acceso robustos [op.acc], gestión de incidentes [op.exp.7], registros de auditoría [op.exp.8] y planes de continuidad del servicio [op.cont].

La vulnerabilidad IDOR de Lexnet suponía un incumplimiento directo de los requisitos de control de acceso del ENS, lo que debería haber activado los mecanismos de supervisión y, en su caso, las consecuencias previstas para los incumplimientos.

Reglamento General de Protección de Datos (RGPD)

El RGPD, aplicable desde el 25 de mayo de 2018, impone obligaciones específicas en caso de brecha de seguridad. Aunque la crisis de Lexnet se produjo en julio de 2017, bajo el régimen actual el Ministerio de Justicia estaría obligado a: notificar a la AEPD en 72 horas (artículo 33), comunicar la brecha a todos los afectados dado el alto riesgo para sus derechos (artículo 34), y disponer de una Evaluación de Impacto en la Protección de Datos previa (artículo 35). Las Administraciones Públicas españolas, aunque no reciben multas económicas bajo la LOPDGDD, sí pueden ser objeto de apercibimiento público y resoluciones declarativas de infracción.

El caso Lexnet demostró que la protección de datos en los sistemas judiciales no puede tratarse como un asunto secundario, sino que debe integrarse desde el diseño (privacidad por diseño, artículo 25 RGPD).

Comparativa con otros sistemas de justicia electrónica en Europa

Para contextualizar los problemas de seguridad de Lexnet, resulta ilustrativo compararla con los sistemas de justicia electrónica de otros países europeos y de la propia Unión Europea.

e-CODEX (Unión Europea)

El proyecto e-CODEX (e-Justice Communication via Online Data Exchange) es la infraestructura de comunicación electrónica transfronteriza de la Unión Europea para el ámbito judicial. e-CODEX no gestiona directamente documentos judiciales, sino que proporciona una capa de interoperabilidad segura entre los sistemas nacionales de los Estados miembros. Su arquitectura de seguridad se basa en:

• Cifrado extremo a extremo de las comunicaciones.
• Firma electrónica cualificada conforme al Reglamento eIDAS.
• Verificación de identidad a través de los esquemas nacionales de identificación electrónica.
• Separación estricta entre autenticación y autorización.

Desde 2023, e-CODEX ha sido asumido por la Agencia de la Unión Europea para la Gestión Operativa de Sistemas Informáticos de Gran Magnitud (eu-LISA), lo que garantiza su mantenimiento y evolución bajo estándares de seguridad homogéneos.

Sistema e-Filing del Tribunal de Justicia de la Unión Europea (TJUE)

El Tribunal de Justicia de la Unión Europea dispone de su propio sistema de presentación electrónica de documentos, conocido como e-Curia. Este sistema implementa:

• Autenticación mediante certificados electrónicos cualificados.
• Control de acceso granular por asunto y parte procesal.
• Registro de auditoría completo de todos los accesos.
• Cifrado de los documentos almacenados.

Una vulnerabilidad de tipo IDOR como la de Lexnet sería conceptualmente imposible en e-Curia, ya que el acceso a cada documento está vinculado criptográficamente a la identidad del usuario y a su rol procesal en el asunto concreto.

beA (Alemania)

El sistema alemán beA (besonderes elektronisches Anwaltspostfach) también experimentó problemas de seguridad en su lanzamiento (diciembre de 2017), incluyendo un certificado raíz privado distribuido junto con el software cliente. La diferencia con el caso español es que las autoridades alemanas reaccionaron con mayor transparencia, reconocieron el problema y publicaron íntegramente los resultados de una auditoría independiente.

Lecciones de la comparativa

La comparación revela que los problemas de seguridad en los sistemas de justicia electrónica no son exclusivos de España, pero que la diferencia reside en la madurez de la respuesta: transparencia, auditorías independientes y rendición de cuentas. En estos aspectos, la gestión de la seguridad de Lexnet quedó por debajo de los estándares europeos.

Estado actual de Lexnet en 2026: ¿ha mejorado la seguridad?

Han transcurrido casi nueve años desde la crisis de 2017, y la pregunta obligada es: ¿ha mejorado la seguridad de Lexnet?

Mejoras implementadas

Tras el incidente de 2017, el Ministerio de Justicia —posteriormente el Ministerio de la Presidencia, Justicia y Relaciones con las Cortes— adoptó diversas medidas:

• Corrección de la vulnerabilidad IDOR: Se implementó la validación de autorización en el lado del servidor, verificando que el usuario solicitante está efectivamente vinculado al procedimiento al que pertenece el documento.
• Auditorías de seguridad: Se han realizado auditorías de seguridad con mayor regularidad, aunque persisten dudas sobre su alcance y la publicación de sus resultados.
• Mejoras en la infraestructura: Se ha actualizado la infraestructura tecnológica del sistema, incluyendo la migración a versiones más recientes de los componentes de software.
• Integración con Cl@ve: La autenticación se ha integrado con el sistema Cl@ve de identificación electrónica de la Administración General del Estado, reforzando los mecanismos de verificación de identidad.

Problemas persistentes

No obstante, Lexnet sigue presentando deficiencias que la comunidad jurídica señala reiteradamente:

• Problemas de disponibilidad: Las caídas del sistema siguen siendo frecuentes, especialmente en periodos de alta demanda (vencimiento de plazos procesales, campañas de notificaciones masivas), lo que obliga al Consejo General del Poder Judicial a ampliar plazos procesales de forma recurrente.
• Interfaz obsoleta: La experiencia de usuario no ha evolucionado al ritmo de las plataformas digitales modernas, lo que dificulta su uso y genera errores operativos.
• Interoperabilidad limitada: La integración con los sistemas de gestión procesal de las Comunidades Autónomas (que tienen competencias transferidas en materia de justicia) sigue siendo deficiente.
• Falta de transparencia en seguridad: No se publican informes de auditoría de seguridad ni existe un programa formal de divulgación responsable de vulnerabilidades.

El contexto de la transformación digital de la Justicia

Lexnet debe analizarse en el contexto más amplio de la transformación digital de la Administración de Justicia impulsada por el plan Justicia 2030. Este plan contempla la modernización integral de los sistemas judiciales, incluyendo el desarrollo de una nueva arquitectura de servicios digitales. Sin embargo, la implementación avanza con lentitud y las inversiones en ciberseguridad judicial siguen siendo insuficientes en comparación con las de otros ámbitos de la Administración electrónica, como la Agencia Tributaria o la Seguridad Social.

¿Qué lecciones deja la vulnerabilidad de Lexnet?

El caso Lexnet ofrece lecciones valiosas para cualquier organización —pública o privada— que desarrolle y mantenga sistemas que gestionan información sensible:

1. La seguridad debe diseñarse desde el inicio (security by design), no añadirse como parche posterior. Un sistema que gestiona documentos judiciales debería haber incorporado controles de acceso robustos desde su primera versión.
2. Autenticación no es lo mismo que autorización. Verificar la identidad de un usuario es necesario pero insuficiente. Es imprescindible verificar también que ese usuario concreto tiene permiso para acceder al recurso concreto que solicita.
3. Las auditorías de seguridad independientes son imprescindibles para cualquier sistema crítico. Las pruebas de penetración habrían detectado la vulnerabilidad IDOR antes de su descubrimiento público.
4. La gestión del incidente es tan importante como la prevención. Una comunicación transparente, la asunción de responsabilidades y un plan de remediación creíble pueden mitigar el daño reputacional. La minimización lo agrava.
5. Los canales de divulgación responsable son esenciales. Si el Ministerio hubiera dispuesto de un canal formal para reportar vulnerabilidades, el incidente podría haberse gestionado de forma controlada antes de convertirse en una crisis pública.

Preguntas frecuentes sobre la seguridad de Lexnet y la vulnerabilidad IDOR

¿Qué es Lexnet y para qué sirve?

Lexnet es la plataforma de justicia electrónica del Ministerio de Justicia de España. Su función principal es permitir la presentación telemática de escritos y documentos ante los órganos judiciales, así como la recepción de notificaciones judiciales por parte de abogados, procuradores, graduados sociales y otros operadores jurídicos. Su uso es obligatorio desde 2016 para la mayoría de los profesionales del ámbito judicial.

¿Qué vulnerabilidad tuvo Lexnet en 2017?

En julio de 2017 se descubrió que Lexnet presentaba una vulnerabilidad de tipo IDOR (Insecure Direct Object Reference) que permitía a cualquier usuario autenticado acceder a documentos judiciales de otros procedimientos con solo modificar el identificador numérico del documento en la URL del navegador. El sistema verificaba la identidad del usuario pero no comprobaba su autorización para acceder al documento solicitado.

¿Qué es una vulnerabilidad IDOR?

Una vulnerabilidad IDOR (Insecure Direct Object Reference) se produce cuando una aplicación web permite acceder a recursos internos (documentos, registros, datos) mediante identificadores que el usuario puede manipular, sin verificar que dicho usuario está autorizado a acceder al recurso solicitado. Es la vulnerabilidad número uno del OWASP Top 10 (dentro de la categoría Broken Access Control) y es relativamente sencilla de detectar y de corregir si se aplican buenas prácticas de desarrollo seguro.

¿Se accedió realmente a documentos judiciales ajenos a través de Lexnet?

El Ministerio de Justicia no proporcionó información detallada sobre si se produjeron accesos efectivos a documentos ajenos explotando la vulnerabilidad. La ausencia de registros de auditoría adecuados —otro fallo de seguridad en sí mismo— dificultó determinar el alcance real de la brecha. Lo que se pudo confirmar es que la vulnerabilidad existía y era explotable sin necesidad de conocimientos técnicos avanzados.

¿Lexnet es seguro en 2026?

Tras la crisis de 2017, el Ministerio de Justicia implementó correcciones para la vulnerabilidad IDOR y ha realizado mejoras en la infraestructura. Sin embargo, Lexnet sigue presentando problemas recurrentes de disponibilidad y no publica informes de auditoría de seguridad independientes que permitan evaluar objetivamente su nivel de protección actual. La comunidad jurídica sigue reportando incidencias de funcionamiento con regularidad.

¿Qué normativa de seguridad debe cumplir Lexnet?

Lexnet debe cumplir con el Esquema Nacional de Seguridad (ENS), regulado por el Real Decreto 311/2022, que establece los principios y requisitos de seguridad para los sistemas de información de las Administraciones Públicas. Además, al tratar datos personales, debe cumplir con el RGPD y la LOPDGDD. Dada la sensibilidad de la información que gestiona, debería clasificarse en la categoría ALTA del ENS.

¿Cómo puedo reportar una vulnerabilidad en un sistema público en España?

En España, el organismo de referencia para la notificación de vulnerabilidades e incidentes de seguridad en el sector público es el CCN-CERT (Centro Criptológico Nacional – Computer Emergency Response Team), dependiente del Centro Nacional de Inteligencia. Puede contactar con ellos a través de su portal ccn-cert.cni.es. Para el sector privado y ciudadanos, el INCIBE-CERT (Instituto Nacional de Ciberseguridad) ofrece un canal de notificación a través de incibe.es.

¿Qué diferencia hay entre autenticación y autorización?

La autenticación verifica la identidad del usuario (que es quien dice ser). La autorización verifica que tiene permiso para la acción solicitada. Un sistema seguro requiere ambos controles. La vulnerabilidad de Lexnet se debía a que existía autenticación pero no autorización a nivel de documento.

Conclusión

La vulnerabilidad IDOR de Lexnet descubierta en 2017 no fue un fallo menor ni un incidente anecdótico: fue la manifestación de una deficiencia estructural en el diseño de seguridad del sistema de justicia electrónica de España. Un fallo que permitía acceder a documentos judiciales confidenciales con la misma facilidad con que se cambia un número en la barra de direcciones del navegador revela la ausencia de controles de seguridad elementales que cualquier auditoría básica habría detectado.

Nueve años después, Lexnet sigue siendo un sistema con margen de mejora significativo. Si bien la vulnerabilidad concreta fue corregida, la transparencia en materia de seguridad, la publicación de auditorías independientes y la madurez en la gestión de incidentes siguen siendo asignaturas pendientes de la justicia electrónica española.

La protección de la información judicial no es solo una cuestión técnica: es un pilar del Estado de Derecho. Los ciudadanos que confían sus asuntos más sensibles al sistema judicial tienen derecho a que esa información se custodie con el máximo nivel de seguridad. La crisis de Lexnet debe servir como recordatorio permanente de que esa seguridad no puede darse por supuesta, sino que debe construirse, verificarse y mantenerse de forma continua.

Si tiene dudas sobre la seguridad de los sistemas electrónicos que utiliza en su práctica profesional o necesita asesoramiento en materia de ciberseguridad y protección de datos, puede contactar con nuestro equipo. Para más análisis sobre derecho tecnológico y seguridad informática, visite nuestra sección de artículos.