Sécurité Odoo : vérifier son instance auto-hébergée

La sécurité Odoo sur votre serveur commence par un gestionnaire de bases inaccessible depuis Internet, une entrée HTTPS unique et des comptes administrateurs restreints. Viennent ensuite les correctifs et les sauvegardes restaurables. Une ligne dans odoo.conf ne prouve rien tant que vous n'avez pas vérifié le service qui tourne.

Cette check-list concerne Odoo 20, Community et Enterprise. Documentation et code source vérifiés le 2 novembre 2026. Prévoyez une heure pour le premier état des lieux, pas pour toutes les corrections ni une restauration complète. Les contrôles portent uniquement sur une instance que vous administrez, sans suppression de base.

Attribuez les responsabilités avant de toucher au serveur#

En auto-hébergement, vous gérez le système, PostgreSQL et l'exposition réseau. Le guide de déploiement Odoo (nouvel onglet) sert de référence aux réglages ci-dessous. Les engagements de sécurité d'Odoo pour son cloud ne s'appliquent pas automatiquement à un serveur loué ailleurs.

Le guide des hébergements Odoo aide à choisir ce partage. Notez qui intervient sur chaque couche avant une modification en production. Une tâche sans responsable reste souvent en attente.

La sécurité Odoo passe par le gestionnaire de bases#

Le gestionnaire peut créer, sauvegarder et supprimer des bases. Ne l'exposez pas sur Internet. Son mot de passe maître, admin_passwd, est distinct du mot de passe d'un utilisateur Odoo et de celui de la connexion PostgreSQL.

Pour une instance Odoo 20 dédiée à une seule base, adaptez cet exemple au nom exact de votre base :

[options]
db_name = acme_prod
dbfilter = ^acme_prod$
list_db = False

Définissez séparément admin_passwd avec un secret long et aléatoire. Restreignez la lecture du fichier de configuration et ne le collez jamais dans un ticket. Après rechargement ou redémarrage selon votre déploiement, vérifiez quel fichier le service utilise. Sur une installation multibase existante, testez la sélection avant de désactiver la liste.

dbfilter sélectionne la base, sans remplacer la protection des routes d'administration. Dans Odoo 20, le gestionnaire peut encore renvoyer une page HTML avec list_db = False. Une réponse HTTP réussie ne dit donc pas si ses opérations sont autorisées.

Bloquez aussi ces routes au reverse proxy. Pour cet exemple monobase, ajoutez ce bloc dans le serveur HTTPS Nginx existant :

location ^~ /web/database {
    return 403;
}

Validez la configuration Nginx avant de la recharger. Depuis une machine extérieure au serveur, lancez ensuite :

curl -sS -o /dev/null -w '%{http_code}\n' \
  https://erp.example.com/web/database/manager

Avec cette règle, le résultat attendu est 403, pas une redirection vers un gestionnaire utilisable. Contrôlez aussi /web/database/selector, volontairement bloqué. Si vous devez administrer les bases, conservez un accès distinct et restreint.

La CVE-2026-25137 (nouvel onglet) concerne le paquet NixOS et un gestionnaire exposé dont le mot de passe ne persistait pas. Elle ne touche pas toutes les installations Odoo. Si vous utilisez ce paquet, suivez son avis et cherchez les requêtes /web/database dans les journaux d'accès.

Exposez HTTPS, pas les ports internes#

Activez proxy_mode uniquement derrière un reverse proxy de confiance. Celui-ci doit définir lui-même les en-têtes transmis. Un client ne doit pas pouvoir le contourner pour fournir directement à Odoo des en-têtes considérés comme fiables.

Avec un proxy sur le même hôte, faites écouter Odoo sur la boucle locale. Avec des conteneurs ou des machines séparées, restreignez plutôt le réseau interne et le pare-feu. Une adresse de boucle locale copiée dans un conteneur peut empêcher le proxy de le joindre.

