Security statement

Formixx is a Shopify app handling Cash-on-Delivery order data and customer phone numbers. This page summarizes the technical and organizational measures we take to protect that data. It complements our Privacy Policy and DPA.

1. Transport security

• Public endpoints fronted by Cloudflare in Full (Strict) mode — browser ↔ CF uses CF edge cert; CF ↔ origin uses a signed TLS cert.
• Minimum TLS 1.2 enforced at the Cloudflare edge.
• HTTP Strict Transport Security (HSTS) with max-age=31536000; includeSubDomains on api.formixx.store.
• All inter-service traffic (Next.js ↔ Fastify, Fastify ↔ Postgres/Redis) is private or TLS-terminated.

2. Application security

• HMAC-verified webhooks. Every Shopify webhook is SHA-256 verified before any DB write. Mismatches return 401 and are logged.
• CSRF-protected OAuth. Shopify OAuth install uses a signed state token with a 10-minute validity window.
• Session cookies are HttpOnly, Secure, SameSite=Lax, and rotated every 30 days.
• Session tokens stored as SHA-256 hashes in Postgres — a DB compromise alone cannot replay sessions.
• Magic-link tokens stored as hashes too, 20-minute expiry, one-shot consumption.
• Role-based access control (OWNER / OPS / VIEWER) enforced server-side on every mutating endpoint.
• Input validation via Zod at every API boundary.

3. Data at rest

• Postgres runs in a private Docker network; only the Fastify app container has access.
• Database backups are encrypted at rest by Hostinger.
• Shopify access tokens are stored in plaintext but accessible only by the app service role. No public exposure.

4. Network & infrastructure

• Production VPS firewall allows inbound 443 only from Cloudflare IPs (nginx allow/deny directive) and SSH from our ops network.
• No management plane (Redis, Postgres) is exposed to the public internet.
• Secrets live in /etc/formixx-cod/.env, mode 0600, owned by root, never in the repo.

5. Third-party security

Our sub-processors (Shopify, Cloudflare, Vercel, Resend, Meta, Robocall.pk) each maintain their own security posture. We review their breach-notification terms at onboarding. See the full list in our DPA.

6. Monitoring & alerting

• Structured logs from Fastify (Pino), retained 90 days.
• Health check at api.formixx.store/health, polled by deploy.yml + external uptime monitor.
• Dashboard alert cron (every 10 minutes) flags: balance low, webhook stalled, token expiring, queue backed up. Alerts surface as dashboard banners and daily email digest.

7. Deployment & CI/CD

• Every push to main runs typecheck, lint, format-check, and unit tests (GitHub Actions).
• Deploys are health-gated: if the new container fails to respond at /health within 60 seconds, we automatically roll back to the previous commit.
• No direct SSH changes to production source; all deploys flow through Git → CI → VPS.

8. Principle of least privilege

• Engineering team: individual SSH keys (password login being phased out); audit log on all shell sessions.
• Shopify OAuth scopes: only read_orders and write_orders. We do not request broader scopes.
• Merchant dashboard roles enforce read-only for VIEWER; OPS cannot change billing; only OWNER can invite, demote, or remove team members.

9. Incident response

In the event of a breach, we follow a documented incident-response runbook: contain within 1 hour, assess within 24 hours, notify affected controllers within 72 hours (per GDPR Art. 33), and publish a postmortem within 30 days. Root-cause analysis is mandatory.

10. Responsible disclosure

If you believe you’ve found a security vulnerability, please email security@zensbot.com. We respond within 72 hours, will never pursue legal action against good-faith research, and acknowledge reporters publicly (if desired) after fixes are shipped.

11. Certifications and attestations

Formixx is v0 — we do not yet hold SOC 2 Type II or ISO 27001 certifications. We aim to pursue these in 2026 Q4 after crossing the relevant traffic + headcount thresholds.