Sécurité Dolibarr : API FAQ orienté conformité

Dolibarr ERP/CRM est une solution open source populaire, notamment auprès des TPE/PME. Son interface de programmation (API) REST, puissante et flexible, permet d’automatiser des processus et d’interconnecter des systèmes. Cependant, une API mal sécurisée peut devenir une faille critique, exposant des données sensibles et mettant en péril la conformité réglementaire (RGPD, ISO 27001, etc.).

Cette FAQ synthétise les questions essentielles sur la sécurisation de l’API Dolibarr dans une logique de conformité.

1. Authentification et gestion des accès

Q : Quels mécanismes d’authentification sont disponibles et recommandés pour respecter la confidentialité ?
R : Dolibarr supporte principalement l’authentification par clé API (token) ou par session utilisateur (via DOLAPIKEY ou cookie de session).

  • Recommandation conformité : Privilégiez les clés API longues et spécifiques à un usage (une clé par application ou service), associées à un compte utilisateur dédié aux accès API, avec des droits restreints au strict nécessaire (principe du moindre privilège). Évitez l’utilisation de comptes administrateurs pour les API. stockez les clés hors du code source (variables d’environnement, vaults).

Q : Comment gérer les permissions fines (lecture, écriture) pour chaque endpoint API ?
R : Le système de permissions de Dolibarr ("Permissions" dans le menu admin) s’applique aux appels API. Les autorisations sont définies par module (Société, Produits, Commandes, etc.) et par action (lire, créer, modifier, supprimer).

  • Recommandation conformité : Effectuez un audit complet des permissions par module pour le compte API. Désactivez systématiquement les actions "Supprimer" et "Modifier" sur les données sensibles (ex: infos clients, factures validées) si elles ne sont pas requises par le processus métier. Documentez cette matrice des droits.

2. Journalisation et traçabilité

Q : Dolibarr logue-t-il automatiquement les appels API ?
R : Oui. Dolibarr enregistre les appels API dans ses fichiers de log standards (souvent dolibarr.log), selon le niveau de configuration ($dolibarr_main_log_level). On y trouve l’utilisateur, l’IP source, l’URL appelée et le statut HTTP.

  • Recommandation conformité : Activez et centralisez ces logs dans un système de gestion des logs (SIEM) externe. Configurez un niveau de log adapté (au moins INFO) et conservez-les pendant la durée légale (ex: 6 ans pour des documents comptables en France). Les logs doivent être protégés contre toute altération.

Q : Que doit contenir une entrée de log pour être conforme (ex: RGPD – registre des activités de traitement) ?
R : Pour un traitement de données personnelles, le log doit idéalement permettre d’identifier :

  1. Qui : Identifiant du compte API/utilisateur.

  2. Quand : Horodatage précis (UTC).

  3. Quoi : Endpoint appelé, paramètres (sans données sensibles en clair !), action réalisée.

  4. Sur qui : ID de l’objet Dolibarr concerné (ex: rowid de la société), sans afficher les données personnelles elles-mêmes dans les logs (ex: ne pas logger le nom complet ou l’email dans l’URL).

  5. Résultat : Code HTTP (200, 403, 500…).

3. Protection des données en transit et au repos

Q : L’API Dolibarr est-elle chiffrée par défaut ?
R : Le chiffrement (HTTPS/TLS) dépend de la configuration de votre serveur web (Apache, Nginx). Dolibarr ne force pas l’HTTPS.

  • Recommandation conformité : Imposez systématiquement HTTPS pour tout accès à l’API. Utilisez TLS 1.2 ou 1.3 avec des suites de chiffrement fortes. Cela est impératif pour la confidentialité des données en transit (RGPD Art. 32).

Q : Comment sont stockées les clés API dans la base de données ?
R : Les clés (apikey) sont stockées en clair dans la table llx_user par défaut.

  • Recommandation conformité (avancée) : C’est un point faible. Pour une sécurité accrue, envisagez un hashage des clés API (comme pour les mots de passe) via un module personnalisé, bien que cela impose de les régénérer à l’usage. Si cela n’est pas possible, limitez strictement l’accès en lecture à la table user dans la base de données.

4. Limitations des risques (Rate Limiting, CORS)

