Sécurité deDolibarr : Étude de cas d’un service Web au Maroc
Version 1.0 – novembre 2025
1. Introduction Depuis le début de la décennie, les PME et les organisations associatives marocaines ont massivement adopté les solutions logicielles libres pour digitaliser leurs processus métiers. Dolibarr, suite ERP‑CRM open‑source, séduit particulièrement par sa simplicité d’installation et son extensibilité via des services Web (REST/SOAP). Pourtant, la mise en œuvre d’un service web exposé sur Internet ou sur le réseau interne d’une PME française‑marocaine expose à des risques de sécurité : injection, accès non‑autorisé aux données sensibles, fuite d’informations via les réponses HTTP, etc.
Cet article propose une analyse détaillée de la sécurité du service Web de Dolibarr à la lumière d’un étude de cas réel mené au Maroc (secteur agro‑alimentaire, coopérative de production de dattes). Nous présentons :
- le contexte organisationnel,
- les exigences légales marocaines (LPM, RGPD‑Maroc, normes ISO 27001),
- les vulnérabilités typiques du service Web,
- le plan d’action de sécurisation,
- les résultats obtenus, et
- les bénéfices pour l’entreprise et les bonnes pratiques à retenir.
2. Dolibarr – rappel technique rapide
| Élément | Description |
|---|---|
| Architecture | Application PHP + MySQL (ou PostgreSQL) et/ou SQLite. |
| Principaux modules | Product, Order, Invoice, Contract, Stock, Payment, Emailing, Web Services. |
| API Web | 1) REST (JSON) pour les modules exposés via /dolibarr/json.php ; 2) SOAP (XML) pour les services legacy (/dolibarr/htdocs/sql/). |
| Authentification | Sessions PHP + token d’API ($conf['HTTPS_KEEPALIVE'] ou $_SESSION['dol_token']). |
| Gestion des droits | ACL basé sur les profils utilisateurs (consultation, création, modification, suppression). |
| Sécurité par défaut | Protection CSRF, filtres d’entrée, désactivation de register_globals. |
Point clé : le service Web n’est pas « off‑the‑shelf » ; il dépend de la configuration serveur, des contrôles d’accès et des paramètres du fichier
conf.php.
3. Cadre réglementaire marocain
| Référence | Contenu principal | Impact sur le service Web de Dolibarr |
|---|---|---|
| Loi n° 09‑08 relative à la protection des données à caractère personnel (LPM) | Obligation de sécuriser les données personnelles, notification de violation sous 72 h. | Chiffrement des communications (HTTPS), journalisation des accès et des modifications. |
| Décret n° 2‑12‑490 portant sur la cyber sécurité | Exigences de mise en place d’un Plan de Continuité Services et de Tests d’intrusion annuels. | Nécessité de mettre en place des contrôles d’authentification forte et de réaliser des scans de vulnérabilité. |
| ISO 27001 (adoptée par la plupart des entreprises publiques) | Politique de sécurité de l’information, gestion des risques. | Documentation des processus liés au service Web, mise en place d’une gouvernance clairement définie. |
| RGPD‑Maroc (alignement avec l’UE) | Principes de minimisation, finalité, exactitude. | Les données exportées via le service Web doivent être limitées aux champs nécessaires. |
4. Vulnérabilités fréquentes du service Web de Dolibarr
| Vulnérabilité | Description | Exemple d’exploitation dans le cas marocain |
|---|---|---|
| Authentification faiblement contrôlée | Le token d’API est parfois stocké en clair dans les logs ou transmis en HTTP. | Un attaquant réseau (Man‑in‑the‑Middle) a récupéré le token et a créé de fausses commandes d’achat. |
| Injection SQL via paramètres GET/POST | Certains paramètres ne sont pas correctement escapés dans les requêtes préparées. | Injection de code SQL sur le module Invoice afin de modifier les solde des comptes. |
| Manque de restriction CORS | Le service accepte les requêtes provenant de tout origine. | Un site tiers peut appeler l’API pour extraire les contacts clients. |
| Exposition des métadonnées | Les réponses JSON contiennent parfois des champs internes (ex : internalnote). |
Extraction de documents contractuels confidentiels. |
| Absence de rate‑limiting | Le serveur accepte un nombre illimité de requêtes par seconde. | Attaque par déni de service (DoS) ciblant le module Stock lors de la campagne de vente de dattes. |
5. Étude de cas : Coopérative « Al‑Mansour » (Maroc)
5.1. Contexte
- Secteur : Production et commercialisation de dattes (exportation vers l’Europe).
- Structure : 45 salariés, 3 sites (production, entrepôt, bureau commercial).
- Besoin : Mettre en place un module de facturation automatisé et un portail B2B permettant aux revendeurs d’obtenir en temps réel le nombre de stocks, les prix et les délais de livraison via un service web REST.
- Contraintes :
- Conformité LPM (les contacts clients sont des données personnelles).
- Sécurité du réseau interne d’une zone industrielle (firewall uniquement autorisé sur TCP 443).
- Disponibilité ≥ 99 % pendant la haute saison (Nov–Feb).
5.2. Architecture initiale
[Internet] → [Load‑Balancer (HTTPS)] → [NGINX] → [Apache/php-dolibarr] → [MySQL]
↘ (certificat Let's Encrypt)- Service Web :
/dolibarr/json.php?module=product&action=getStock&id=XX - Authentification : token statique
apiKey=abc123intégré dans le script client (JavaScript) et transmis en query‑string (non‑chiffré). - Contrôle d’accès : Aucun rôle différencié, tous les usuarios disposaient du même niveau d’accès (lecture).
5.3. Analyse de sécurité (pentest interne)
| Étape | Résultat | Recommandation |
|---|---|---|
| Scan de ports | Open 80 & 443 exposés ; aucun firewall restrictif | Bloquer le port 80, n’autoriser que le 443 avec TLS 1.3 |
| Analyse du token | Stocké dans le code JS, visible via inspection du DOM | Utiliser OAuth2 mutualisé (client_id/client_secret) |
| Injection test | Injection de ' OR 1=1;-- dans id → affichage d’erreurs |
Escaper les paramètres, tests automatisés (PHPUnit) |
| CORS | Access-Control-Allow-Origin: * désactivé, mais aucune restriction |
Ajouter whitelist d’origines (ex : https://client.mansour.ma) |
| Rate‑limiting | Aucun | Limiter à 60 requêtes/min par IP (mod_evasive) |
| Logs | Absence de logs d’accès aux API | Activer access_log détaillé, rotation quotidienne |
6. Plan de sécurisation implémenté | Action | Détails techniques | Impact attendu |
|——–|——————–|—————-|
| 1️⃣ Migration vers HTTPS obligatoire | RewriteEngine On + SSLRequireSSL + certificat Let’s Encrypt renouvelable automatiquement. | Confidentialité des tokens, conformité LPM. |
| 2️⃣ Authentification renforcée | – Générer un client_id / client_secret via un script d’administration.
– Utiliser OAuth2 Authorization Code; les tokens sont signed JWT (RSA‑256).
– Stock du secret uniquement côté serveur (variables $conf['oauth_client_secret']). | Réduction drastique du risque de vol de token ; conformité RGPD‑Maroc. |
| 3️⃣ Refactorisation des appels API | – Supprimer les paramètres GET sensibles ; passer à POST avec corps JSON chiffré TLS.
– Utiliser PDO avec requêtes préparées partout.
– Ajouter un filtre de validation (filter_input(INPUT_POST, ...)). | Élimination des injections SQL, protection contre XSS. |
| 4️⃣ Whitelisting CORS | Modifier Access-Control-Allow-Origin dans le VirtualHost NGINX : add_header Access-Control-Allow-Origin "https://client.mansour.ma";. | Blocker les appels cross‑origin non autorisés. |
| 5️⃣ Rate‑limiting + throttling | Configurer mod_evasive : DavLockDB /var/www/html/dolibarr/dav_lock.db + LimitRequestBody 1048576.
Implémenter un compteur en base de données (api_rate_limit) qui bloque les IP dépassant 120 req/min. | Protection contre DoS ciblé sur le module stock. |
| 6️⃣ Journalisation & monitoring | – Logs api_access.log au format JSON (timestamp, IP, client_id, module, action, résultat).
– Envoi vers Graylog avec alertes sur 5 erreurs consécutives ou dépassement du seuil de taux. | Détection précoce des abus, conformité aux exigences de diagnostic dans le cadre du plan de continuité. |
| 7️⃣ Tests d’intrusion périodiques | Tous les 6 mois, simulateurs d’attaque (OWASP ZAP, Nmap) avec pentest externe. | Maintenir le niveau de sécurité à jour. |
| 8️⃣ Documentation et formation | – Politique de sécurité de l’information (ISO 27001) mise à jour.
– Sessions de sensibilisation pour les développeurs et le personnel administratif (phishing, fuite de token). | Culture de la sécurité, réduction des erreurs humaines. |
7. Résultats obtenus
| KPI | Valeur avant | Valeur après 6 mois |
|---|---|---|
| Temps moyen d’authentification | 12 ms (token statique) | 18 ms (OAuth2) – léger impact, mais sécurisé |
| Nombre de tentatives d’accès non‑autorisé (par mois) | 342 | 28 (détectées et bloquées) |
| Temps de disponibilité du service Web | 96,5 % | 99,7 % (conforme à la cible ≥ 99 %) |
| Incidents de fuite de données | 1 (exfiltration de contacts) | 0 |
| Coût de remédiation (déploiement, formation) | 0 (réactif) | 8 500 MAD (investissement unique) |
| Score d’audit interne (ISO 27001 – partie API) | 63 % | 92 % |
Analyse : La mise en œuvre d’OAuth2 et le chiffrement TLS ont éliminé les scénarios de vol de token. L’ajout de restrictions CORS et de rate‑limiting a réduit les attaques de type scan de ports et DoS. Le renforcement du pipeline SQL a supprimé toutes les tentatives d’injection détectées. Le service a maintenant un audit externe positif et la direction a validé le respect des obligations légales.
8. Bonnes pratiques à retenir pour les organisations marocaines | # | Pratique | Pourquoi |
|—|———-|———-|
| 1 | Utiliser exclusivement HTTPS avec certificats reconnus (Let’s Encrypt ou CA régionaux). | Conformité LPM (confidentialité) et ISO 27001 (contrôle de la transmission). |
| 2 | Ne jamais transmettre les secrets dans le code client (JS, flash, etc.). | Risque d’extraction par navigateur. |
| 3 | Passer à OAuth2 (client_id/client_secret) avec JWT signé. | Traçabilité, expiration contrôlée, protection contre le replay. |
| 4 | Faire valider chaque paramètre (type, longueur, valeur attendue) avant l’accès à la base de données. | Éviter les injections SQL. |
| 5 | Limiter les origines autorisées (CORS whitelist). | Bloquer les appels cross‑origin non autorisés. |
| 6 | Imposer des limites de fréquence (rate‑limit) par IP ou client. | Protéger contre les abus et les DoS. |
| 7 | Conserver des logs détaillés (API, authentification, erreurs). | Traçabilité pour audits et investigations. |
| 8 | Réaliser des tests d’intrusion au moins une fois par an (pentest, scans automatisés). | Détecter les nouvelles vulnérabilités. |
| 9 | Former les développeurs aux bonnes pratiques de sécurité (OWASP Top 10, secure coding). | Réduire les erreurs de conception. |
| 10| Intégrer la politique de sécurité dans le processus CI/CD (tests automatisés, scans de sécurité d’images Docker). | Garantir la continuité de la conformité. |
9. Conclusion
L’étude de cas de la coopérative Al‑Mansour montre que la mise en production d’un service Web Dolibarr dans un contexte marocain exige une approche holistique de la sécurité : chiffrement, contrôle d’accès fort, filtrage des entrées, gouvernance des logs et conformité légale.
En suivant le plan d’action décrit ci‑dessus, la coopérative a pu :
- Sécuriser les échanges de données sensibles, – Réduire les vecteurs d’attaque (injection, vol de token, DoS),
- Obtenir la conformité avec la loi marocaine sur la protection des données,
- Améliorer la disponibilité du service à 99,7 % pendant la période critique,
- Renforcer la confiance de ses partenaires exportateurs grâce à un niveau de sécurité reconnu.
Pour toute organisation marocaine souhaitant exploiter Dolibarr (ou tout autre ERP) via des API, la leçon principale est double : la sécurité ne peut être un add‑on après coup, elle doit être intégrée dès la conception. En adoptant les bonnes pratiques décrites—OAuth2, HTTPS obligatoire, CORS strict, rate‑limiting, journalisation et audits continus—il devient possible de tirer les bénéfices de la flexibilité du service Web tout en protégeant efficacement les données et les processus métier.
Sources & Références
- Dolibarr ERP‑CRM Documentation – API Web (version 22.0, 2024).
- Loi n° 09‑08 du 28 novembre 2009 relative à la protection des données à caractère personnel.
- ISO 27001:2022 – Annex A – Controls for API security.
- OWASP Testing Guide v4.2 – Sections API Security et Rate Limiting.
- Rapport d’audit interne « Sécurisation des API Dolibarr – Al‑Mansour », version 1.2, novembre 2025. —
À propos de l’auteur :
Dr. Youssef Benabdelkader, expert en sécurité des systèmes d’information, certifié CISSP et ISO 27001 Lead Auditor. Il travaille pour CyberSecure Morocco et intervient régulièrement en tant que conseiller en transformation digitale des PME marocaines. —
Fin de l’article.