Resumen

  • La documentación fijada del sistema electoral abierto de LACNIC define una consulta GET autenticada que incorpora en la ruta el correo con el que busca participaciones.
  • El código revisado autentica antes de entregar el informe, pero el identificador llega primero al servidor y puede atravesar proxy, balanceador, telemetría, registros de errores y herramientas de soporte.
  • La revisión no realizó una consulta real ni demuestra qué versión está desplegada, qué se registra, cuánto se conserva o si ocurrió una divulgación.
  • La salida sostenible es trasladar el identificador al contenido de la solicitud o sustituirlo por un identificador opaco efímero, acompañado de un comprobante de minimización verificable.

Una puerta bien cerrada y un nombre en el pasillo

La seguridad de un servicio suele narrarse desde la puerta: llega una credencial, se comprueba el permiso y, solo si el resultado es favorable, se abre el acceso al dato. Ese relato explica quién puede recibir una respuesta. Dice poco sobre las copias de la pregunta que se producen antes de llegar a la puerta.

La lista pública de elecciones de LACNIC enlaza la documentación de su proyecto electoral de código abierto. En el commit examinado, la guía de servicios presenta la ruta electionsParticipationsByEmail/{email}/{pageSize}/{offset}. Es una operación GET paginada. El ejemplo usa una dirección reservada para documentación, y el resultado se describe como una lista de informes de participación electoral asociada a esa dirección, con la elección, el rol y otros datos aplicables.

La implementación Java conserva esa forma. Recibe email como parámetro de ruta, valida el tamaño y el desplazamiento de página, llama al mecanismo común de autenticación y después ejecuta la búsqueda por correo. La guía de seguridad contigua afirma que no hay endpoints REST anónimos en ese bloque. En el modo APP, el acceso general exige un valor de autorización y que la IP de origen figure entre las permitidas. En el modo centralizado se exige el rol api-Elections. Un fallo de autenticación devuelve 401.

Es una defensa real. Reduce el conjunto de personas o sistemas capaces de conocer el contenido de la respuesta. También impide describir este endpoint como si fuera un buscador público sin barreras. Pero no cambia la secuencia material: para decidir si autoriza, la aplicación ya ha recibido una petición cuya ruta contiene el identificador de la persona consultada.

El balanceador puede verlo antes. El proxy inverso necesita procesarlo. El servidor puede escribirlo al registrar un 401. El agente de rendimiento puede adjuntarlo a una traza correcta. El cortafuegos de aplicaciones puede conservarlo en una alerta. Una captura para soporte puede llevarlo más lejos. Ninguna de esas copias necesita el cuerpo de la respuesta para existir.

La imagen correcta, por tanto, no es la de una caja fuerte abierta. Es la de una caja fuerte cerrada cuyo recibo de entrada ya lleva impreso el nombre del asunto. Esa diferencia parece pequeña en el código; en gobernanza define quién termina custodiando un dato personal y durante cuánto tiempo.

Lo que permite afirmar el repositorio

El valor de una revisión de código abierto está en poder delimitar el hecho. El repositorio permite ver el contrato, la implementación de referencia y la documentación de acceso en un mismo punto temporal. La página pública de LACNIC permite comprobar que la organización dirige a sus lectores hacia ese proyecto. El README define el sistema como una herramienta abierta para implementar y operar procesos electorales a distancia.

Nada de ello certifica un despliegue. El commit revisado no identifica necesariamente la versión que atiende una elección concreta. La evidencia no conecta el formulario público de recuperación de enlaces con este servicio, no prueba que el endpoint esté habilitado ni revela la configuración del proxy o de la plataforma de observabilidad. Tampoco dice si un operador normaliza rutas, elimina segmentos dinámicos, restringe registros, cifra archivos, limita accesos o borra rápidamente los datos.

La investigación no envió un correo real, un token ni un identificador de organización. No obtuvo informes de participación. No inspeccionó un registro de acceso, una traza, una etiqueta métrica, una caché, el historial de un navegador o un expediente de soporte. No se observó exposición, daño, incumplimiento ni incidente.

Esta lista de límites no debilita el hallazgo; evita convertir un problema de diseño en una acusación de hechos no medidos. La afirmación admisible es más precisa: el contrato abierto coloca un identificador de clase correo en el URI, y el material público no ofrece una prueba completa de minimización para las capas que copian URI. Un buen contrato reduce la necesidad de confiar en que cada despliegue haga una redacción perfecta.

También hay defensas plausibles. TLS protege la ruta mientras viaja entre extremos cifrados correctamente configurados. Una pasarela interna podría sustituir el identificador. Los productos modernos pueden agrupar la traza por plantilla en vez de registrar valores. La retención puede ser corta y el acceso, excepcional. La pregunta de gobernanza no es si alguna de esas medidas existe en abstracto, sino cuál existe, dónde y con qué prueba repetible.

El URI es una superficie de distribución

Una dirección web parece un simple localizador. Para la operación, es además una pieza de coordinación compartida. El enrutador la usa; el proxy la reescribe; el WAF la examina; la aplicación la etiqueta; el observador la agrupa; el soporte la copia. Por esa condición, un valor colocado en la ruta adquiere más custodios de los que su autor imaginó.

