Security at CutFlow

Production environment

• Region: United Kingdom
• Operating system: Ubuntu LTS, with automatic security patching via unattended-upgrades
• Web server: Nginx with HTTP/2 enabled
• Application server: Uvicorn (Python ASGI) managed via systemd
• Database: PostgreSQL
• Process model: Multiple Uvicorn workers behind Nginx for high availability
• Real-time messaging: Redis (for WebSocket session distribution across workers)

Network security

• All traffic served over HTTPS (TLS 1.2 or higher) with certificates from Let's Encrypt, automatically renewed via a systemd timer.
• HTTP requests are redirected to HTTPS at the edge (308 Permanent Redirect).
• HSTS (HTTP Strict Transport Security) is enforced — max-age=31536000; includeSubDomains on the application and API, and max-age=63072000 (2 years) on the marketing site — instructing browsers to never connect over plain HTTP.
• Additional security headers in place: X-Frame-Options: SAMEORIGIN (clickjacking protection), X-Content-Type-Options: nosniff (MIME sniffing protection), and Referrer-Policy: strict-origin-when-cross-origin.
• A host-level firewall (UFW, configured deny-by-default) restricts inbound traffic to only ports 22, 80, and 443. All other ports are blocked at the kernel level, regardless of any application listening locally.
• The PostgreSQL database accepts connections only from the application server on 127.0.0.1. It is not bound to any external network interface, so all database traffic stays within the same machine — there is no remote attack surface.
• SSH access to the production server is restricted to key-based authentication for named administrators. Password authentication and root login are disabled.
• SSH is additionally protected by Fail2ban, which automatically bans IP addresses showing repeated failed authentication attempts.
• The operating system applies Ubuntu security patches automatically via unattended-upgrades, ensuring kernel and package CVEs are remediated within hours of upstream release.

Password storage

• Passwords are hashed using bcrypt with automatic per-password salt generation.
• The bcrypt cost factor (work factor) ensures that brute-force attacks are computationally expensive.
• Plaintext passwords are never stored, logged, or returned in API responses.

Password requirements

• Minimum 10 characters
• Must contain at least one uppercase letter, one lowercase letter, and one number
• Maximum length capped at the bcrypt 72-byte limit

Session tokens

• Access tokens: Short-lived (15 minutes), sent via the Authorization: Bearer HTTP header.
• Refresh tokens: Longer-lived (7 days), stored as HTTP-only cookies with the Secure and SameSite=Lax flags set.
• Refresh tokens are rotated on each use — the old token is invalidated immediately.
• Refresh tokens are stored in the database as SHA-256 hashes (the original token is never persisted).
• Tokens use the HS256 algorithm (HMAC with SHA-256) signed with a 512-bit cryptographically random secret generated at deployment time.
• The signing key is validated at application startup — the production application refuses to start with a default development key.

Login protection

• Login attempts are rate-limited per IP address, with thresholds tuned to block credential stuffing while permitting legitimate retries.
• Failed login responses use timing-safe comparisons to prevent username enumeration via response timing.
• Activity is logged whether the login succeeds or fails.

Account types and access levels

• Workshop staff see only the worker app — they cannot access admin functions, billing, or settings.
• Drivers see only the driver app — they cannot access customer details outside their delivery runs.
• Admins see the full admin interface for their company only.
• Superadmins are CutFlow staff with limited support access (impersonation is logged and audited).

Session invalidation

• Logging out invalidates the refresh token immediately.
• If a user account is deactivated or deleted, their tokens stop working on the next request.
• Password resets invalidate all existing refresh tokens for that user.

Two-factor authentication & SSO

Two-factor authentication (2FA): On the roadmap — no fixed date. We will prioritise based on customer demand. Until 2FA ships, accounts are protected by bcrypt password hashing, 10-character minimum passwords, IP-based rate limiting, Fail2ban, and 15-minute access token expiry.

SSO / SAML: Not currently supported. SSO/SAML support is on the roadmap as the customer base grows. For now, all users authenticate via username + password with bcrypt hashing and rate-limited login.

Encryption in transit

• All connections to CutFlow use TLS 1.2 or higher.
• HTTP requests are redirected to HTTPS automatically.
• HSTS instructs browsers to use HTTPS exclusively for cutflow.co.uk and all subdomains.
• Database traffic does not traverse the network — PostgreSQL is bound to 127.0.0.1 only, so all queries between the application and database stay within the same machine.
• Email sent from CutFlow uses STARTTLS with certificate verification.

Encryption at rest

• OAuth access and refresh tokens for third-party integrations (Xero, Sage, Shopify, WooCommerce, Outlook Calendar) are encrypted at rest using Fernet (AES-128-CBC with HMAC-SHA256 authentication).
• Passwords are stored as bcrypt hashes (one-way, never decryptable).
• Stripe payment information is never stored on CutFlow servers — Stripe handles all card data directly under PCI DSS Level 1 certification.

