Comment sécuriser ses tâches planifiées (Cron jobs) sur un serveur de production ?

Un script Cron qui s’exécute avec trop de privilèges, qui s’exécute en double ou qui échoue en silence représente un danger majeur pour la sécurité et l’intégrité de vos données.

Règle 1 : Ne lancez jamais vos scripts sous l’utilisateur root

Un script vulnérable exécuté en root compromet instantanément l’intégralité du serveur dédié. Utilisez le cron de l’utilisateur applicatif dédié (ex: www-data).

# Modifier le cron d'un utilisateur spécifique
crontab -u www-data -e

Règle 2 : Déclarer un environnement d’exécution (PATH) explicite

Contrairement à votre terminal interactif, l’environnement d’un Cron est extrêmement restreint. Spécifiez toujours les chemins absolus pour vos binaires ou déclarez le PATH en haut de votre fichier crontab :

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Exemple de tâche sécurisée avec chemins absolus
0 4 * * * /usr/bin/php /var/www/mon-projet/artisan backup:run

Règle 3 : Éviter l’exécution simultanée (Overlap) avec flock

Si un script de synchronisation configuré pour tourner toutes les 5 minutes met finalement 10 minutes à s’exécuter, une deuxième instance va se lancer en parallèle. Cela provoque souvent des corruptions de données ou des surcharges CPU. Utilisez flock pour verrouiller l’exécution :

*/5 * * * * usr/bin/flock -n /tmp/mon_cron_sync.lock -c "/usr/bin/php /var/www/mon-projet/sync.php"

(Le commutateur -n indique à flock de s’arrêter immédiatement sans attendre si le verrou est déjà actif).

Règle 4 : Capturer et masquer la sortie standard, mais logger les erreurs

Ne laissez pas vos crons polluer les boîtes mail locales ou les fichiers de logs génériques. Redirigez la sortie standard (stdout) vers le vide absolu /dev/null, tout en capturant les erreurs (stderr) :

0 2 * * * /usr/bin/python3 /scripts/clean.py > /dev/null 2> /var/log/cron_e