Dolibarr et la Sécurité : erreurs fréquentes & solutions sans toucher au fonctionnement déjà existant
Article rédigé en français – à destination des administrateurs, chefs de projet et utilisateurs qui souhaitent renforcer la sécurité de leur instance Dolibarr sans réécrire les workflows déjà en place.
1. Introduction
Dolibarr est un ERP / CRM léger, très apprécié pour sa facilité d’utilisation et sa souplesse d’adaptation. Cette simplicité, cependant, ne garantit pas automatiquement une posture de sécurité solide. De nombreux déploiements pratiques – petites entreprises, associations ou services IT d’entreprise – fonctionnent « out‑of‑the‑box » sans analyser les risques potentiels.
Le but de cet article est double :
- Identifier les erreurs de sécurité les plus récurrentes dans les installations Dolibarr.
- Proposer des solutions concrètes qui permettent d’améliorer la sécurité tout en conservant le fonctionnement actuel du système.
2. Principales erreurs de sécurité rencontrées
| # | Erreur | Pourquoi c’est dangereux | Exemple concret dans Dolibarr |
|---|---|---|---|
| 1 | Mauvaise gestion des droits d’accès | Les fiches clients/fournisseurs, factures ou stocks sont alors visibles ou modifiables par des utilisateurs non autorisés. | Un collaborateur avec le rôle Editor peut créer de fausses factures. |
| 2 | Utilisation de la version par défaut des modules | Certaines extensions (ex. : paiement en ligne, signature électronique) sont installées avec leurs réglages de sécurité désactivés. | Le module Card Booking accepte les requêtes GET non authentifiées. |
| 3 | Aucun chiffrement des données sensibles | Données de cartes bancaires, identifiants ou pièces d’identité transitent en clair sur le serveur ou le réseau. | Les champs Numéro de carte sont stockés sans AES‑256. |
| 4 | Mauvaise configuration du serveur web | Les fichiers de configuration ou les backups sont accessibles via le répertoire web. | config.php peut être téléchargé depuis le navigateur. |
| 5 | Absence de mises à jour automatiques | Des vulnérabilités connues (ex. : XSS, SQLi) restent exploitées tant que le core ou les modules ne sont pas patchés. | Une faille CVE‑2023‑xxxxx dans le module Payment persiste après sa publication. |
| 6 | Mauvaise gestion des backups | Les sauvegardes sont stockées en clair, souvent sur le même serveur ou sur un partage non sécurisé. | Un backup .db contenant des numéros de carte est consultable par n’importe qui. |
| 7 | Utilisation de comptes par défaut ou mots de passe faibles | Les comptes admin/admin avec mot de passe « admin » sont encore existants sur certaines installations. |
L’accès à l’interface d’administration est possible en une seule tentative. |
| 8 | Pas de journalisation ou de monitoring | Aucun alertes en cas d’activité suspecte (connexions multiples, modifications massives). | Aucun log n’est renvoyé lorsqu’un utilisateur exporte la totalité de la base. |
3. Solutions concrètes – « sans casser l’existant »
3.1. Verrouiller et affiner les droits d’accès
| Action | Méthode | Impact minimal sur le fonctionnement |
|---|---|---|
| Audit des profils | Utiliser le menu Administration → Permissions → « Vérifier les droits ». Exporter la matrice actuelle et la comparer à la matrice de référence (ex. : admin doit être le seul avec Root). |
Aucun changement de code, seulement une réaffectation de rôles. |
| Créer des rôles spécifiques | Ajouter un rôle « Finance » avec uniquement Invoice view/edit et Bank reconciliation. |
Les workflows restent les mêmes, seules les restrictions s’appliquent. |
| Désactiver les actions sensibles | Désactiver le bouton “Delete” pour les profils non‑admin via Settings → Advanced → Disable Delete. | L’interface reste fonctionnelle mais empêche la suppression accidentelle. |
3.2. Sécuriser les modules additionnels
| Module | Erreur typique | Fix sans rupture |
|---|---|---|
| Payment (ex. : Stripe, PayPal) | Accès direct aux URL de paiement sans validation. | Activer le mode “Secure Checkout” (HTTPS obligatoire) dans les paramètres du module. |
| QR Code / PDF Generation | Export PDF contenant les champs sensibles en clair. | Limiter l’accès aux utilisateurs qui possèdent le rôle “Export”; ajouter un filtre mask_sensitive_data=true dans la configuration du module. |
| Third‑party plugins | Installation par défaut sans désactivation du support de debug. | Passer le paramètre debug_mode sur false via le fichier llxConstant. |
3.3. Chiffrer les données sensibles
| Technique | Implémentation (sans toucher au code source) |
|---|---|
| Chiffrement au niveau DB | Utiliser les fonctions de chiffrement MySQL (AES_ENCRYPT) dans les champs personnalisés via le Hook UserAction (ou en créant un champ « masked »). |
| Stockage des cartes | Activer l’option “Hide PAN” du module Payment qui masque le numéro de carte dans l’interface et ne le stocke que sous forme de token. |
| PST (Personal Data) | Configurer le moteur de cryptage de Dolibarr ($cfg->dol_use_recyclers) pour crypter les champs marqués comme “sensitive”. |
Astuce : Les modifications se font via les fichiers de configuration (
llx.conf) ou via le tableau de bord Parameters → Security. Aucun fichier core n’est modifié, donc aucune regression pendant les upgrades.
3.4. Renforcer la configuration du serveur web
| Configuration | Action recommandée |
|---|---|
| Accès aux fichiers de configuration | Placer le répertoire htdocs hors du document root ou ajouter un .htaccess avec Deny from all sur config.php et llx* fichiers. |
| Headers de sécurité | Ajouter les lignes suivantes dans le .htaccess ou dans la configuration Apache/Nginx : Header set X-Content-Type-Options "nosniff" Header set X-Frame-Options "SAMEORIGIN" Header set Content-Security-Policy "default-src 'self' ; script-src 'self' 'unsafe-inline' ; style-src 'self' 'unsafe-inline' ;" |
| Redirection HTTPS | Forcer le protocole TLS 1.2+ via RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]. |
Impact : Ces changements sefont côté serveur, n’influencent pas les fonctionnalités de Dolibarr, mais bloquent les vecteurs d’attaque classiques.
3.5. Gestion des mises à jour et du cycle de patching
- Mise en place d’un serveur de test (clone du serveur de prod) où les mises à jour sont testées pendant 48 h.
- Planifier les upgrades (core & modules) lors d’une fenêtre de maintenance avec notification aux utilisateurs.
- Utiliser le module “Upgrade” de Dolibarr (menu Administration →Upgrade) qui applique les scripts de migration sans perte de données.
- Automatiser les contrôles avec un petit script Cron qui compare la version installée à la version officielle du dépôt (
git tag -l).
3.6. Sauvegardes sécurisées
| Étape | Description |
|---|---|
| Sauvegarde chiffrée | Utiliser mysqldump --encrypt ou pg_dump avec gpg pour produire un fichier .gpg. |
| Rotation des backups | Conserver 30 jours sur un volume chiffré, puis archiver sur un stockage hors‑site (ex. : S3 avec SSE‑KMS). |
| Restauration testée | Exécuter une restauration test sur l’environnement de dev chaque trimestre pour s’assurer que les sauvegardes sont intègres. |
3.7. Gestion des comptes et mots de passe
| Action | Méthode |
|---|---|
| Supprimer les comptes “admin”/“admin” | Créer un compte administrateur dédié avec un mot de passe fort (au moins 14 caractères, mixte, chiffres, spéciaux). |
| Activer l’authentification 2FA | Installer le module “2FA” (nécessite PHP ≥ 7.4) et activer la double authentification pour les comptes avec droits élevés. |
| Forcer le changement de mot de passe | Configurer $cfg->login_check_ip = 1; et $cfg->force_password_change = 1; dans conf.php. |
3.8. Journalisation et monitoring
| Technique | Implémentation rapide |
|---|---|
| Activer les logs natifs | Dans conf.php, définir $cfg->log_level = 'debug'; et $cfg->log_dir = '/var/log/dolibarr/';. |
| Surveiller les accès | Utiliser fail2ban avec un filtre dédié aux URLs index.php?main~login ou index.php?account~list. |
| Alertes mail | Configurer mail.watchdog dans Setup → Email pour recevoir un mail à chaque création d’un compte avec le rôle admin. |
4. Checklist “Sécurité Dolibarr – déploiement sans rupture”
| ✅ | Action | Vérification |
|---|---|---|
| 1 | Audit des droits – Réexporter la matrice des rôles. | Aucun rôle possède plus de privilèges que le profil admin. |
| 2 | HTTPS & HSTS – Forcer TLS 1.2+. | curl -I https://votre‑dolibarr renvoie Strict-Transport-Security. |
| 3 | Modules à jour – Vérifier les versions des plugins installés. | Toutes les versions > date de publication de la dernière CVE. |
| 4 | Chiffrement des données sensibles – Appliquer le masquage PAN. | Les champs “Card Number” sont stockés sous forme de token. |
| 5 | Backups chiffrés – Exporter un dump et le protéger avec GPG. | Le fichier .gpg ne peut être lu que avec la clé privée. |
| 6 | 2FA activé – Tester la connexion avec un compte admin. | Le prompt 2FA apparaît après saisie du mot de passe. |
| 7 | Journalisation – Vérifier la présence de logs dans /var/log/dolibarr/. |
Les fichiers error.log et access.log sont créés et remplis. |
| 8 | Plan de restauration – Simuler une restauration sur un serveur de test. | Le système reprend exactement les mêmes données et configuration. |
5. Conclusion
Dolibarr est un outil performant, mais sa simplicité ne doit pas conduire à négliger la sécurité. Les erreurs les plus fréquentes (mauvaises permissions, modules vulnérables, absence de chiffrement, sauvegardes exposées…) sont toutes remédiables par des actions ciblées qui ne requièrent pas la modification du cœur du logiciel.
En suivant la démarche présentée :
- Auditer les droits et les configurations actuelles.
- Verrouiller les points faibles via les réglages natifs ou les modules complémentaires.
- Mettre en place des processus de mise à jour, de sauvegarde et de monitoring automatisés.
… vous obtiendrez une post‑ure de sécurité renforcée tout en préservant les flux métier déjà opérationnels.
Rappel : la sécurité est un processus continu. Réévaluer régulièrement les points ci‑dessus, surtout après chaque mise à jour ou changement majeur de configuration, garantit que votre instance Dolibarr reste à la fois efficace et protéggée contre les menaces actuelles.
Pour toute question précise sur un module ou un réglage particulier, n’hésitez pas à me le préciser ; je pourrai vous fournir le code exact du hook ou le paramètre à modifier.