Automatiser web service dans Dolibarr : Framework avec une approche sécurité

Dolibarr ERP & CRM est une solution open source populaire pour la gestion d’entreprise, mais son offre native en matière d’API REST peut être limitée pour des intégrations complexes. Pour pallier cela, beaucoup d’organisations développent leurs propres services web automatisés. Cependant, ouvrir Dolibarr à des échanges externes sans une approche sécurité rigoureuse expose l’ERP à des risques majeurs : fuites de données, attaques par injection, accès non autorisés.

Cet article propose une architecture de framework pour créer des services web automatisés dans Dolibarr, en intégrant dès la conception les principes essentiels de sécurité.

1. Pourquoi un framework personnalisé ?

Dolibarr propose une API REST basique (module api), mais elle présente des limites :

  • Gestion fine des permissions limitée.

  • Pas de mécanisme natif robuste d’authentification (clés API simples).

  • Absence de validation poussée des payloads.

  • Journalisation (logging) minimaliste.

Un framework dédié permet de :

  • Centraliser la logique métier.

  • Appliquer uniformément des contrôles de sécurité.

  • Faciliter la maintenance et l’évolution.

2. Architecture recommandée du framework

2.1. Structure en couches

  • Contrôleurs (Entry points) : Point d’entrée HTTP, responsables de l’authentification initiale, de la validation des en-têtes et du routage.

  • Services (Métier) : Contiennent la logique métier, sans aucune dépendance HTTP. Ils appellent les classes natives de Dolibarr (ex: $object->fetch(), $db->query()).

  • Couche de données (Facultatif) : Pour complexifier, une couche d’abstraction aux requêtes Dolibarr peut être ajoutée.

  • Modèles de sécurité : Classes dédiées aux vérifications de permissions, validation des entrées, chiffrement.

2.2. Intégration dans Dolibarr

  • Créer un module personnalisé (ex: mymodule).

  • Définir une page d’accueil pour le service (ex: /mymodule/api/endpoint).

  • Utiliser le bootstrap Dolibarr (define('NOCSRFCHECK', 1); en haut du script pour désactiver la vérification CSRF Dolibarr, mais seulement après avoir mis en place vos propres protections).

3. Approche sécurité : Les fondamentaux incontournables

3.1. Authentification & Autorisation

  • Éviter les clés API statiques en dur. Préférer :

    • OAuth 2.0 (Client Credentials ou Authorization Code) avec un serveur d’autorisation dédié (Keycloak, ou service maison). Le jeton d’accès (JWT signé) est ensuite présenté à Dolibarr.

    • Certificats TLS mutuels (mTLS) pour une authentification forte machine-à-machine.

  • Intégrer les permissions Dolibarr : Vérifier systématiquement que l’utilisateur/le jeton associé a les droits Dolibarr requis ($user->hasRight('mymodule', 'read')).

  • Gestion des rôles : Mapper les rôles externes (ex: "partenaire_logistique") aux groupes/utilisateurs Dolibarr.

3.2. Validation des entrées & prévention des injections

  • Valider toutes les entrées (paramètres GET/POST, JSON payload) avec des règles strictes (type, format, plage).

  • Utiliser les requêtes préparées (prepared statements) pour toutes les interactions avec la base de données ($db->prepare() et $db->execute()).

  • Échapper les sorties si le service renvoie des données qui seront affichées dans un navigateur (XSS).

  • Limiter la taille des payloads (post_max_size, upload_max_filesize dans .htaccess ou config PHP).

3.3. Chiffrement

  • Imposer HTTPS (TLS 1.2+). Configurer le serveur web (Apache/Nginx) pour rediriger tout le trafic HTTP vers HTTPS.

  • Ne jamais stocker de mots de passe ou secrets en clair. Utiliser password_hash() pour les mots de passe utilisateurs, et un coffre-fort (vault) pour les secrets techniques (clés API externes, certificats).

