Security

typress's security model is built around one invariant: a single leaked admin password should not bring down the site. Unlike WordPress, capturing an admin session is not enough to do damage — every destructive action re-prompts for the password.

Reauth

These actions all require the password (and TOTP, if enrolled) at the moment of the request:

• Enroll / confirm / disable TOTP
• Enable / disable / install / uninstall a plugin
• Install / uninstall a theme
• Add / revoke a trusted key
• Update site settings
• Create / promote / delete / reset-password a user

With only a stolen cookie, the attacker can browse the admin UI but cannot perform any of these. Every attempt — successful or not — lands in the audit log.

Enabling TOTP

Enrollment lives in the admin Overview tab. Secrets are encrypted at rest with AES-256-GCM, with the per-record key derived via HKDF from the master key (ADR-005). A stolen DB dump can't recover TOTP secrets. Lost-device recovery is via the CLI: typress admin totp-disable <email>.

Audit log

Every login (success and failure), destructive action, plugin start, and theme install is appended to audit_events. The admin UI exposes the log to admin role only — subscribers can't see it.

Plugin sandbox boundary

Plugins run in separate processes and only talk to the host through a Cap'n Web RPC bridge. Only the methods matching the manifest's declared capabilities are exposed; direct DB / filesystem / network access is not even reachable. OS-level containment is the systemd unit's hardening.