Odoo Security Best Practices: Hardening Your Server in 2026

Odoo instances contain valuable business data: customer information, financial records, pricing strategies, and supplier contacts. A compromised Odoo server can lead to data theft, ransomware, or business disruption.

Small and mid-size Odoo deployments are frequent targets because they often run with default configurations, weak passwords, no firewall rules, and unpatched software. Attackers scan the internet for Odoo login pages, attempt credential stuffing with leaked password databases, and exploit known vulnerabilities in outdated Odoo versions.

The PostgreSQL database password is in /etc/odoo/odoo.conf in plain text. If an attacker gains read access to this file, they have direct database access.

What to do:

• Generate a random 32-character password: openssl rand -base64 32
• Update db_password in odoo.conf
• Restart Odoo and PostgreSQL
• Never reuse this password anywhere else

Set file permissions:
sudo chmod 600 /etc/odoo/odoo.conf
sudo chown odoo:odoo /etc/odoo/odoo.conf

This ensures only the odoo user can read the config file.

By default, PostgreSQL listens on all network interfaces. This means anyone who can reach your server on port 5432 can attempt to connect to the database.

Edit /etc/postgresql/*/main/postgresql.conf:
listen_addresses = 'localhost'

Edit /etc/postgresql/*/main/pg_hba.conf and ensure only local connections are allowed:
local all all peer
host all all 127.0.0.1/32 md5

Restart PostgreSQL:
sudo systemctl restart postgresql

Now PostgreSQL only accepts connections from the same server where Odoo runs.

An open firewall is an invitation. Close all ports except those you explicitly need.

Ports to allow:

• 22 (SSH) — restrict to your office IP if possible
• 80 (HTTP) — for Let's Encrypt renewal
• 443 (HTTPS) — for Odoo web interface

Block everything else:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Advanced: Restrict SSH to specific IPs
If your office has a static IP, allow SSH only from that IP:
sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR_OFFICE_IP to any port 22

This blocks SSH brute-force attacks from the internet.

The Odoo database manager (accessible at /web/database/manager) allows anyone to create, drop, duplicate, or restore databases if the master password is weak or default.

In odoo.conf, set:
list_db = False

This disables the database selector and manager interface. Users can only access the database specified in db_name or via db_filter. The database manager becomes unreachable even if someone knows the master password.

Security vulnerabilities are discovered regularly in Odoo, Python libraries, and system packages. Unpatched servers are easy targets.

Monthly maintenance checklist:
1. Check Odoo's GitHub releases for security patches
2. Update Odoo to the latest minor version (e.g., 17.0.5 → 17.0.6)
3. Update system packages: sudo apt update && sudo apt upgrade
4. Update Python dependencies: pip install --upgrade -r requirements.txt
5. Restart Odoo after updates: sudo systemctl restart odoo

Subscribe to security announcements:

• Odoo security advisories: https://www.odoo.com/security
• Ubuntu security notices: https://ubuntu.com/security/notices

If a critical CVE is announced, patch immediately — do not wait for the next monthly cycle.

Running Odoo over HTTP transmits passwords, session tokens, and data in plain text. Anyone on the network path can intercept credentials.

Use Let's Encrypt (free, auto-renewing):
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d odoo.yourcompany.com

Certbot automatically configures Nginx to:

• Redirect HTTP → HTTPS
• Use strong cipher suites
• Enable HSTS (HTTP Strict Transport Security)

Test your SSL configuration:
https://www.ssllabs.com/ssltest/

Aim for an A+ rating. If you score lower, adjust cipher suites and enable OCSP stapling.

Brute-force attacks on /web/login are common. Attackers try thousands of username/password combinations from leaked databases.

Nginx rate limiting:
Add to /etc/nginx/sites-available/odoo:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /web/login {
limit_req zone=login burst=2;
proxy_pass http://127.0.0.1:8069;
}

This allows 5 login attempts per minute per IP, with a burst of 2. Further attempts receive a 503 error.

Reload Nginx:
sudo systemctl reload nginx

Fail2ban (system-wide protection):
sudo apt install fail2ban

Configure a jail for Odoo in /etc/fail2ban/jail.local:
[odoo]
enabled = true
port = http,https
filter = odoo
logpath = /var/log/odoo/odoo-server.log
maxretry = 5
bantime = 3600

This bans IPs that trigger 5 failed login attempts within 10 minutes.

Employees leave, roles change, and contractors finish projects — but their Odoo accounts often remain active with full access.

Quarterly user audit:
1. Review all active users in Settings → Users & Companies
2. Disable accounts for users who no longer need access
3. Remove "Administrator" rights from users who do not need full system access
4. Verify multi-company access rules are correct
5. Check API keys and deactivate unused ones

Principle of least privilege:
Each user should have the minimum access required to do their job. A warehouse worker does not need accounting module access. A salesperson does not need Settings access.

ServerChest includes security-focused features in its monitoring and audit system:

Real-time alerts:

• SSH login attempts from unknown IPs
• Failed Odoo login bursts (potential brute-force)
• Firewall rule changes
• Unauthorized sudo commands

Audit log:
Every action taken via ServerChest (backup, restart, config change) is logged with timestamp, user, and IP. This creates accountability and makes post-incident investigation possible.

Automatic updates:
ServerChest can notify you when Odoo security patches are released, or automatically apply system package updates on a schedule you control.

Backup encryption:
Backups can be encrypted with AES-256 before upload to cloud storage, ensuring that even if someone gains access to your Google Drive or S3 bucket, they cannot read the data.