Sécurité

Sécurité

• CSRF — Toutes les actions POST (formulaires et AJAX) sont protégées par un token CSRF via session serveur. L'en-tête X-CSRF-Token est injecté automatiquement sur chaque fetch non-GET grâce à un intercepteur JavaScript.
• XSS — Les données issues d'API tierces (AirVPN) injectées dans le DOM via innerHTML sont systématiquement échappées par une fonction _esc() (HTML entity encoding) avant insertion. Les attributs onclick/onchange inline présents dans les composants dynamiques ne contiennent que des valeurs JSONifiées ou des constantes — aucune donnée utilisateur non échappée n'y est interpolée.
• SECRET_KEY — L'application refuse de démarrer si SECRET_KEY est absente ou égale à la valeur par défaut (dev-secret-change-me, remplacer-par-une-chaine-aleatoire-longue). Génère une clé sécurisée avec : openssl rand -hex 32.
• Injection YAML/XML — La valeur du filtre de serveur est assainie avant écriture dans docker-compose.override.yml en mode Compose (retours à la ligne supprimés, guillemets et backslashs échappés). En mode Unraid/DockerMan, les valeurs sont échappées avant écriture dans le template XML, avec sauvegarde .bak datée.
• Socket Docker — Le socket Docker est sécurisé via docker-socket-proxy, qui restreint les appels autorisés : lecture (containers, images, réseaux, volumes) + POST/DELETE pour la gestion des sidecars temporaires. Tout accès direct au daemon Docker (exec, swarm, info…) est bloqué.
• Anti brute-force — Le login bloque une IP après 5 échecs en 5 minutes pendant 15 minutes (compteur en mémoire, remis à zéro à la connexion réussie).
• Exposition réseau — Gunicorn écoute sur 0.0.0.0:8765 (toutes interfaces). Ne pas exposer ce port directement sur Internet. Sur un serveur accessible publiquement, placez Companion derrière un reverse proxy (Nginx, Caddy, Traefik) avec HTTPS et authentification forte, ou restreignez le binding à l'interface locale : 127.0.0.1:8765:8765 dans le docker-compose.yml.
• /metrics — Ouvert par défaut sur le LAN. Si votre machine est accessible depuis l'extérieur, définissez la variable METRICS_TOKEN ou configurez un token API dans Paramètres → Maintenance → REST API : /metrics l'utilisera automatiquement pour exiger un Bearer token.
• Sidecar — Chaque container sidecar (speed-test sur le port 8766, catalogue sur le port 8767) reçoit automatiquement un secret aléatoire généré par le Companion (SIDECAR_SECRET, 32 octets d'entropie via secrets.token_hex). Toutes les requêtes HTTP vers le sidecar exigent ce secret dans l'en-tête X-Sidecar-Token — un sidecar sans le bon token répond 403. Ce secret est unique par instance et détruit avec le container à la fin du test. Ces ports ne doivent pas être accessibles depuis l'extérieur : si votre hôte est public, restreignez le binding ou isolez ces ports par firewall.
• Secrets dans /settings — Le token API, le mot de passe proxy et les URLs de webhook sont affichés en clair dans l'interface d'administration. Tout accès à l'UI admin équivaut à un accès total à ces secrets.

Sécurité des images Docker

Les deux images (gluetun-companion et gluetun-companion-sidecar) embarquent des binaires Go tiers (Docker CLI, Docker Compose, librespeed-cli, ookla speedtest) qui ont leur propre chaîne de dépendances, invisible pour les gestionnaires de paquets Python. Un pipeline à deux niveaux maintient ces images à jour :

Dependabot (déjà en place, exécuté chaque lundi 06:00 UTC) :

• Met à jour les dépendances pip de Companion et du Sidecar (PRs automatiques ; les patchs demandent l'auto-merge si cette fonction GitHub est activée, les mineures restent en revue manuelle)
• Surveille les images de base Docker (python:3.12-slim) — mises à jour de sécurité du runtime Python
• Surveille les versions des GitHub Actions dans les workflows CI

Workflow Trivy (.github/workflows/trivy-scan.yml, chaque lundi 07:00 UTC) :

• Builde les deux images et les scanne avec Trivy pour les CVE de sévérité HIGH et CRITICAL
• Upload les résultats au format SARIF dans l'onglet Security du dépôt GitHub (visible sous Security → Code scanning)
• Si des CVE avec fix disponible sont détectées et qu'une image Docker CLI plus récente existe : ouvre automatiquement une PR qui bumpe le FROM docker:XX-cli dans le Dockerfile
• Si aucun changement automatique n'est possible : ouvre une Issue listant les CVE à corriger manuellement

Smoke test (.github/workflows/docker-publish.yml, sur chaque PR) :

• Builde les deux images en amd64
• Démarre chaque container avec une configuration minimale et vérifie qu'il répond en HTTP dans les 20 secondes
• Échoue si une image ne démarre plus ; il bloque la fusion lorsqu'il est configuré comme contrôle requis dans la protection de main

---