The Ultimate Securing Odoo Instance Checklist: 12 Critical Steps

Odoo is the central nervous system for thousands of businesses, managing everything from CRM and accounting to inventory and HR. A security breach isn't just a data leak; it's a catastrophic event that can halt operations, damage customer trust, and incur massive financial penalties. Yet, a surprising number of production Odoo instances are deployed with near-default configurations, leaving them exposed to common and preventable attacks.

Hardening an Odoo instance is not a one-time task but a continuous process of vigilance. This comprehensive checklist moves beyond the basics, providing actionable steps and expert insights to build a robust security posture. Follow this 12-point guide to transform your Odoo environment from a potential liability into a secure business asset.

Foundational Hardening: Secure Your odoo.conf File

Your odoo.conf file is the primary control panel for your instance's security posture. A few incorrect lines in this file can undermine all other security efforts. Treat this file as a sensitive asset and ensure it's configured for production, not development.

Key directives include:

• proxy_mode = True: This is non-negotiable when running Odoo behind a reverse proxy like Nginx or Caddy. It ensures Odoo correctly handles X-Forwarded-For headers, which is critical for accurate logging and preventing IP spoofing.
• list_db = False: In a production environment, your users should never see the database manager page (/web/database/manager). Disabling this prevents attackers from enumerating, copying, or dropping your databases.
• admin_passwd = [HASHED_PASSWORD]: This sets a master password required to perform database operations through the manager interface. Even with list_db = False, this should be set to a strong, securely generated hash (e.g., using pbkdf2_sha512) as a defense-in-depth measure. Never store it in plaintext.
• xmlrpc_interface = 127.0.0.1: This directive binds the XML-RPC service to the local loopback interface. This means the service is not directly exposed to the external network, forcing all traffic to go through your reverse proxy, where you can apply further security rules.

# Example secure odoo.conf for production
[options]
admin_passwd = $pbkdf2-sha512$25000$.... ; A strong, hashed master password
proxy_mode = True

# Bind services to localhost; your reverse proxy will handle external access
xmlrpc_interface = 127.0.0.1
longpolling_port = 8072

# Disable features not needed in production
list_db = False
netrpc = False
debug_mode = False

Enforce HTTPS and Modern Security Headers

Transmitting business data over unencrypted HTTP is unacceptable. All communication between your users and your Odoo server must be encrypted using TLS (SSL). Configure your reverse proxy to handle TLS termination and automatically redirect all HTTP requests to HTTPS.

Go a step further by implementing the Strict-Transport-Security (HSTS) header. This tells browsers to only connect to your site using HTTPS for a specified period, eliminating the risk of protocol downgrade attacks and SSL stripping.

Isolate and Secure the Server Environment

Your Odoo application's security depends on the security of the underlying server. Follow these best practices:

• Run as an Unprivileged User: The Odoo process should never run as root. Create a dedicated system user (e.g., odoo) with restricted permissions. This limits the potential damage an attacker can cause if they achieve remote code execution through an application vulnerability.
• Implement a Firewall: Use a host-based firewall like UFW (Uncomplicated Firewall) or iptables to restrict network access. By default, deny all incoming traffic and only explicitly allow connections on necessary ports (e.g., 22 for SSH, 80 for HTTP redirect, and 443 for HTTPS).
• Database Isolation: Whenever possible, run your PostgreSQL database on a separate server or, at minimum, configure it to only accept connections from the Odoo application server's IP address. Secure your pg_hba.conf file to prevent unauthorized access.

Master User Access Control with the Principle of Least Privilege

The Principle of Least Privilege (PoLP) dictates that a user should only have access to the specific data and functions necessary to perform their job. Odoo's access control system is powerful but often misconfigured.

Regularly audit your users and groups, paying close attention to:

• Over-privileged Users: Who has "Settings" or "Administrator" access? Does the sales team really need access to accounting reports? Remove users from powerful groups like base.group_system and base.group_no_one (Technical Features) unless absolutely essential.
• Stale Accounts: Deactivate accounts for employees who have left the company immediately. A forgotten admin account is a ticking time bomb.
• Shared Accounts: Prohibit the use of shared accounts. Accountability is impossible when you can't trace actions back to a specific individual.

Decommission the Default 'admin' User Immediately

The default admin user is a universal target for brute-force attacks. Every automated scanner and malicious actor will try the username admin with a list of common passwords. Keeping it active is an open invitation for an attack.

