Notifications
Clear all
Topic starter
21/08/2026 4:53 pm
TL;DR: Online voting systems can be manipulated through cookie resets, IP changes, email and phone aliasing, vote-weight tampering, type-casting tricks, and race conditions, according to INTIGRITI. The pattern shows that fairness depends as much on state handling and normalization as on authentication, which means integrity controls must be tested like security controls.
NHIMG editorial — based on content published by INTIGRITI: A hackers’ guide to online voting systems
Questions worth separating out
Q: What breaks when online voting systems rely on cookies or IP addresses to prevent repeat votes?
A: Those checks are easy to reset or route around, so they stop casual repeat voting but not determined abuse.
Q: Why do authenticated polls still need integrity controls beyond login?
A: Login proves who started the session, not whether the vote payload was manipulated after authentication.
Q: How do type-casting flaws create duplicate voting risk?
A: If the application compares one representation of an item during validation but stores another after conversion, the same vote can appear different enough to pass checks twice.
Practitioner guidance
- Harden vote submission as a server-side transaction Move uniqueness checks, vote counting, and persistence into one atomic server-side transaction so the application cannot validate one state and store another.
- Canonicalise every vote input before policy checks Normalize item identifiers, vote counts, and user claims before any duplicate or eligibility comparison so alternate encodings cannot bypass the rule.
- Replace weak uniqueness signals with abuse-resistant identity binding Use stronger account assurance, session binding, or verified participation controls instead of relying on cookies, IPs, or easily aliased email addresses.
What's in the full article
INTIGRITI's full blog post covers the attack primitives and request examples this post intentionally leaves at the analytical level:
- Concrete request payload examples for vote-weight manipulation and vote-quantity bypasses
- Detailed demonstrations of cookie, IP, email, and phone aliasing techniques used to repeat votes
- Type-casting edge cases and normalization pitfalls that let duplicate votes pass validation
- Race-condition reasoning for when concurrent requests beat duplicate-check logic
👉 Read INTIGRITI's analysis of online voting manipulation techniques →
Online voting manipulation: what integrity controls are missing?
Explore further
21/08/2026 5:11 pm
Identity proof is not the same as integrity assurance: this article shows why systems that only identify a voter still fail if they cannot preserve state correctly. Cookies, IPs, and email aliases tell you that a request came from somewhere plausible, not that the vote is unique or final. For identity and trust teams, the practical lesson is to separate authentication from abuse resistance and to design both explicitly.
A question worth separating out:
Q: How should teams respond when a voting system shows signs of race-condition abuse?
A: Treat it as a transaction-integrity problem and lock down the decision path immediately. Move validation and write operations into one atomic server-side process, temporarily rate-limit suspicious repeat submissions, and review logs for simultaneous requests from the same account or session. The goal is to stop multiple commits before they land.
👉 Read our full editorial: Online voting manipulation shows where integrity controls fail
