Trust Center
Security Overview
A summary of the security controls implemented in Safe For The Office™, written for IT reviewers and security teams completing vendor assessments.
Authentication
Password hashing
scrypt (N=16384, r=8, p=1) — memory-hard, OWASP-compliant
Timing-safe comparison
All password comparisons use constant-time functions to prevent timing attacks
User enumeration protection
Unknown email addresses receive the same response time as known addresses
Brute-force lockout
5 consecutive failures trigger a 15-minute server-side account lockout
Session cookies
HttpOnly, Secure, SameSite=Strict — inaccessible to JavaScript, HTTPS-only, CSRF-resistant
Session expiry
8-hour absolute timeout — no persistent sessions
Password reset tokens
32-byte random tokens, SHA-256 hash stored only, 1-hour expiry, single-use
Authorization and Least Privilege
Role-based access control
Four roles: Facilitator, Read-only, Admin, Super Admin — each with defined permissions
Database-authoritative roles
Role is re-verified against the database on every admin request — a stale session token cannot grant elevated access
Immediate suspension
Suspended accounts are denied on the next request — no waiting for session expiry
Database runtime user
The application uses a limited-permission database user — it cannot modify the database schema
Audit log protection
The application user cannot modify or delete audit log entries — append only
Administrative Controls
Append-only audit log
All administrative actions are recorded with actor identity, action, target, result, and timestamp
Metadata allowlist
Sensitive fields (passwords, tokens, participant data) are filtered before audit log insertion
Last super-admin protection
The platform prevents suspension or deletion of the last remaining super-admin account
Admin pages — no indexing
Administrative pages include X-Robots-Tag: noindex and Cache-Control: no-store headers
Migration and Schema Controls
Forward-only migrations
Database schema changes are applied in order and cannot be reversed by the migration runner
Checksum verification
Each migration file is verified by SHA-256 checksum before application — modified migration files are rejected
Transactional migrations
Each migration runs in a transaction — a failed migration is rolled back automatically
Drift detection
The health endpoint detects when the production schema is behind the deployed application code and blocks deployment
Deployment Security
OIDC authentication
Deployments use short-lived OIDC credentials — no long-term AWS access keys stored in CI/CD
Active sessions gate
Deployments are blocked if a live workshop session is in progress
Post-deploy health gate
Every deployment is automatically rolled back if the application does not pass health validation
Versioned artifacts
Each deployment produces a versioned, immutable artifact — rollback restores the previous artifact
No credentials in code
All secrets are stored in AWS Secrets Manager — no credentials in source code, configuration files, or deployment artifacts
Network Security
TLS enforced
All public connections use HTTPS — HTTP is redirected to HTTPS
Database in private subnet
The database is not accessible from the internet — only from the application server within the same network
Database TLS
The application-to-database connection uses TLS with certificate verification (verify-full)
Responsible Disclosure
If you discover a security vulnerability in Safe For The Office™, please report it responsibly. Contact us using the form below and describe the issue. We will acknowledge your report and work to address confirmed vulnerabilities promptly.
Please do not publicly disclose vulnerabilities before we have had an opportunity to investigate and respond.
Report a security issue →Last reviewed: October 2026