How we protect your data

Encryption

• In transit: all traffic is served over HTTPS and forced to TLS, with HTTP Strict Transport Security (HSTS) and secure, signed cookies.
• At rest: sensitive fields such as connected-app credentials and integration tokens are encrypted at the application layer (ActiveRecord::Encryption, AES-256-GCM) with keys held outside the database, so a database copy alone does not expose them.
• Content Security Policy: a Content Security Policy restricts which scripts and resources the browser will load, reducing the blast radius of cross-site-scripting attempts.

Tenant isolation

Every account's data is scoped to that account. Application queries are constrained to the signed-in account, so one customer cannot read another customer's contacts, lists, or campaigns.

Authentication & access

Passwords are hashed with bcrypt and never stored in plain text. We also support passwordless magic-link sign-in.

• Strong passwords: new passwords are checked for minimum strength and screened against known-breached-password corpuses (Have I Been Pwned’s k-anonymity range API, so the full password is never sent) and rejected if compromised.
• Account lockout: repeated failed sign-in attempts temporarily lock the account to blunt credential-stuffing and brute-force attacks.
• Bot protection: public forms are defended with Cloudflare Turnstile plus a honeypot and timing checks, and traffic is rate-limited at the network edge (Rack::Attack) and per API client.

Honest gap: account-level multi-factor authentication (2FA) is on our roadmap but is not yet available.

Webhook & input integrity

When you connect One Click Politics to your own systems, we protect both directions of the integration:

• Signed outbound webhooks: every webhook we deliver is signed with a per-subscription secret using HMAC-SHA256 over a timestamped payload (an X-Capitol-Signature: t=<timestamp>,v1=<hmac> header). Verify it on your end so you can confirm the request really came from us and reject replays. Each delivery also carries an idempotency key so duplicates are detectable.
• SSRF protection: any customer-supplied URL we fetch or post to — webhook targets included — is validated against a deny-list of loopback, link-local, cloud-metadata (169.254.169.254), and private (RFC 1918) address ranges, and non-HTTP(S) schemes are refused. We re-validate on every request, not just at save time, so a target cannot be re-pointed at an internal address after the fact.

Verifying a signature: recompute HMAC-SHA256(secret, "<timestamp>.<raw-body>"), compare it to the v1 value with a constant-time comparison, and reject requests whose timestamp is too old to guard against replay.

Compliance & your rights

Our communications and data flows are built to meet the rules that govern political and commercial outreach:

• CAN-SPAM: every email includes one-click unsubscribe (RFC 8058 List-Unsubscribe-Post) and honors a delivery suppression list.
• TCPA: SMS records consent and honors STOP / HELP keywords automatically.
• GDPR & CCPA: you can exercise data access and erasure rights through our data-rights request flow.

Subprocessors

We use a small set of vetted vendors to deliver the service. Each one, what it does, and the data shared with it is listed on our subprocessors page. We do not sell personal data.

Where our legislative data comes from

Our bill, vote, and legislator data is collected directly from official government sources — each state’s own legislature, Congress.gov, and the Federal Register — not resold from a data broker. That gives you a clean, auditable provenance for every record.