3.4. Journalisation (Logging) et surveillance

  • Tout logger : Tentatives d’authentification (réussies/échouées), accès aux données sensibles, erreurs métier.

  • Masquer les données sensibles dans les logs (numéros de compte, informations personnelles).

  • Centraliser leslogs vers un système SIEM (ex: Graylog, ELK) pour détecter des anomalies.

  • Implémenter une limitation de débit (rate limiting) par IP/client pour prévenir les attaques par force brute.

3.5. Gestion des sessions et des tokens

  • Pour les authentifications par session web : Utiliser les sessions PHP natives de Dolibarr mais avec session.cookie_httponly = 1, session.cookie_secure = 1, et régénérer l’ID de session après l’authentification.

  • Pour les tokens API :

    • Durée de vie courte (ex: 1 heure).

    • Révocation immédiate possible.

    • Stockage sécurisé en base (hachage, comme pour les mots de passe).

    • Rotation automatique des secrets.

4. Exemple de code sécurisé (conceptuel)

// mymodule/public/api/create_order.php

define('NOCSRFCHECK', 1); // Désactive CSRF Dolibarr, mais on met en place nos propres vérifications

require '../../main.inc.php';
// 1. Vérifier HTTPS

if (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === "off") {

    http_response_code(403);

    echo json_encode(['error' => 'HTTPS requis']);

    exit;

}
// 2. Authentifier via JWT (exemple简化)

$authHeader = $_SERVER['HTTP_AUTHORIZATION'] ?? '';

if (!preg_match('/Bearer\s(\S+)/', $authHeader, $matches)) {

    http_response_code(401);

    exit;

}

$jwt = $matches[1];

$user = verifyJwtAndGetDolibarrUser($jwt); // Fonction maison externe

if (!$user || !$user->hasRight('commande', 'creer')) {

    http_response_code(403);

    exit;

}
// 3. Lire et valider le payload JSON

$input = json_decode(file_get_contents('php://input'), true);

if (!is_array($input)) {

    http_response_code(400);

    echo json_encode(['error' => 'JSON invalide']);

    exit;

}
// Validation stricte des champs attendus

$required = ['ref_client', 'lignes', 'date'];

foreach ($required as $field) {

    if (empty($input[$field])) {

        http_response_code(400);

        echo json_encode(['error' => "Champ manquant: $field"]);

        exit;

    }

}
// 4. Logging sécurisé (sans données sensibles)

error_log("API CreateOrder: user_id={$user->id}, ref_client={$input['ref_client']}, date={$input['date']}");
// 5. Traitement métier dans le service (requêtes préparées)

$service = new OrderCreationService($db);

try {

    $orderId = $service->createFromExternalData($input, $user);

    echo json_encode(['success' => true, 'order_id' => $orderId]);

} catch (Exception $e) {

    // Log l'erreur technique, retourner un message générique à l'utilisateur

    error_log("Erreur création commande API: " . $e->getMessage());

    http_response_code(500);

    echo json_encode(['error' => 'Erreur interne']);

}

5. Bonnes pratiques additionnelles

  • Séparer les environnements : Development, pré-production, production avec des jeux de données et identifiants différents.

  • Scanner les dépendances : Utiliser composer audit pour vérifier les vulnérabilités des librairies PHP.

  • Realiser des tests d’intrusion (pentests) réguliers sur l’API.

  • Documenter l’API avec OpenAPI/Swagger, en précisant les Droits requis et les formats attendus.

  • Former les développeurs aux risques OWASP Top 10 (injections, broken authentication, etc.).

6. Conclusion

Automatiser Dolibarr via des services web est un puissant levier d’intégration, mais la sécurité ne doit pas être une option. En adoptant une architecture en couches, en forçant l’authentification forte, en validant agressivement les entrées et en journalisant soigneusement, vous construisez une passerelle robuste et fiable.

Souvenez-vous : la sécurité est un processus, pas un produit. Votre framework doit évoluer avec les menaces. Commencez par ces bases, auditez régulièrement, et n’hésitez pas à consulter un expert en sécurité pour les déploiements à fort enjeu.

« Mieux vaut prévenir que guérir » – cette maxime n’a jamais été aussi vraie que dans le contexte d’un ERP exposé sur le web.

Publications similaires