The correct procedure is not just to change the password, but to disable the account entirely:

1. Create a new user with a different, non-obvious username (e.g., sysadmin.yourcompany).
2. Assign this new user to the "Settings / Administrator" group.
3. Log in as the new administrator to confirm access.
4. Log back in as the original admin, navigate to Users, and deactivate the default admin account.

Lock Down API Endpoints (XML-RPC & JSON-RPC)

Odoo's XML-RPC and JSON-RPC endpoints are essential for integrations but are also powerful vectors for brute-force login attempts and other automated attacks. If you do not use external applications to connect to Odoo, block these endpoints entirely at your reverse proxy.

If you do need API access for specific services, restrict it to known, static IP addresses. This is one of the most effective ways to reduce your attack surface.

# Nginx configuration to block XML-RPC access except for a trusted IP
location /xmlrpc/ {
 allow 203.0.113.50; # Allow your trusted service IP
 allow 127.0.0.1; # Allow localhost
 deny all; # Block everyone else

 proxy_pass http://127.0.0.1:8069;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

The Hidden Dangers in Custom Modules: A Code Audit Guide

While Odoo's core code is vetted for security, custom modules from third-party developers or your own team are the number one source of vulnerabilities in most installations. A manual code audit is critical.

Look for these common red flags:

• Raw SQL Queries: Any use of cr.execute() with Python string formatting (%s, .format(), f-strings) is a potential SQL injection vulnerability. Always use parameterized queries: cr.execute("SELECT ... WHERE id = %s", (variable,)).
• Access Control Bypass: The use of .sudo() in controller code is extremely dangerous. It elevates privileges and bypasses all record rules and access rights. If used, it must be preceded by rigorous validation to ensure a user cannot access data they are not authorized to see.
• Hardcoded Credentials: Never store API keys, passwords, or other secrets directly in your Python code. Use Odoo's system parameters or a secure external vault.
• Cross-Site Scripting (XSS): Ensure any data rendered in QWeb templates is properly escaped, especially if it originates from user input. Be wary of using t-raw unless you have explicitly sanitized the content.

Watch Out For: Common Odoo Security Mistakes

Beyond the major points, several common missteps can compromise your instance:

• Leaving Debug Mode On: Never run a production server with debug=True. Debug mode exposes detailed stack traces and other internal application data that can provide attackers with a roadmap of your system.
• Ignoring PostgreSQL Security: Odoo's security is moot if your database is wide open. Ensure your pg_hba.conf is configured to only allow trusted connections, and use a strong, unique password for the Odoo database user.
• Using Default Attachments Storage: By default, Odoo stores attachments in the database. For performance and security, configure it to use filestore storage (ir_attachment.location), which stores them on the filesystem outside the database, and ensure this directory is not web-accessible.
• Outdated Dependencies: Your Odoo instance relies on system libraries (like libxml2, openssl) and Python packages. Keep them updated to patch vulnerabilities that exist outside of the Odoo application code itself.

Maintain a Strict Update and Patching Cadence

Odoo regularly releases security patches for supported versions. You must have a process to apply these updates promptly. Subscribe to Odoo's security advisories. Running an outdated version, especially one that is End-of-Life (EOL), means you are not receiving patches for newly discovered vulnerabilities.

This also applies to community modules. A module from the Odoo App Store might not be actively maintained. Vet your third-party addons and be prepared to patch them yourself if the author becomes unresponsive.

Implement and Test a Bulletproof Backup Strategy

Security is also about resilience. In the event of a breach, data corruption, or ransomware attack, your backups are your last line of defense. A backup strategy isn't complete until it's tested.

Follow the 3-2-1 rule:

• 3 Copies of your data (your live database + 2 backups).
• 2 Different Media (e.g., on your server's disk and in cloud storage like S3).
• 1 Off-site Copy (the cloud copy).

Automate daily backups of your database and your filestore. Crucially, schedule a quarterly or semi-annual drill where you perform a full restore of a backup to a staging server. A backup you can't restore is worthless.

Final Thoughts: A Layered Approach

Securing an Odoo instance requires a layered, defense-in-depth strategy. No single control is foolproof. By combining server hardening, meticulous Odoo configuration, rigorous access control, proactive code auditing, and a robust recovery plan, you create a resilient environment that can withstand threats and protect your critical business operations. For those looking to automate this process, consider exploring tools and services that can provide continuous monitoring and auditing capabilities.