Q : Comment se protéger contre les attaques par force brute sur l’API ?
R : Dolibarr n’a pas de mécanisme de limitation de taux (rate limiting) natif pour son API.

  • Recommandation conformité : Mettez en place un reverse proxy (Nginx, Apache, Cloudflare) en frontal pour :

    • Limiter le nombre de requêtes par IP/clé API (limit_req dans Nginx).

    • Bloquer les tentatives répétées d’authentification infructueuses.
      Cela protège contre le déni de service et les tentatives d’énumération.

Q : Faut-il configurer CORS (Cross-Origin Resource Sharing) ?
R : Par défaut, Dolibarr n’envoie pas d’en-têtes CORS, ce qui est sécurisant. Si votre application frontale (sur un autre domaine) doit appeler l’API, vous devrez configurer les en-têtes Access-Control-Allow-Origin de manière très précise (domaine spécifique, pas de *).

  • Recommandation conformité : Ne jamais autoriser Access-Control-Allow-Origin: * pour une API authentifiée. Listez les origines explicitement autorisées. Configurez également Access-Control-Allow-Credentials: true si les credentials (cookies) sont utilisés.

5. Conformité réglementaire spécifique

Q : L’utilisation de l’API Dolibarr doit-elle être déclarée dans le registre des traitements (RGPD) ?
R : Oui. Tout traitement de données à caractère personnel (DCP) via l’API (ex: interrogation/modification de fiches clients, fournisseurs, contacts) est une activité de traitement. Le registre doit mentionner :

  • La finalité (ex: "Synchronisation automatisée des clients avec l’outil de marketing").

  • Les catégories de données concernées.

  • Les destinataires (le service/application qui consomme l’API).

  • Les mesures de sécurité mises en œuvre (authentification forte, logs, chiffrement).

Q : Comment gérer le droit à l’oubli (effacement) avec l’API ?
R : L’API permet d’supprimer des objets (DELETE /api/index.php/…). Cependant, la suppression physique dans Dolibarr peut être désactivée (archivage par défaut). La conformité au "droit à l’oubli" nécessite souvent une anonymisation (suppression des chails DCP) plutôt qu’une suppression technique.

  • Recommandation conformité : Définissez une procédure claire : soit l’appel API déclenche une fonction personnalisée d’anonymisation, soit il utilise un endpoint dédié qui supprime/archiève de manière irréversible et journalise cet acte critique. Ne pas exposer une simple suppression sans contrôle.

6. Bonnes pratiques opérationnelles

Q : Faut-il surveiller l’API en dehors des logs ?
R : Absolument. Les logs sont passifs. Une surveillance active est cruciale :

  • Alerting : Surveillez les pics d’erreurs 4xx/5xx, les tentatives d’accès depuis des IP inhabituelles.

  • Health Check : Implémentez un endpoint de health check simple pour vos outils de monitoring (ex: /api/index.php/status).

  • Revue régulière : Auditez périodiquement les clés API actives, les permissions des comptes dédiés et les logs d’accès.

Q : Comment sécuriser les développements personnalisés utilisant l’API ?
R : Le plus grand risque vient souvent des applications externes qui consomment l’API.

  • Recommandation conformité : Appliquez aux développements qui utilisent l’API les mêmes règles que pour tout code applicatif :

    • Validation stricte des entrées (surtout si paramètres en POST/PUT).

    • Gestion robuste des erreurs (ne pas fuiter d’informations système dans les réponses).

    • Revue de code axée sur la sécurité.

    • Rotation périodique des clés API utilisées par ces applications.

Conclusion

Sécuriser l’API Dolibarr n’est pas une option, mais une condition sine qua non à sa conformité. Cela repose sur une triple approche :

  1. Configuration stricte de Dolibarr et de son environnement (HTTPS, permissions minimales).

  2. Infrastructure de protection en amont (reverse proxy pour rate limiting, WAF).

  3. Gouvernance et supervision continue (logs centralisés, registre des traitements, audits audits).

Ne considérez jamais l’API comme une simple "interface technique". Elle est une frontière de sécurité qui donne un accès programmable à votre système d’information. Sa sécurisation doit être pensée dès la conception et réévaluée régulièrement à l’aune des menaces et des obligations légales.

Recommandation ultime : Avant toute exposition de l’API Dolibarr à l’extérieur (internet ou réseau non totalement maîtrisé), faites réaliser un test de pénétration (pentest) spécifique à l’API par un tiers indépendant. C’est la seule façon d’identifier les vecteurs d’attaque concrets.

Publications similaires