Hardening

​

Decide your network exposure

​

TLS via reverse proxy

privacytracker.lan {
    reverse_proxy localhost:3000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
    }
}

services:
  privacytracker:
    image: privacytracker:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.pt.rule=Host(`privacytracker.lan`)"
      - "traefik.http.routers.pt.tls=true"
      - "traefik.http.services.pt.loadbalancer.server.port=3000"
      - "traefik.http.middlewares.pt-headers.headers.customRequestHeaders.Host=privacytracker.lan"
      - "traefik.http.routers.pt.middlewares=pt-headers"

server {
    listen 443 ssl http2;
    server_name privacytracker.lan;

    ssl_certificate     /etc/letsencrypt/live/privacytracker.lan/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/privacytracker.lan/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3000;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

# Should fail with 403
curl -X POST https://privacytracker.lan/api/sync/trigger

# Should succeed
curl -X POST https://privacytracker.lan/api/sync/trigger \
  -H "Origin: https://privacytracker.lan"

​

Set the admin token

openssl rand -hex 32
# 7c8d2a3f… (paste into your .env, compose file or service manager)

echo "AUDITOR_ADMIN_TOKEN=$(openssl rand -hex 32)" >> .env
docker compose up -d --force-recreate

# Should fail with 401 {"error":"Admin token required"}
curl -X POST https://privacytracker.lan/api/reset \
  -H "Origin: https://privacytracker.lan"

# Should succeed
curl -X POST https://privacytracker.lan/api/reset \
  -H "Origin: https://privacytracker.lan" \
  -H "X-Auditor-Admin-Token: $AUDITOR_ADMIN_TOKEN"

​

Block dev endpoints from the proxy

privacytracker.lan {
    @dev path /api/dev/*
    handle @dev {
        respond 404
    }
    reverse_proxy localhost:3000 {
        header_up Host {host}
    }
}

curl -X POST https://privacytracker.lan/api/dev/seed-sample-data
# 404

​

Review the audit log

sqlite3 data/privacy.db "
  SELECT datetime(created_at/1000, 'unixepoch') AS ts, action, actor_ip, user_agent
  FROM audit_log
  WHERE created_at > strftime('%s', 'now', '-30 days') * 1000
  ORDER BY created_at DESC
  LIMIT 50;
"

• Repeated admin_token.login.invalid from the same IP — someone’s brute-forcing. Rotate the token, then ban the IP at the proxy. admin_token.login.rate_limited and admin_token.login.global_throttled mean the built-in limiter already pushed back.
• Unfamiliar IPs hitting destructive routes — even if the token check passed (i.e., they have the token), an unfamiliar source means the token leaked. Rotate.
• reset.success you didn’t trigger — your data was wiped. Restore from backup; investigate how the actor got the token.

​

Off-host backups

# /etc/cron.d/privacytracker-backup
0 3 * * * privacytracker rsync -a /opt/privacytracker/data/ backup@nas-2:/backups/privacytracker-$(date +\%F)/

​

Disable inbound auto-update on Tier 3

• Run the Docker build instead of the desktop app on Tier 3 hosts. Image updates are explicit (docker compose pull && up), which is the posture this tier wants anyway.
• Block the update endpoint at the host firewall — the updater reads https://github.com/privacykey/privacytracker/releases/latest/download/latest.json. A failed check now backs off (15 minutes, doubling, capped at a day) rather than retrying tightly, so a blackholed endpoint is not a busy loop.

​

Network restrictions

sqlite3 data/privacy.db \
  "INSERT OR REPLACE INTO app_settings (key, value) VALUES ('update_check_enabled', 'false');"

​

Pre-launch checklist

​

What you can’t lock down

• No user accounts. Anyone with browser access has full access. Treat the URL itself as a credential.
• No per-caller rate limiting without a trusted proxy. privacytracker does limit its own routes (Rate limiting) — 30/min on /api/scrape, 3 per 10 min on /api/backup/restore, 5/min on token login, and so on. But unless PRIVACYTRACKER_TRUST_PROXY is set, X-Forwarded-For is untrusted and every caller shares one bucket per route, so a bad actor inside the trust boundary consumes the same budget as the household. Rate-limit at the proxy if Tier 3.
• No anti-CSRF beyond same-origin. No token-cookie pairs, no SameSite=strict-only flows. The same-origin check + the admin token are the entire CSRF surface.
• No append-only enforcement on audit_log at the SQL level. Individual rows are never rewritten — the only write is an insert — but two admin-token routes clear the whole table (POST /api/admin/start-over truncates it, POST /api/backup/restore replaces it), and a process with shell access to data/privacy.db can rewrite it directly. So the actor you are investigating after a token leak can erase the record of their own access. The mitigation is to replicate the log off-host, and not to give untrusted actors shell access.