Application security

• SQL injection: Prevented at the framework level via SQLAlchemy ORM with parameterised queries — no user input is ever interpolated into SQL strings.
• Cross-site scripting (XSS): All API responses are JSON; no user-generated content is rendered as HTML server-side. Email templates use Jinja2 with auto-escaping enabled. On the frontend, the React framework automatically escapes all user-generated content when rendering, providing defence-in-depth against XSS even if a backend bug were to allow malicious input through.
• Cross-site request forgery (CSRF): Refresh cookies use SameSite=Lax. State-changing API endpoints require Bearer tokens that cannot be set by browsers automatically.
• Clickjacking: X-Frame-Options: SAMEORIGIN prevents the application from being embedded in iframes on third-party sites.
• MIME sniffing: X-Content-Type-Options: nosniff prevents browsers from interpreting files as a different content type than declared.
• Path traversal: File uploads use UUID-based filenames; user-supplied filenames are sanitised. Files are stored outside the web root and served through authenticated download endpoints.
• Mass assignment: All API endpoints use Pydantic schemas with explicit field whitelists — clients cannot inject unauthorised fields like is_admin or company_id.
• Open redirects: External redirects are restricted to a configured allowlist.

How isolation works

• Every database table includes a company_id foreign key.
• Every database query is scoped to the requesting user's company_id at the application layer.
• Database unique constraints include company_id, so two companies can have customers, orders, or invoices with the same name without collision.
• Real-time WebSocket events are scoped to a per-company "room" — your team's events never reach another customer's browser.
• Subdomain routing (e.g., acme.cutflow.co.uk vs widgets.cutflow.co.uk) provides an additional layer of separation.
• File uploads are stored in per-company directories on disk, with access controlled by the same company_id checks.

What this means in practice

• A user authenticated to Company A cannot access Company B's data, even by guessing IDs.
• A bug or compromise in Company A's account cannot affect Company B.
• Customer data is never used for product analytics or shared between accounts.

Backup schedule

• Database backups run automatically every night using pg_dump in PostgreSQL custom format.
• File uploads (attachments, logos, signatures) are backed up nightly as compressed tar archives.
• Configuration files are backed up with restricted permissions.

Backup integrity

• Each backup is validated immediately after creation (pg_restore --list for the database, archive integrity check for files).
• Backups are excluded from public web access.
• Failed backups trigger an alert to the operations team.

Offsite replication

• Each nightly backup is replicated to Backblaze B2 (UK/EU region), an independent storage provider, immediately after creation.
• Backups are encrypted at rest on Backblaze B2 using server-side encryption (SSE-B2 with AES-256).
• This protects against both single-point hardware failure and full-site loss — if the production server were destroyed entirely, customer data could be restored from the offsite copy.
• The end-to-end restore procedure has been tested against a real backup file.

Retention

• 30 days of daily backups are retained on the production host and replicated to offsite storage.
• Older backups are automatically rotated out.

Recovery objectives

• Recovery Point Objective (RPO): 24 hours (maximum data loss between backups).
• Recovery Time Objective (RTO): 4 hours, based on tested restore procedures from a verified backup.

Customer-initiated restores: If a customer needs a specific record restored after accidental deletion, contact support and we will recover from the most recent backup that contains the data.

What is logged

• Successful and failed login attempts (with IP address)
• User logout events
• Order creation, modification, and deletion
• Order status changes
• Invoice creation and payment
• Quote creation
• Production operation start and completion
• User creation, modification, and deletion
• Settings changes
• Admin impersonation events (when CutFlow support staff access a customer account)

What is recorded

• Timestamp (UTC)
• Acting user ID and name
• IP address
• Activity type and description
• Affected company ID

Retention

Activity logs are automatically purged after 90 days via a scheduled cleanup job, minimising data exposure beyond the security investigation window. If you require a specific retention or deletion policy under your organisation's data handling rules, contact developer@cutflow.co.uk.

Access

Customer admins can view their own company's activity logs through the admin panel. Activity from other companies is never visible.

Core subprocessors

Optional integrations

Used only if a customer chooses to enable them.

All integrations use industry-standard OAuth 2.0 or signed webhook authentication. Webhook payloads from Stripe, Shopify, WooCommerce, and Xero are verified using HMAC signatures before processing — we never trust unsigned data from third parties.

Subprocessor changes: We will notify customers in advance if we add a new subprocessor that handles their data.

Data export

Customers can request a complete export of their data at any time by contacting developer@cutflow.co.uk. The export is provided in machine-readable formats (CSV, JSON) within 14 working days of the request.

