Security

Security is not a feature — it's the foundation

Every layer of the platform — from vote storage to session management — is designed with the assumption that data is sensitive and attackers are real.

AES-256-GCM Vote Encryption

The platform uses two deliberate voting models. Candidate and class ballots are secret: each choice is encrypted with AES-256-GCM before being written, using a dedicated key held in the server environment and never in the database, so a database-only compromise does not reveal how anyone voted. Resolution voting — CoC and creditor meetings — is attributable by design, because the voting record must show how each creditor voted; those votes are stored against the voter and reproduced in the report.

OTP Authentication — No Passwords

There are no stored passwords in the system. Authentication is passwordless: a time-limited one-time code is sent to the registered email. OTP codes are hashed with bcrypt before storage and expire after use. Replay attacks are blocked at the database level.

Cryptographic Voting Tokens

Each voter receives a unique 256-bit (32-byte, base64url-encoded) voting token. Tokens are single-use: the status change and the vote are written in one transaction, so a second submission finds the token already spent and is rejected. The same link cannot be used to vote twice.

Rotating JWT + httpOnly Refresh Tokens

Access tokens for signed-in staff are short-lived JWTs (15 min). Refresh tokens are stored as httpOnly cookies — not accessible to JavaScript — and are rotated on every use. Stolen cookies cannot be replayed because the previous token is invalidated the moment a new one is issued.

RBAC Role Enforcement

Every API endpoint is guarded by a JwtAuthGuard + RolesGuard combination, and irreversible election actions — opening, closing, declaring a result, extending a deadline, deletion — are restricted to the Resolution Professional. Data queries are scoped to the authenticated user's organisation, so one firm's data is not reachable from another firm's account.

Immutable Audit Logs

Every significant action — login, OTP verify, nomination submit, vote cast, document upload, result publish — is written to an audit log with timestamp, actor, IP address and user agent. The application never deletes audit entries, and the full log is exportable as PDF.

TLS / HTTPS Everywhere

The platform is served exclusively over HTTPS with a valid SSL certificate managed via Let's Encrypt. HTTP requests are permanently redirected (301) to HTTPS by Nginx. The evoting.variedreach.com domain is the only origin accepted by the API's CORS policy.

Network Isolation

The API container and database are on an internal Docker network not exposed to the internet. Only the Nginx reverse proxy is internet-facing. The database port is never published externally.

Security architecture overview

┌─────────────────────────────────────────────────┐
  │              Internet / Client                  │
  └──────────────────────┬──────────────────────────┘
                         │ HTTPS (TLS 1.2/1.3)
                         ▼
  ┌─────────────────────────────────────────────────┐
  │        Nginx Reverse Proxy (vdr_edge)           │
  │   SSL termination · HTTP→HTTPS redirect         │
  │   CORS: evoting.variedreach.com only            │
  └──────────────────────┬──────────────────────────┘
                         │ Internal Docker network
                         ▼
  ┌─────────────────────────────────────────────────┐
  │           NestJS API (evoting-api)              │
  │  JwtAuthGuard  ─  RolesGuard  ─  orgId scope   │
  │  OTP bcrypt hash  ─  AES-256-GCM vote encrypt  │
  │  Rotating refresh tokens (httpOnly cookie)      │
  │  AuditLog written on every action                │
  └──────────────────────┬──────────────────────────┘
                         │ Internal only (not internet-exposed)
            ┌────────────┴────────────┐
            ▼                         ▼
  ┌──────────────────┐     ┌──────────────────────┐
  │   PostgreSQL DB  │     │     Redis Cache       │
  │  (evoting-db)    │     │  (evoting-redis)      │
  │  Port NOT public │     │  Port NOT public      │
  └──────────────────┘     └──────────────────────┘

Security FAQ

Can anyone see who a homebuyer voted for?

No. Votes are encrypted with AES-256-GCM before storage. Only the vote tallying process — which runs server-side at result declaration — can decrypt them. There is no interface to view individual ballot choices.

What happens if someone shares their voting link?

The link is bound to a single-use cryptographic token. The first person to complete OTP verification and cast a vote will consume the token. Any subsequent attempt to use the same link returns a 'already voted' screen.

Is the platform penetration tested?

The platform is code-reviewed for OWASP Top 10 vulnerabilities as part of development. Formal third-party penetration testing is available for Enterprise clients on request.

Where is data stored?

Data is stored on a dedicated VPS (Hostinger, India datacenter) with PostgreSQL. No data is shared with third-party analytics services. Backups are taken daily.

Is the platform GDPR / PDPB compliant?

The platform collects only the minimum data required (name, flat number, email/mobile) to conduct a legal election. Data retention and deletion policies are configurable per client. Formal DPA/compliance documentation is available for Enterprise.

Found a security issue?

We take security disclosures seriously. Please report vulnerabilities responsibly to our security team. We commit to acknowledging reports within 24 hours and providing a fix timeline within 72 hours for critical issues.

Report a Vulnerability