Skip to content

Security: thejuran/triggarr

SECURITY.md

Security Policy

Supported Versions

Version Supported
2.x Yes
1.x No

Reporting a Vulnerability

Do not open a public issue for security vulnerabilities.

Please use GitHub's private vulnerability reporting to report security issues. You will receive a response within 7 days.

Security Model

Triggarr is a single-process automation daemon that connects to configured Radarr, Sonarr, and Lidarr instances. It includes application authentication by default, protects stored service credentials, and is designed for Docker-first deployments with an optional standalone config directory.

Authentication and Access Control

  • Setup flow by default -- a fresh config starts in setup mode and redirects browser users to /setup until a local username, password hash, API key, and session secret are created.
  • Supported auth modes -- Forms (default), Basic, External, and Disabled are configured in [auth].method. Use External only when a trusted reverse proxy or SSO layer enforces authentication and authorization before traffic reaches Triggarr and direct access to port 8484 is blocked. Disabled intentionally removes Triggarr auth and should be limited to already-private networks.
  • Session cookies -- browser sessions are signed, HTTP-only, SameSite=Lax cookies with a 30-day max age. Cookies are marked Secure when the ASGI request scheme is HTTPS. Behind a reverse proxy, Uvicorn can translate X-Forwarded-Proto into that HTTPS scheme only for peers listed in TRUSTED_PROXY_IPS; configure that trust list so forwarded headers are accepted only from expected proxies.
  • API access -- requests may authenticate with X-Api-Key when auth.api_key is configured. API keys are generated by setup/security settings flows and compared using timing-safe checks.
  • Login protection -- form login attempts are rate-limited per client IP.

Credential Protection

  • SecretStr for API keys and auth secrets -- instance API keys, auth API keys, password hashes, and session secrets are stored as Pydantic SecretStr fields. Secret values are only unwrapped at explicit use sites such as HTTP client initialization, password/session validation, or API-key comparison.
  • Loguru redaction -- a custom redacting sink filters collected secret values from log output before writing, covering both log messages and exception tracebacks.
  • Settings UI redaction -- normal settings pages do not expose stored API keys or auth secrets in HTML.

Web Security

  • Deny-by-default route protection -- after setup, non-exempt routes require a valid session, API key, configured Basic credentials, or an explicitly configured External/Disabled mode.
  • CSRF protection -- OriginCheckMiddleware validates the Origin and Referer headers on state-changing requests (POST, PUT, PATCH, DELETE), rejecting cross-origin submissions with 403 Forbidden.
  • Security headers -- responses include frame denial, MIME-sniffing prevention, same-origin referrer policy, and a restrictive Content Security Policy.
  • SSRF validation -- URL inputs are validated against an allow-list of schemes (http, https) and a block-list of cloud metadata and link-local hostnames to prevent server-side request forgery.
  • Input clamping -- integer form values are clamped to safe bounds (minimum/maximum) rather than rejected, preventing overflow or abuse of numeric settings.

Data Integrity and Runtime Paths

  • Atomic file writes -- config (TOML) and state (JSON) writes use a write-to-tempfile, fsync, then rename pattern. This prevents corruption from interrupted writes or container restarts.
  • Config file permissions -- Triggarr writes the TOML config with owner-read/write permissions.
  • Config directory contract -- runtime config, state, and SQLite files derive from TRIGGARR_CONFIG_DIR when set to an absolute path. When it is unset, Triggarr uses /config for Docker compatibility.

Container Hardening

  • Multi-stage Docker build -- Tailwind CSS compilation happens in a builder stage; only the compiled CSS artifact is copied to the production image. Build tools are not present at runtime.
  • PUID/PGID privilege dropping -- the entrypoint creates a non-root user with the specified UID/GID and drops privileges via setpriv --reuid/--regid with --no-new-privileges where supported.
  • Minimal Linux capabilities -- the recommended compose configuration drops all capabilities except those required for startup ownership and privilege setup.
  • Health check -- a built-in Docker HEALTHCHECK verifies the application is responsive.

Deployment Recommendations

  • Keep the Docker port bound to localhost (127.0.0.1:8484:8484) unless Triggarr is behind Tailscale, a VPN, or a reverse proxy.
  • Set TRUSTED_PROXY_IPS to specific proxy IPs or CIDR ranges when using forwarded headers. Do not use *, because it lets any client spoof its apparent IP address.
  • Prefer auth.method = "External" only for reverse-proxy or SSO deployments where the proxy enforces authentication and authorization and is the only path to Triggarr.
  • Rotate any Radarr/Sonarr/Lidarr API keys that may have been pasted into logs, screenshots, issue reports, or shared config files.

There aren't any published security advisories