Data deletion

When a customer cancels their subscription:

• Active customer data remains accessible during a 30-day grace period for export
• After 30 days, customer data is permanently deleted from production systems
• Customer data in backups is automatically removed when the backup ages out (within 30 days of backup deletion)
• Anonymised aggregate metrics (e.g., total orders processed across the platform) may be retained for product analytics

User account deletion

Individual users can have their accounts deleted by their company admin. The account is removed from active systems immediately, with their data references in audit logs anonymised within 90 days when log retention rolls over.

UK GDPR rights

• Right of access: Request a copy of personal data we hold about you
• Right to rectification: Correct inaccurate or incomplete personal data
• Right to erasure: Request deletion of personal data ("right to be forgotten")
• Right to data portability: Receive your data in a structured, machine-readable format
• Right to object: Object to processing of personal data
• Right to restrict processing: Request that processing of your data is limited

To exercise any of these rights, contact developer@cutflow.co.uk. We will respond within 30 days as required by UK GDPR.

UK GDPR & Data Protection Act 2018

CutFlow is operated in alignment with UK GDPR and the Data Protection Act 2018. Our data handling practices implement the principles of data minimisation, purpose limitation, and storage limitation.

Data Processing Agreement (DPA)

A standard Data Processing Agreement based on the UK ICO's controller-processor template clauses is available for customers who require one. Contact developer@cutflow.co.uk to request a copy.

PCI DSS

CutFlow does not store, process, or transmit credit card data. All payment processing is handled by Stripe, which is PCI DSS Level 1 certified.

Certifications in progress

CutFlow is a young company and has not yet pursued formal certifications such as SOC 2 or ISO 27001. We will publish updates on this page if and when those certifications are obtained.

Please report it to developer@cutflow.co.uk. We commit to:

• Acknowledging your report within 2 working days
• Providing an initial assessment within 5 working days
• Working with you to verify and reproduce the issue
• Keeping you informed of progress toward a fix
• Crediting researchers who report responsibly disclosed vulnerabilities (with permission)

Please do not

• Publicly disclose the vulnerability before we have had a reasonable opportunity to fix it
• Test on customer data you do not own
• Use automated scanners that generate excessive load on our infrastructure

We do not currently offer monetary rewards (bug bounty), but we will publicly thank researchers who report meaningful issues.

Code security & testing

• Every code change is automatically tested before deployment via a CI/CD pipeline (GitHub Actions).
• The pipeline runs the full backend test suite (2,600+ tests), the full frontend test suite (600+ tests), and a clean production build.
• Deployments are blocked if any test fails — no untested code reaches production.
• A local pre-push Git hook runs the same tests before code can even reach the repository, providing two independent gates against regressions.
• Dependencies are tracked, and security advisories are monitored via automated tooling.
• Critical security patches are applied promptly (typically within 7 days for high-severity issues).

Automated security patching

• Operating system security patches are applied automatically via Ubuntu's unattended-upgrades.
• Kernel and package CVEs are remediated within hours of upstream release without manual intervention.
• The system reboots into the latest kernel during scheduled maintenance windows.

Deployment process

• Deployments only proceed after the CI/CD pipeline reports all tests passing.
• Each deployment creates a Git rollback point that can be restored if issues are detected.
• Database migrations are run as part of every deploy.
• A health check verifies the application is responding before deploys are considered complete.

Access control

• Production server access is limited to named administrators with SSH keys (password authentication and root login are disabled).
• SSH is additionally protected by Fail2ban with automatic IP banning on repeated failures.
• A host firewall (UFW) blocks all ports except 22, 80, and 443 at the kernel level.
• The PostgreSQL database is bound to 127.0.0.1 only — no network connections accepted.
• Environment secrets (API keys, signing keys) are stored in restricted-permission .env files outside the web root.
• The signing key used for JWT tokens is validated at startup — the application refuses to start in production with a default development key.

Monitoring & detection

• Application errors and unhandled exceptions are reported to Sentry in real time, with alerts on new error types — incidents are typically detected and triaged before customers report them.
• Failed login attempts are logged and rate-limited per IP address.
• Webhook delivery failures are logged for investigation.
• Anomalous activity (e.g., spikes in 4xx/5xx responses, repeated rate-limit hits from the same IP) surfaces in Sentry alerts.

Incident response

If we detect or are notified of a security incident affecting customer data, we will:

1. Contain the issue within 24 hours of confirmation.
2. Notify affected customers within 72 hours of confirmation (in line with UK GDPR requirements).
3. Provide a written post-incident report describing what happened, what data was affected, and what we have changed to prevent recurrence.

All security incidents are logged internally and reviewed in a structured post-mortem process.