Summary

  • LACNIC's pinned open-source election guide documents an authenticated GET lookup whose request path contains the email used to find a person's election participations.
  • The reviewed implementation authenticates before it returns the report, but authentication does not remove the identifier from a URI that servers, proxies, monitoring systems and support tools may record.
  • No production deployment, logging configuration, real request, disclosure or harm was observed. TLS, access controls and local redaction can materially narrow the exposure surface.
  • LACNIC should move the identifier into request content or exchange it for a short-lived opaque handle, then publish a minimization receipt covering every layer that can copy the request target.

The name is outside the locked room

An access-control diagram usually draws a gate before the protected data. The client presents a credential; the service decides whether the caller may proceed; only then does the database return an answer. That picture is accurate as far as it goes. It is also incomplete when the question itself is written on the envelope.

LACNIC's public election page links to documentation for its open-source election project. At the reviewed commit, the services guide describes a paginated GET endpoint called electionsParticipationsByEmail/{email}/{pageSize}/{offset}. Its worked example places a reserved example-domain address directly into that path. The response is described as a list of election-participation reports associated with the supplied address, including the election, role and related information where applicable.

The Java implementation matches the guide. It binds email as a path parameter, checks the pagination inputs, invokes the common authentication routine and then calls the participation lookup. The adjacent security guide says the REST block has no anonymous endpoints. In one documented mode, callers need both an authorization token and an allowed source address; in the centralized mode, the general service requires the api-Elections role. Failed authentication produces a 401 response.

Those controls are not decorative. They sharply change who can obtain the answer. Any fair account must start there: the reviewed route is not an unauthenticated public directory, and the evidence does not show that a stranger can enumerate participation records.

But the authentication decision happens after the server has received the request target. The email has already crossed the components that terminate TLS, route the request, calculate metrics, capture errors or preserve traces. A system can deny the response perfectly and still copy the rejected request's URI into an access log. It can authorize the response correctly and still retain the successful request's URI for longer than it retains the answer. Response control and identifier placement are related security decisions, not the same decision.

That is the awkward detail in the open-source interface: the locked room may be sound, while the visitor's name is printed on the corridor receipt.

What the evidence does, and does not, establish

The public repository is unusually valuable because it permits a precise review of a contract rather than speculation about a black box. It also demands restraint. A source tree is not a production attestation.

The reviewed commit establishes the documented route shape, the path binding in the reference implementation and the documented authentication modes. The public election list establishes that LACNIC points readers toward this project and its system documentation. The repository describes software for implementing and operating remote election processes. Together, these sources make the design relevant to LACNIC's public operating surface.

They do not establish which commit is deployed, whether this endpoint is enabled, whether a public form calls it, how a reverse proxy is configured, which fields an APM product captures, how long logs are retained or who can read them. No participant address, token or organization identifier was submitted for this review. No response, access log, trace, metric label, cache record, browser history, support export, disclosure, compromise or legal violation was observed.

There may be strong protections outside the repository. TLS can prevent intermediaries outside properly configured encrypted hops from seeing the request target. Operators may log only route templates, hash or mask path segments, restrict log access, suppress successful requests, shorten retention or disable the endpoint. An internal gateway may replace the external identifier before the Java service sees it. Each would materially narrow the risk.

The article therefore makes a bounded claim: a public interface contract places an email-class identifier in the request URI, while the available deployment evidence does not prove that every possible copy is minimized. That is enough to ask for a better contract. It is not enough to announce a leak.

Authentication controls the answer; observability copies the question

HTTP infrastructure treats a request target as operational material. A reverse proxy needs it to route. A server may log it to diagnose failures. A monitoring agent may group transactions by it. A web application firewall may retain it for investigation. An error tracker may attach it to an exception. A load balancer, service mesh, support screenshot or browser history can create another copy. Some products normalize dynamic segments; some do not. Some redact query strings while leaving paths untouched. Controls vary because the URI is normally assumed to identify the resource being requested.

RFC 9110 makes the general principle explicit. URIs are designed to be shared rather than secured, it says, and servers, proxies and user agents commonly log or display the target URI. It advises against including sensitive or personally identifiable information there. When a form would construct a URI from potentially sensitive input, the standard notes that POST is often preferred because the data travels in request content. It also states the trade-off: POST gives up safe-method semantics and can complicate caching.

Email is not a secret in every context. It can be printed on a website or used as a public contact address. In an election-participation lookup, however, it is a subject selector. The combination of identifier, service name, time, status code and caller context can reveal that someone or some system asked about a person's participation. Even when the response remains inaccessible, the request record can have operational and privacy significance.

OWASP's logging guidance accordingly lists email addresses among personal data that may require de-identification and recommends considering removal, masking, sanitization, hashing or encryption. Its REST guidance gives the sharper warning that credentials should not appear in URLs because web servers record them. That credential example is an analogy, not an equivalence: an email address is not an API key. The transferable lesson is about uncontrolled copies at the URL boundary.

