Version 1.0 – 2 novembre 2025
Auteur : [Votre nom / votre agence]
1. Introduction
Dolibarr est un ERP/CRM open‑source très populaire qui permet de gérer la comptabilité, la logistique, les ventes, les achats, la gestion de projets, etc. Sa flexibilité, sa simplicité d’installation et son moteur de plugins en font une solution prisée par les PME et les organisations à but non lucratif.
Cependant, comme tout logiciel web, Dolilbr pose des risques de sécurité lorsqu’il est exposé à Internet ou lorsqu’il est utilisé par plusieurs utilisateurs.
Le présent article vous propose :
- Un cadre de nettoyage (hardening) de votre instance Dolibarr.
- Un guide pratique étape par étape pour sécuriser, nettoyer et maintenir votre système.
- Des intégrations modernes (SSO, API, paiement en ligne, notifications) qui renforcent la sécurité tout en améliorant l’expérience utilisateur.
Objectif : Passer d’une installation « développeur » à un environnement de production robuste, audité et conforme aux bonnes pratiques.
2. Pourquoi la sécurité Dolibarr mérite-t-elle une attention particulière ?
| Risque | Impact potentiel | Exemple de scénario |
|---|---|---|
| Accès non authentifié | Exposition de données sensibles (clients, factures, stocks) | Un visiteur malveillant récupère les factures de l’entreprise. |
| Exploitation de vulnérabilités du core ou des modules | Escalade de privilèges, exécution de code à distance | Injection SQL via un formulaire non filtré. |
| Mauvaise gestion des droits | Fraudes internes ou erreurs de facturation | Un employé modifie des prix sans supervision. |
| Stockage non chiffré des données sensibles | Vol de données en cas de compromission du serveur | Accès aux numéros de carte bancaire en clair. |
| Dépendances obsolètes | Introduction de failles connues | Bibliothèques tierces à l’origine d’une faille XSS. |
| Mauvaise configuration HTTPS / HTTP Headers | Interception de sessions (session hijacking) | Cookies non sécurisés interceptés en clair. |
Ces risques sont évitable grâce à un processus de nettoyage et de renforcement systématique.
3. Checklist de nettoyage (« Hardening ») de Dolibarr
À exécuter avant toute mise en production
(ou après chaque mise à jour majeure)
3.1. Pré‑installation
| Action | Pourquoi | Comment |
|---|---|---|
| Utiliser les dernières versions de PHP, MySQL/MariaDB, Apache/Nginx | Corrige les bugs déjà résolus | apt upgrade && apt install php8.2-fpm php8.2-cli php8.2-mbstring php8.2-xml |
Désactiver les modules PHP inutiles (ex. php-auth) |
Réduire la surface d’attaque | Modifier php.ini → disable_functions = exec,passthru,shell_exec,system,proc_open |
| Créer un user dédié pour Dolibarr (pas de root) | Limiter les privilèges | useradd -r -s /usr/sbin/nologin dolibarr |
Installer sur un sous‑domaine dédié (doli.mondomaine.com) |
Isoler le trafic | Configurer VirtualHost + ServerName doli.mondomaine.com |
3.2. Configuration de Dolibarr
| Setting | Valeur recommandée | Action |
|---|---|---|
$dolibarr->global->enabled_authentication_methods |
ldap, oauth2, sso |
Désactiver les méthodes none / basic si non utilisées. |
$conf['allowguest'] |
0 |
Bloquer l’accès en mode invité. |
$conf['allow_export'] |
1 (déconseillé) ou 0 en production |
Désactiver les exports CSV/Excel si non nécessaires. |
$conf['money_prefix'] / $conf['money_suffix'] |
Convenir à votre locale | Standardiser le format de monétaire. |
$conf['hide_completed_payments'] |
1 |
Masquer les paiements déjà traités. |
$conf['log_type'] |
syslog ou dedicated_file |
Centraliser les logs. |
$conf['dol_openapi'] |
1 (pour API) |
Activer l’API REST uniquement avec jetons SSL. |
3.3. Sécurisation du serveur web
| Directive (exemple Apache) | Explication |
|---|---|
Header set X-Content-Type-Options "nosniff" |
Empêche le navigateur d’interpréter les fichiers comme un autre type. |
Header set X-Frame-Options "DENY" |
Bloque les clickjacking. |
Header set X-XSS-Protection "1; mode=block" |
Active la protection XSS du navigateur. |
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'none';" |
Restreint les sources de scripts, CSS, objets et URIs. |
SSLProxyEngine On + TLS 1.2+ |
Forcer le chiffrement TLS 1.2 ou supérieur. |
Redirect permanent / /login?redirect=... |
Rediriger tout accès non authentifié vers la page de login. |
3.4. Gestion des droits internes
| Méthode | Description |
|---|---|
| RBAC (Role‑Based Access Control) | Créez des rôles Admin, Facturation, Gestion de projet avec des droits granulaires. |
| Audit Trail | Activez CONFIG_MULTICOMPANY = 1 et journalisez chaque modification dans audit table. |
| Segregation Of Duties (SoD) | Interdisez à un même rôle de créer + valider un même type de document. |
4. Guide pratique – Nettoyage pas à pas
Le processus suivant est pensé pour une installation existante (Dolibarr 23.x) que l’on veut mettre en conformité.
Étape 1 – Sauvegarde complète
# Export de la base
mysqldump -u dolibarr -p dolibarr > /var/backups/dolibarr_$(date +%F).sql
# Copie du répertoire de fichiers
tar czf /var/backups/dolibarr_web_$(date +%F).tgz /var/www/dolibarrVérifiez l’intégrité de la sauvegarde avant de poursuivre.
Étape 2 – Mise à jour du core et des modules
cd /var/www/dolibarr
git pull https://github.com/Dolibarr/dolibarr.git
# Si vous utilisez des modules via le marketplace, mettez-les à jour aussiAprès chaque mise à jour, lancez les tests fonctionnels (ex. création d’un devis).
Étape 3 – Nettoyage des fichiers temporaires et caches
rm -rf /var/www/dolibarr/files/_temp/*
rm -rf /var/www/dolibarr/files/_cache/*
rm -rf /var/www/dolibarr/temp/*Ces dossiers peuvent contenir des traces de sessions ou de logs non sécurisés.
Étape 4 – Masquage des informations sensibles dans les logs
Modifier /etc/php/8.2/fpm/php.ini :
expose_php = Off
display_errors = Off
log_errors = On
error_log = /var/log/php-dolibarr.logAssurez-vous que le fichier est chmod 640 et owner root:adm, afin que seul le groupe d’administration puisse le lire.
Étape 5 – Renforcement des sessions PHP
// En haut du fichier htdocs/_config.php (ou dans un custom plugin)
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_secure', 1); // si HTTPS
ini_set('session.use_strict_mode', 1);
ini_set('session.sid_length', 128);
session_name('DOL_SESSID');Ces paramètres empêchent le vol de cookie via XSS et MITM.
Étape 6 – Audit des modules tiers
| Action | Outils |
|---|---|
| Lister tous les plugins installés | php /var/www/dolibarr/docs/tools/scripts/list_modules.php |
| Vérifier la version et la date de dernière mise à jour | Interface Admin → “Modules → Marketplace → Updates” |
| Désactiver ceux qui ne sont plus maintenus | Désinstaller via “Desinstaller” dans l’admin. |
| Valider les dépendances | php -m | grep -i '^dolibarr' (vérifier les extensions requises). |
Étape 7 – Mise en place d’une authentification moderne
7.1. SSO via LDAP / Active Directory
- Activer le module LDAP :
php /var/www/dolibarr/docs/tools/scripts/ldap_init.php. - Configurer dans
Admin → Configuration → Authentification → LDAP:- URL serveur LDAP (
ldaps://ad.example.com). - Bind DN (
cn=svc-dolibarr,ou=services,dc=example,dc=com). - Mot de passe du compte service.
- Filtre d’utilisateur (
(&(objectClass=user)(sAMAccountName=%{user}))). - Mapper les attributs (mail → email, givenName → firstName).
- URL serveur LDAP (
7.2. OAuth2 / OpenID Connect (ex. Keycloak)
- Créez un client dans Keycloak (
Dolibarr) avec les redirect URIs :https://doli.mondomaine.com/*. -
Dans Dolibarr (admin → Authentification → OpenID Connect) :
client_id= dolibarr_clientclient_secret= [secret généré]authorisation endpoint=https://keycloak.example.com/realms/myrealm/protocol/openid-connect/authtoken endpoint=https://keycloak.example.com/realms/myrealm/protocol/openid-connect/tokenScope=openid email profile.
- Activer le mode « OAuth2 Only » pour refuser les logins en mode « basic ».
Étape 8 – Chiffrement des données sensibles
| Donnée | Technique | Où la configurer |
|---|---|---|
| Cartes bancaires | Utiliser Stripe ou PayPal (PCI‑DSS) et ne jamais stocker le PAN en clair. | Module paiement → Enable PCI mode + Store payment data? = 0. |
| Numéros de TVA intracommunautaire | Chiffrement AES‑256 via plugin DoliCrypto (bundle dolibarr.plugins.crypto). |
Admin → Plugins → Cryptography → Enable. |
| Mail de connexion (reset password) | Utiliser un token à usage unique (hashé SHA‑256) stocké 24 h. | Admin → Paramètres → Sécurité → Reset token TTL. |
Étape 9 – Mise en place d’un monitoring et WAF
- Fail2Ban : créer un filtre pour les tentatives de login brute‑force (
dolibarr-login.conf). - ModSecurity (Apache) : règle CRS 950120 (SQL injection) + 960015 (XSS).
- Grafana + Loki : agrégation des logs PHP/Apache pour détection d’anomalies.
Étape 10 – Test de pénétration rapide (automatisé)
# OWASP ZAP baseline
zap.sh -daemon -port 8090 -config api.disablekey=true
zap-cli -p 8090 quick-scan http://doli.mondomaine.com/Analysez les résultats, corrigez les problèmes avant le passage en production.
5. Intégrations modernes qui renforcent la sécurité
| Intégration | Pourquoi c’est plus sûr | Implémentation rapide |
|---|---|---|
| Single Sign‑On (SSO) – Azure AD / Okta | L’accès est centralisé, les mots de passe ne sont jamais stockés en interne. | Utiliser le plugin “SSO – OpenID Connect”. |
| Authentification à deux facteurs (2FA) | Ajoute une couche de protection contre le phishing. | Configuration via Google Authenticator ou Duo Security (plugin disponible). |
| API REST sécurisée (OAuth 2.0) | Permet aux applications tierces d’interagir sans exposer les droits admin. | Activer $conf['dol_openapi'] = 1 + créer des jetons avec exp limité (30 jours). |
| Notifications par email transactionnelles via DKIM/SPF | Empêche le détournement de domaine et les phishing “faux” factures. | Utiliser le mailer interne de Dolibarr + serveur de mail interne avec DKIM. |
| Webhooks pour les paiements | Les notifications de paiement sont signées par le PSP (ex. Stripe). | Créer un contrôleur /webhook/stripe.php qui vérifie la signature HMAC. |
| Gestion des secrets via Vault ou Secrets Manager | Aucun mot de passe en clair dans les fichiers de configuration. | Injecter les variables d’environnement dans docker-compose.yml. |
Astuce : Combinez SSO + 2FA + API‑only pour obtenir un modèle Zero Trust : chaque appel est authentifié, les droits sont limités, et chaque action est journalisée.
6. Bonnes pratiques de maintenance continue
| Fréquence | Action |
|---|---|
| Hebdomadaire | Vérifier les mises à jour de sécurité (core + modules). |
| Mensuel | Exécuter un scan de vulnérabilité (ex. Nikto, OpenVAS). |
| Trimestriel | Réviser les logs d’audit et les performances du serveur. |
| Annuel | Réévaluer le plan de continuité d’entreprise (BCP) et la politique de sauvegarde. |
| Après chaque incident | Faire un post‑mortem → mettre à jour les procédures et les scripts d’automatisation. |
7. Checklist finale – Votre instance Dolibarr est‑elle prête ?
| ✅ | Item |
|---|---|
| 1 | Dernière version du core (≥ 23.0.3) installée. |
| 2 | Tous les modules tiers à jour et audités. |
| 3 | Authentification SSO ou 2FA activée. |
| 4 | $conf['allowguest'] = 0; aucun compte “admin” en clair. |
| 5 | HTTPS obligatoire etheaders de sécurité configurés. |
| 6 | Sessions PHP httponly, secure, strict. |
| 7 | Journalisation centralisée + rétention ≥ 90 jours. |
| 8 | Sauvegarde automatisée (full + incrémentale) testée. |
| 9 | WAF / Fail2Ban en place et règles actualisées. |
| 10 | Plan de réponse à incident documenté. |
8. Ressources complémentaires
| Ressource | Lien |
|---|---|
| Documentation officielle Dolibarr – Sécurité | https://www.dolibarr.org/doc/en/security/ |
| Guide de durcissement OWASP pour les applications PHP | https://owasp.org/www-project-phpshell/ |
| Plugin “DoliCrypto” – Chiffrement AES‑256 | https://github.com/Dolibarr/dolibarr-plugins/tree/master/crypto |
| Keycloak – Securing an app with OpenID Connect | https://www.keycloak.org/docs/latest/securing_apps/ |
| ModSecurity CRS – Rule 950120 (SQLi) | https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.3.0/rules/950120-detect-sqli.conf |
9. Conclusion
Dolibarr est un outil puissant, mais sa sécurité dépend avant tout d’une configuration rigoureuse et d’une culture de maintenance. En suivant le processus de nettoyage décrit ci‑dessus :
- Mettre à jour le core et les modules.
- Sécuriser le serveur web et les sessions PHP.
- Passer à une authentification moderne (SSO, OAuth2, 2FA).
- Chiffrer les données sensibles et gérer les droits RBAC.
- Monitorer, auditer et tester régulièrement.
Vous disposerez ainsi d’une plateforme fiable, auditée et prête à s’intégrer avec les solutions les plus récentes (API, paiement en ligne, notifications sécurisées).
N’oubliez pas : la sécurité n’est jamais « termine ». Chaque mise à jour, chaque nouveau module et chaque accès réseau doit être repensé sous l’angle de la minimisation des surfaces d’attaque.
Bonne sécurisation ! 🚀
Auteur :
[Nom du·de la rédacteur·trice] – Expert·e en ERP open‑source & Architecture sécurisée.
Contact : expert@exemple.com | LinkedIn : linkedin.com/in/exemple.