Security Overview

This document describes the Service's security posture, intended for IT security reviewers, public health inspectors, and customer procurement teams. It is current as of the date above and is updated when material changes occur.

Architecture summary

Pool Operator Logbook is a browser-based progressive web application served as static assets from Netlify's edge CDN. The backend is PostgreSQL hosted on Supabase (Canada Central region). The application communicates with the backend over HTTPS using the Supabase JavaScript SDK and custom session tokens issued by server-side PostgreSQL functions.

Authentication

• Credential storage: PINs are hashed using bcrypt (work factor 10) via PostgreSQL's pgcrypto extension. Plaintext PINs are never stored. The users.pin column has been dropped from the schema.
• PIN policy: 4–8 digits required. The server rejects common weak PINs (all-same-digit, sequential ascending/descending, well-known leaked PINs).
• Forced change: manager-issued PINs are flagged must_change_pin; the operator must replace the PIN on first login before any other action is permitted.
• Rate limiting: 5 failed attempts per minute per user triggers a 1-minute account lockout. Each attempt (success or failure) is logged with timestamp.
• Sessions: 256-bit random tokens issued by verify_pin RPC, 30-minute idle expiry, sliding renewal on activity. Stored client-side in localStorage and transmitted via the X-Session-Token header.
• Session revocation: users can revoke their own other sessions; managers can revoke any operator session in their organization.

Authorization

• Database-level enforcement: PostgreSQL Row-Level Security (RLS) is enforced on every table. The anonymous role has read access only to pool configuration and a public users view (no PIN hashes); all other operations require a valid session token.
• Role tiers: operator can create entries and modify their own within the 24-hour edit window. supervisor and manager can edit any entry with a recorded reason, view the audit log, manage operators, and export organization data.
• Sensitive tables locked: users, sessions, pin_attempts, and audit_log have USING (false) RLS policies — they are accessible only via specific SECURITY DEFINER RPCs that perform additional permission checks.

Data integrity and tamper evidence

• Audit log: append-only. Every INSERT, UPDATE, and DELETE on operational data is captured via PostgreSQL triggers with the full before/after row state as JSONB.
• No-delete enforcement: the anonymous and authenticated roles have REVOKE INSERT, UPDATE, DELETE on the audit log. The log can only be appended via the audit trigger itself.
• 24-hour edit window: operational records are flagged with editable_until = created_at + 24h. Within this window, operators can correct their own entries. After expiry, only managers can edit, and edits include a last_edit_reason field captured in the audit log.
• Operator binding: each operational record carries operator_id and operator_initials. RLS UPDATE policy prevents operators from modifying records attributed to other operators.

Transport and content

• TLS: all connections are HTTPS-only. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload is set, instructing browsers to refuse non-HTTPS access.
• Content Security Policy: restrictive default-src 'self'; connect-src limited to *.supabase.co; frame-ancestors 'none'; base-uri 'self'.
• Other headers: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy blocks geolocation, microphone, camera, payment, USB.
• XSS protection: all user-typed content (handoff notes, chem reasons, equipment notes, meter notes) is HTML-escaped at render time. No eval or Function() constructors are used.

Data residency and backup

• Primary database: Supabase, Canada Central region (Ontario).
• Static assets: Netlify global CDN; no operational data passes through this layer.
• Backups: Supabase performs automated daily backups retained per plan (7 days Pro / 30 days Team), stored in the same region. Point-in-time recovery is available on Team tier.
• Data export: customers can export their entire organization's data at any time as JSON via the admin panel.

Retention

Current state vs commercial-grade roadmap

Incident response

In the event of suspected unauthorized access or data tampering:

1. Operators report to a manager immediately. Managers report to the Service operator.
2. The Service operator revokes all active sessions for the affected organization within 30 minutes of confirmation.
3. Audit log is reviewed to determine the scope of the incident.
4. Affected customer organizations are notified in writing within 72 hours per PIPEDA breach-notification expectations.
5. A written post-incident report is provided to the customer within 14 days.

Reporting a vulnerability

Security researchers are encouraged to report vulnerabilities directly to the Service operator named in your organization's pilot agreement. Good-faith reports are appreciated; we do not pursue legal action against researchers who follow responsible disclosure.

Questions

Direct security questions to your facility manager or the Service operator listed in your pilot agreement.