Security

Your farm records — cow health, employee pay, financial transactions — are some of your most sensitive business data. Here's exactly how we protect it.

1. At a glance

2. Encryption

In transit

All traffic between your browser and FarmFlow is encrypted with TLS 1.2 or newer using certificates issued by Let's Encrypt. We send the Strict-Transport-Security response header with a two-year max-age and includeSubDomains; preload, and we have submitted the farmflow.co.nz domain to the Chrome HSTS preload list so browsers refuse plain-HTTP connections to any FarmFlow subdomain.

At rest

Data is stored in PostgreSQL on Railway's managed infrastructure. Railway encrypts disk storage at the platform level. Backups inherit that encryption. We are evaluating an additional application-level encryption layer for the most sensitive fields.

3. Account & authentication security

• Password hashing: all passwords are hashed with scrypt (salted, intentionally slow). We never store, log, or transmit your password in plain text. We cannot recover a forgotten password — only reset it.
• Account lockout: after 5 failed login attempts your account is locked for 15 minutes. Each attempt is logged.
• IP rate limiting: beyond per-account lockout, we rate-limit login attempts to 30 per minute per source IP. This blocks distributed credential-stuffing attacks that rotate the email being tried.
• Signed time-limited tokens for email verification (24 hour expiry) and password reset (1 hour expiry).
• Session invalidation on password change: changing your password automatically signs out every other device.
• Suspicious login alerts: when you log in from a country you have never used before, the farm owner receives an email detailing the IP, location, and user agent.
• Session cookies are marked HttpOnly (not readable by JavaScript), Secure (HTTPS only), and SameSite=Lax (CSRF defense).
• CSRF protection on every state-changing request using a per-session token compared in constant time.
• Two-factor authentication is on the roadmap (see section 12).

4. Multi-tenant isolation

FarmFlow is a multi-tenant system — many farms share the same underlying database. We isolate them with a defence-in-depth approach:

• Every database query that reads or writes farm-scoped data is filtered by your active farm's identifier. We use a single helper function for this pattern that is called more than 300 times across the codebase, so the isolation is consistent rather than ad-hoc.
• Cross-farm access is impossible through normal application use — your session can only see the farm or farms you own or have been explicitly invited to.
• The restore engine that lets a super-administrator move a farm's backup into another farm performs explicit identifier remapping to prevent cross-farm references from surviving the restore.
• Database-layer Row-Level Security (RLS) policies are on the roadmap as an additional safety net for the most sensitive tables.

5. Backups & recovery

Per-farm daily backups

Every day at 02:00 NZ time, FarmFlow snapshots every active farm's data into a separate backup table inside the same database. We retain up to 30 snapshots per farm; the oldest are automatically pruned.

One-click restore + safety snapshot

Owners and super-administrators can restore from any stored snapshot through the Settings UI. Before any restore actually changes data, the current state of the target farm is automatically saved as a pre-restore snapshot so the operation is reversible.

Manual export

You can download a complete JSON backup of your farm at any time from Settings → Backup. The download includes every farm-scoped record, including the four cow and employee child tables that some early-stage backup tools skip.

Database-platform backups

Railway's managed PostgreSQL takes its own automated backups at the platform level, providing an additional recovery option independent of the application-level backups above.

6. Audit logging

FarmFlow keeps a detailed audit log of significant administrative actions. The log captures more than 21 distinct event types, including:

• Backup creation, listing, verification, and restoration
• Farm trash, restore, and permanent destruction
• Permission and role changes
• Successful and failed restore attempts (including the reason a restore was blocked — bad password, name mismatch, cross-farm flag missing)

Login events are stored separately with IP, approximate location, and user-agent string, and are used to detect logins from new countries.

7. Browser security headers

Every HTTP response sent by both farmflow.co.nz and app.farmflow.co.nz includes the following headers, configured in defence-in-depth:

8. Rate limiting & abuse protection

The following endpoints are rate-limited per source IP using a database-backed bucket store that survives application restarts and works across replicas:

File-upload endpoints (CSV imports, backup uploads) each cap individual uploads to a size appropriate for the format (5 MB for CSVs, 10 MB for Excel imports, 25 MB for backup JSON files).

The system refuses to start in production with the default cryptographic signing key, preventing accidental key reuse across environments.

9. Hosting & infrastructure

FarmFlow runs on these providers. Each has been chosen for security posture as well as cost and reliability:

All passwords and secrets used by the application are stored in Railway's encrypted environment variable store, never committed to source code.

10. Reporting vulnerabilities

We take all security reports seriously. If you believe you have found a vulnerability in FarmFlow, please email us at security@farmflow.co.nz with the subject line "Security vulnerability report".

Please include:

• A clear description of the issue
• Steps to reproduce
• The potential impact
• Any proof-of-concept code or screenshots

We commit to:

• Acknowledging your report within 3 business days
• Providing a remediation timeline within 14 days
• Crediting you publicly (with your permission) when the fix ships
• Not pursuing legal action against good-faith researchers

Please do not publicly disclose the issue until we have had a reasonable opportunity to fix it.

11. Incident response

In the unlikely event of a security incident affecting your data:

• We will notify you without unreasonable delay.
• If the incident is a notifiable privacy breach under the NZ Privacy Act 2020 (one likely to cause you serious harm), we will notify the Office of the Privacy Commissioner within 72 hours of becoming aware of it.
• We will publish a post-incident summary describing what happened, what was affected, what we did about it, and what we are doing to prevent recurrence.

12. Security roadmap

Active or near-term improvements (listed publicly so you can hold us accountable):

• Application-level error tracking via Sentry, including silent-error sweep
• Continuous integration that runs the full automated test suite on every push
• External uptime monitoring with multi-region health checks
• Two-factor authentication (TOTP) for super-administrator accounts
• Row-Level Security policies at the database layer on the most sensitive tables
• Tightening Content-Security-Policy from 'unsafe-inline' to per-request nonces
• Off-platform backup replication for disaster recovery beyond the Railway account boundary
• An external penetration test by a New Zealand security firm before significant user growth