# Securing a national postal-voting frontend

*Jun 15, 2026 · application-security, frontend, case-notes*

> Notes on the application-security decisions behind voter-facing apps that handle regulated identity data.

A voter-facing application is the part of an election system that strangers are invited to touch. That framing decided most of our early choices: the frontend is not a thin shell over an API, it is an attack surface that has to assume hostile, regulated, and audited conditions from the first commit.

These are working notes on the decisions that mattered while building the postal-voting and prisoner-voting portals — written for engineers who will have to defend similar systems.

## Threat model before features

We wrote the threat model before the component library. Identity data flows through national systems (NID), so the question was never "what can this screen do" but "what can this screen leak, and to whom". Every form that touched identity was treated as a boundary, not a convenience.

Concretely: no sensitive identifier was ever held in client state longer than a single submission, tokens were short-lived and scoped per role (public, Returning Officer, admin), and the prisoner-voting flow was isolated from the public portal entirely rather than gated behind a flag.

## Encryption at the boundary

Postal votes are received encrypted at the Returning Officer portal; the client's job is to never be the weakest link in that chain. We kept cryptographic operations server-side and treated the browser as an untrusted courier — it transports ciphertext and proves identity, it does not hold keys.

Trusted key-data synchronisation — the constituency mapping that decides which ballot a voter even sees — was the part we audited hardest. A wrong mapping is not a bug, it is a disenfranchisement, so it shipped behind reconciliation with EC officials rather than as a derived client computation.

## What I would keep

Two practices earned their place. First, a single source of truth for content and config, validated in CI, so claims on a screen cannot silently drift from what was reviewed. Second, designing every voter-facing route to be legible to an auditor at a glance — the same discipline that makes a page trustworthy to a person makes it trustworthy to a machine reading it later.