Security Model

This page describes what Brivacia protects against, how, and what remains your responsibility as a self-hosted admin.

Authentication

• The admin account is local, no third-party login provider.
• Sessions use a signed cookie (HMAC), not PHP's default session mechanism.
• Repeated failed login attempts are tracked per truncated IP and trigger a temporary lockout, to slow down brute-force attempts.
• Two-factor authentication (TOTP) is available and recommended. It works with any standard authenticator app (Google Authenticator, 1Password, Proton Pass, Aegis, Ente Auth, etc.). Backup codes are generated on activation in case you lose access to your authenticator.

Cross-Site Request Forgery (CSRF)

• Every state-changing admin action (settings, import, update, etc.) requires a CSRF token derived from the signed admin cookie.
• The token is attached automatically to admin requests; a request without a valid token is rejected.

Content Security Policy & headers

• A strict Content-Security-Policy is enforced using per-request nonces, avoiding unsafe-inline scripts.
• Standard hardening headers are set on every response: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• Sensitive API routes (settings, import, 2FA, dashboard) are marked X-Robots-Tag: noindex, nofollow, noarchive, nosnippet so they're never indexed by search engines.

Tracking pixel endpoint

The pixel endpoint (api/pixel.php) is the only route reachable by anonymous visitors, so it gets extra scrutiny:

• Requests are rate-limited per IP prefix (sliding window), applied before any other processing — so even malformed or invalid requests can't be used to flood the server.
• The site parameter is checked against a whitelist of configured sites; unknown sites are silently dropped.
• All data written to the database goes through prepared statements (PDO) — no raw SQL string building, so SQL injection isn't possible through pixel input.

Data minimization & visitor privacy

• Brivacia does not create a persistent visitor profile. The daily visitor identifier is a hash derived from the day, a truncated IP, and the user agent family — it changes every day and cannot be used to track someone across days.
• IP addresses are truncated (2 or 3 octets, configurable) before being used for country estimation, and are never stored in full.
• Log files never contain raw IP addresses — they're redacted automatically before being written.
• A public "Your data" widget can be added to the tracked site so visitors can see exactly what's recorded about them.

Logs

• All logs are written through a single logging function with automatic 30-day retention — old entries are purged, so log files don't grow indefinitely over the years.
• Log content is sanitized (line breaks stripped, IPs redacted, length capped) before being written.

Updates

• The self-update system downloads a new release archive and verifies its SHA-256 checksum before installing it, to detect a corrupted or unexpected file.

Data storage

• All data is stored locally in a SQLite database file — no data leaves your server, no third-party analytics service is involved.
• Automatic backups are taken, and the database is automatically restored from the latest backup if it becomes unreadable or corrupted.
• Old data is archived yearly to keep the active database lightweight.

What's outside Brivacia's control (your responsibility as a host)

Brivacia protects the application layer, but a few things depend on how you deploy it:

• HTTPS: Brivacia doesn't force an HTTPS redirect itself. If your server doesn't have HTTPS configured, forcing a redirect in the application could make the dashboard unreachable — so this is left to your web server configuration (.htaccess, Nginx, or a reverse proxy like Caddy/Traefik).
• File system protection: make sure your web server denies direct access to data/, logs/, and archives/ (a default .htaccess is provided, verify it's active on your setup).
• data/brivacia.key: this file signs your admin sessions and CSRF tokens. Keep it backed up and never share it — losing it invalidates all sessions, leaking it lets someone forge them.
• Custom rules (includes/rules_custom.php): if you write your own page/title rules from the provided sample, you have full server access anyway — Brivacia doesn't sandbox this file, the same way it doesn't sandbox any other file on your own server.
• PHP & server updates: keeping your PHP version and server software patched is on you, as with any self-hosted software.

Reporting a security issue

If you find a security issue in Brivacia, please [contact details / process to fill in] rather than opening a public issue, so it can be fixed before being disclosed.

Do you find this project useful? You can support its development using the buttons in the page footer.