Odoo Security on Your Own Server: A Practical Hardening Checklist

Keep Odoo, the Operating System and PostgreSQL Patched

Odoo publishes security advisories for Community and Enterprise as issues marked [SEC] in its GitHub repository, and patches Odoo Online and Odoo.sh as soon as a fix is available. On your own server, a fix only arrives when you install it.

• Install the latest build of your Odoo version regularly, from GitHub or Odoo's download page. Odoo's update guide recommends a complete, up-to-date version rather than applying individual patches.
• Remember that updating is not upgrading. An update installs the latest revision of the same version and leaves your data alone; an upgrade moves the database to a new major version.
• Apply operating system and PostgreSQL security updates on a schedule, not only when something breaks.
• Test updates on a neutralized copy first, and take a backup before touching production, as described in our Odoo backup strategy.
• Never install demo data on internet-facing servers, test copies included. Demo databases contain default logins and passwords.

Firewalls and Network Rules

• Expose only ports 80 and 443 to the internet. Odoo's ports and PostgreSQL, which listens on port 5432 by default, should answer only where they must.
• Restrict PostgreSQL in pg_hba.conf to the Odoo host, and never open it to the internet.
• Allow SSH with keys only, ideally through a VPN or from trusted addresses, and run brute-force protection such as fail2ban.
• Apply an outbound default-deny rule, then allow only what Odoo needs: your mail server, the banks and payment providers you integrate with and, for Enterprise, services.odoo.com on port 80, which Odoo's weekly update notification uses to validate the subscription.
• If Odoo sits behind a web application firewall or a DDoS protection service, accept connections only from that service's published address ranges.
• Host staging and test copies on separate machines from production, with the same precautions.

Users, Passwords and Two-Factor Authentication

Many incidents start with an account rather than a server. Odoo's guide asks for unique logins and strong passwords for every administrator, no login called admin, no default passwords even on test databases, and administrator accounts kept for administration rather than daily work.

• In Settings, under Permissions, tick Enforce two-factor authentication for employees only or for all users, portal users included. Ask everyone to add an authenticator app from the security tab of My Profile.
• Install the Password Policy module and raise the Minimum Password Length, which defaults to 8.
• Give each person the lowest access level that lets them work, and keep the Settings administrator role to a few named people.
• Connect integrations through a dedicated user with only the rights they need, using API keys. Odoo 19 asks for a description and a duration for each key, so name it clearly and let it expire.
• Archive leavers on their last day, and review the devices listed on each user's profile, revoking any that should no longer be signed in.

Server, hosting and domain credentials deserve the same care. Our free SBS Password Manager keeps them inside Odoo, encrypted with a key held outside the database, revealed only after an identity check to people named on each record, and logged every time someone looks. It is built and tested on Odoo 19 Community and listed for Odoo.sh and on-premise installations, not Odoo Online. Its Copy button needs HTTPS, one more reason to finish the proxy step.

Monitor Logs and Block Brute-Force Attempts

Odoo writes a log entry for every login attempt, with the result, the login and the source IP address, in a line that reads "Login failed for db:... login:... from ...". That makes failed logins easy to watch:

1. Make sure Odoo logs to a file that is rotated, and keep the proxy's access and error logs.
2. Point a fail2ban filter at the failed-login lines and ban an address after repeated failures. Odoo's guide shows a jail that blocks an address for 15 minutes after 10 failures within one minute.
3. Add rate limiting on the proxy for the login page and the API.
4. Alert on what matters: bursts of failures, new administrator accounts, certificate expiry, a filling disk and missed backups.
5. Review alerts weekly, and keep logs long enough to investigate an incident after the event.

An Odoo Security Hardening Checklist

• HTTPS only, with HTTP redirected and a valid certificate.
• proxy_mode = True behind the proxy, with Odoo's ports closed to the internet.
• list_db = False, with db_name or dbfilter matching one database per hostname.
• A long, random admin_passwd, kept in a password manager.
• A PostgreSQL user that is neither a superuser nor the owner of the databases.
• Multi-processing workers with memory, CPU and time limits such as limit_memory_hard, limit_time_cpu and limit_time_real.
• No demo data on any internet-facing database.
• Odoo, the operating system and PostgreSQL updated on a schedule.
• Inbound ports 80 and 443 only, outbound traffic by exception and SSH by key.
• Two-factor authentication enforced and a minimum password length set.
• Least privilege for users and integrations, reviewed regularly.
• fail2ban or an equivalent on failed logins, with alerts someone reads.
• Daily backups of databases and filestore, copied to a server the Odoo server cannot reach.

How Star Bit Solutions Can Help

Through OdooStar, we implement Odoo Enterprise on Odoo Online, Odoo.sh and your own servers, and Odoo Community where it fits. With your own servers, the servers, security patches and backups stay with your IT team, and we can agree a support arrangement around them: a review against this checklist before go-live, then issue resolution, monitoring and backups. If running servers is not where you want to spend your time, we can help you weigh a move to Odoo.sh or Odoo Online.

Ask for a review of your set-up: contact us, call +971 55 973 4524 or email [email protected].