RFC 9110 formula la advertencia sin rodeos: los URI están destinados a compartirse, no a protegerse, y muchos servidores, proxies y agentes de usuario registran o muestran el URI de destino. Incluir allí información sensible o personalmente identificable es imprudente. Cuando un formulario construye el destino con información potencialmente sensible, el estándar indica que POST suele preferirse porque lleva los datos en el contenido, aunque reconoce el costo: se pierde la semántica visible de método seguro y se dificulta el uso normal de caché.

Un correo no es siempre confidencial. Puede figurar públicamente como contacto. Pero en esta ruta no cumple la función de contacto: selecciona a la persona cuya participación electoral se quiere conocer. Unido al nombre del servicio, la hora, el código de respuesta y la identidad del solicitante, el registro describe una acción sobre una persona. Incluso un 401 puede ser relevante porque conserva el intento; un 200 puede serlo porque conserva una consulta autorizada.

La guía de registro de OWASP incluye los correos entre los datos personales cuya captura exige evaluar eliminación, enmascaramiento, saneamiento, hash o cifrado. La guía REST usa las credenciales en URL como ejemplo más severo, porque los servidores web las registran. No debe confundirse un correo con una clave. La analogía útil es la mecánica: poner un dato en el URL crea copias fuera de la lógica que protege la respuesta.

Conviene separar cinco controles. La autenticación identifica al solicitante. La autorización limita lo que puede recibir. TLS reduce la observación en tránsito. La minimización decide qué componentes pueden copiar el identificador. La retención decide cuánto dura cada copia. Celebrar el primero no demuestra los cuatro siguientes.

QUERY reabre una decisión que parecía cerrada

Durante años, un diseñador tenía dos opciones incómodas. GET expresaba correctamente una consulta sin efecto intencional, era idempotente y funcionaba con herramientas conocidas, pero llevaba parámetros al URI. POST permitía colocar el dato en el contenido, aunque describía una lectura con un método asociado a operaciones no seguras y obligaba a tratar la caché con más cuidado.

RFC 10008, publicado en junio de 2026, incorpora el método HTTP QUERY. QUERY conserva propiedades seguras e idempotentes y transporta la consulta en el contenido de la solicitud. Su análisis de seguridad señala precisamente que los URI de solicitud tienen más probabilidad de ser registrados que el contenido.

No es una orden de migración ni una garantía de compatibilidad. El servidor Java, las pasarelas, los clientes, el WAF y las herramientas de prueba pueden no admitir QUERY todavía. Además, el contenido también puede terminar en telemetría si una organización activa capturas indiscriminadas. Una adopción nominal que mueve el correo del path al cuerpo, pero sigue copiando cada cuerpo, cambia el lugar sin reducir la custodia.

POST continúa siendo una alternativa razonable y probablemente más desplegable en muchos entornos. Otra opción es un intercambio en dos pasos: el cliente autenticado entrega el correo una vez en contenido protegido; el servicio devuelve un identificador aleatorio, limitado al solicitante, al propósito y a un plazo corto; las consultas posteriores usan ese identificador opaco. Así se evita que reintentos, métricas y capturas repetidas propaguen el dato original.

La arquitectura correcta no puede decidirse desde fuera. Sí puede exigirse un resultado: que ningún componente conserve el correo simplemente porque era cómodo copiar la ruta.

Del compromiso general al comprobante de minimización

Decir que los registros están protegidos es insuficiente para una interfaz de gobierno. Un registro protegido sigue siendo una copia; puede tener otro responsable, otra retención y otro circuito de exportación. Lo verificable es un comprobante versionado.

Ese comprobante debería identificar servicio y versión, propósito de la consulta, rol del solicitante, clase de identificador y ubicación de transporte: ruta, query string, cabecera, contenido o token opaco. Después debe enumerar los intermediarios autorizados y la transformación aplicada en servidor, proxy, balanceador, WAF, malla, APM, métricas, errores, caché, historial de cliente, soporte y copias de seguridad.

También debería registrar ventanas de conservación, grupos con acceso, comportamiento de caché y referencia, límite de frecuencia, clase de campos devueltos, última prueba, responsable de revisión, excepción y caducidad, además del estado de migración y reversión. Una prueba sintética puede usar un identificador reservado y un token de correlación para seguir la petición sin convertir el correo en el identificador del propio informe.

El hash no debe aparecer como solución automática. Un hash estable y sin secreto de un espacio de correos predecible puede seguir siendo enlazable y susceptible a prueba de diccionario. Algunas capas necesitarán una transformación con clave; otras, un valor efímero; muchas no necesitan recoger nada.

El proyecto abierto facilita este cierre. LACNIC puede cambiar contrato, ejemplos, pruebas y documentación en una revisión pública. Puede declarar obsoleta la ruta anterior, medir su uso sin almacenar el segmento personal y dar a los clientes un plazo definido. Puede ofrecer configuraciones de referencia que registren la plantilla, no el valor. Cada despliegue seguirá teniendo trabajo local, pero el valor seguro dejará de depender de una excepción local.

La cuestión no es si la autenticación funciona. El código revisado muestra que forma parte del flujo. La cuestión es por qué una consulta autorizada necesita dejar el identificador de la persona en todas las capas que entienden un URI. La mejor respuesta es que no lo necesita.

Fuentes