This is why adding authentication cannot finish the analysis. Authentication answers whether the caller may receive a participation report. Authorization may further determine which records or fields the caller can see. TLS protects the request between encrypted endpoints. Logging policy governs which copies are made. Retention policy governs how long those copies remain. Support and incident workflows govern where they travel later. A defensible system treats these as separate layers and produces evidence for each.

A newer method clarifies the old compromise

For years, designers faced an inelegant choice. GET expressed a safe, idempotent lookup and worked naturally with caches and familiar tooling, but put user input into the URI. POST moved the input into content but described a query with a method normally associated with unsafe processing. Many systems sensibly chose POST anyway; others accepted the URI and depended on disciplined redaction.

RFC 10008, published in June 2026, standardizes the HTTP QUERY method. QUERY is safe and idempotent while carrying the query in request content. Its security discussion names the exact observability issue: request URIs are more likely to be logged than request content. The method creates a standards-based option for APIs that want query semantics without making the input part of the target URI.

QUERY is not a magic retrofit. Frameworks, gateways, clients, WAF rules and monitoring products may need upgrades. Request content can still be logged, traced or copied. Cache behavior requires deliberate handling. Some deployments will find a conventional POST easier to ship and govern. The relevant point is that the design space is no longer limited to “email in GET path” or “pretend the lookup is a state-changing operation.”

A third design can be better when many components must cooperate: exchange the email for a short-lived opaque handle. An authenticated client submits the identifier once in protected content; the service returns a random handle scoped to that caller, purpose and brief lifetime; subsequent requests use the handle. That does not erase the first request, but it prevents the subject identifier from propagating through every later route, retry, metric and support capture. It also creates a natural place to impose expiry and replay limits.

The choice among QUERY, POST and an opaque handle should be driven by deployability and observed copy paths, not method fashion. All three can fail if request bodies are indiscriminately captured. All three can outperform the current route when accompanied by explicit minimization.

The missing deliverable is a minimization receipt

Code review can identify the route. It cannot prove how every deployment handles it. That gap is best closed with a versioned receipt rather than a general assurance that logs are “secure.”

For this interface, a useful minimization receipt would record the service and version; lookup purpose; authorized caller role; identifier class; whether the identifier travels in path, query, header, content or an opaque handle; which intermediaries are permitted to see it; and the rule applied at each observability layer. The layer list should include the application server, reverse proxy, load balancer, WAF, service mesh, APM agent, metrics pipeline, error tracker, cache, browser-facing history, support export and backup.

The receipt would also state retention windows, access groups, cache and referrer behavior, rate-limit class, response-field class, last verification date, review owner, approved exceptions and expiry dates. It would name the migration and rollback state. It would use a correlation token rather than the raw email, allowing a reviewer to prove that the same test moved through the layers without publishing or replicating the subject identifier.

This is not a demand to expose operational secrets. The public portion can say which controls exist and when they were tested; restricted evidence can contain configurations and sample traces. Nor should the receipt claim that hashing automatically anonymizes an address. A stable unsalted hash of a guessable email space can remain linkable and vulnerable to guessing. Minimization may require truncation, keyed transformation, ephemeral correlation or no collection at all, depending on the layer's purpose.

The receipt changes the governance question from “do we think our logs are careful?” to “which component needs the raw subject identifier, for how long, under whose exception?” Most components will have no good answer. That is useful information.

Open source should make the fix easier to verify

The design appears in a public repository, which gives LACNIC an unusually clean route to resolution. A route change can be reviewed as a contract change. Migration notes can identify compatibility behavior. Tests can assert that raw email never appears in the request target. Example logging configurations can normalize the route and suppress subject identifiers. Security documentation can enumerate the expected observability boundary.

Open source also makes overclaiming easier, because a visible line of code can be mistaken for a production fact. The proper benefit is different: maintainers and deployers can share a verifiable minimum while preserving local choices. The repository can establish that the safe default no longer emits a subject identifier in a URI; each deployment can attest how it handles request content and older routes.

A transition need not be abrupt. LACNIC could introduce a content-bearing endpoint, mark the path form deprecated, emit a non-identifying warning to authenticated clients and measure usage without retaining the email segment. Old clients could receive a documented sunset window. The rollback plan could restore functional access without restoring raw-identifier logging. Compatibility is a real constraint, but it is not a reason to preserve an avoidable data path indefinitely.

The most important editorial discipline is to keep the control proposal proportionate to the evidence. There is no basis here for naming affected people, counting exposed records or grading LACNIC's production logging. There is a basis for saying that the open contract asks infrastructure to carry an identifier in the field infrastructure most naturally copies. A mature election service should not require every deployer to rediscover that mistake and redact it perfectly.

Sources