En mode multiprocessus, Odoo utilise normalement 8069 pour HTTP et 8072, le port gevent, pour les websockets. Routez /websocket/ vers le bon port. Le port gevent séparé ne sert pas en mode multithread par défaut.

Depuis une machine extérieure autorisée, contrôlez l'adresse réelle du serveur :

nmap -Pn -p 443,8069,8072,5432 ADRESSE_IP

HTTPS doit être joignable, les ports Odoo internes et PostgreSQL fermés ou filtrés depuis ce réseau. Recommencez en IPv6 si le serveur dispose d'une adresse publique IPv6. Vérifiez aussi dans un navigateur le certificat, la redirection HTTPS et les notifications en direct : un port 443 ouvert ne prouve rien de tout cela.

Protégez les comptes et les accès des intégrations#

Imposez la double authentification aux employés, surtout aux administrateurs. La documentation 2FA d'Odoo 20 (nouvel onglet) décrit deux périmètres : employés uniquement ou tous les utilisateurs. Le second inclut le portail. Testez votre choix avec un compte distinct avant de le généraliser.

Gardez des comptes administrateurs nominatifs et une procédure de récupération documentée, puis testez les accès avec un utilisateur ordinaire : ne pas pouvoir ouvrir les Paramètres ne prouve pas que les règles d'enregistrement empêchent de consulter les données d'une autre société. Testez les enregistrements eux-mêmes.

Attribuez à chaque intégration un utilisateur dédié aux permissions limitées. Inventoriez les identifiants API, révoquez les accès inutilisés et vérifiez que l'intégration ne peut pas lire des données étrangères à sa fonction. L'activation de la 2FA interactive ne prouve pas qu'un identifiant d'intégration déjà émis est protégé.

Vérifiez le code réellement déployé après chaque correctif#

Un correctif protège l'instance quand le processus utilise le code corrigé. Notez la révision ou le digest de l'image déployée. Mettez à jour les builds de votre branche Odoo, mais aussi le système, PostgreSQL et les modules tiers.

Répétez la mise à jour sur une copie isolée avec vos modules spécifiques, puis redémarrez la production selon votre procédure de livraison et revérifiez sa révision. Appliquer des correctifs au sein d'une version diffère d'une migration vers une autre version d'Odoo. Ne remplacez pas un correctif de sécurité par un saut de version non testé.

Restaurez la base et le filestore sur une autre instance#

Sauvegardez ensemble la base et le filestore. Le guide Odoo recommande des sauvegardes quotidiennes copiées vers un serveur d'archivage distant inaccessible au serveur applicatif lui-même. Contrôlez la rétention et les identifiants, pas seulement le dernier message de réussite.

Restaurez dans un environnement isolé, avec les e-mails sortants et les intégrations désactivés. Ouvrez un enregistrement et téléchargez sa pièce jointe. Notez la durée de reprise et la période de données manquantes : ces mesures permettent de juger votre objectif de récupération.

Le rôle PostgreSQL de l'application ne doit pas être superutilisateur. Faites examiner la propriété des bases et le privilège CREATEDB avant de les modifier : un changement mal préparé peut casser la maintenance ou la restauration.

Conservez une check-list avec ses preuves#

• Nommer les responsables et noter la révision Odoo déployée.
• Vérifier le filtre de base et la désactivation de la liste.
• Obtenir le refus attendu du proxy sur les routes de gestion.
• Contrôler les ports depuis l'extérieur, y compris en IPv6.
• Tester la 2FA et les permissions des intégrations.
• Restaurer la base et le filestore sur une instance isolée.

Conservez les résultats datés près de la configuration, sans secrets. Pour comparer ces responsabilités avec une plateforme en libre accès, essayez Ofleet et vérifiez les réglages que vous pilotez vous-même. Le guide du dimensionnement d'un serveur Odoo vous aide à préparer une instance de test séparée.