Odoo security hardening

A hardening change is only finished when someone has tried to break it and written down what happened. For an on-premise Odoo deployment, that means running a short set of checks against the live configuration, each with a stated expected result, and keeping the output so that an internal reviewer or an independent auditor can repeat the test later. Start with the database manager, because it is the highest-impact exposure. From a machine outside the trusted network segment, request the database manager page and confirm it does not list or create databases without the master password. Then confirm the master password is set to a strong value that is not stored in a shared file, and that the database manager is disabled in the production configuration if your team does not need it.

Next, confirm the exposed surface is what you designed. Scan the Odoo host from outside the proxy and verify that the only reachable service is the reverse proxy's TLS endpoint. The Odoo application port and the PostgreSQL port should not answer from any network except the internal segments that need them. Repeat the scan from inside the proxy network and from the application network, since a rule that blocks the public internet may still allow lateral access. Check the certificate chain and protocol versions the proxy negotiates, and record the scanner version, the target, the timestamp and the raw output. Those four fields are what make the result reproducible.

Access control is where most Odoo findings occur, so test it per role rather than per screen. Create one test user for each access group that exists in production, plus a user with no groups, and sign in as each. For every test user, confirm which menus appear, which records a list view returns for a company or team, and whether a record rule hides records that belong to another company or sales team. Then attempt the actions the user should not have: open a record by its database identifier in the URL, edit a field the role should only read, delete a record, and call the same model through the external API with that user's API key. The UI and the API must both refuse. Record each attempt as a row with the user, model, record identifier, action, expected result and observed result.

Two sign-in paths need failure testing as well. For two-factor authentication, enable it for a test user, then try to sign in with a wrong or missing second factor and confirm that no session is created and that repeated failures do not reveal which step failed. For LDAP, point a test user at an unreachable directory server, then at a server that returns an error, and confirm the login is refused rather than falling back to a local password that was never meant to apply. Also check the setting that creates users on first login from a template: a failed directory lookup must not create an account. Confirm these behaviors with the exact Odoo version and modules in your environment, since authentication behavior can change between releases.

Finally, prove that backups can be restored and that the restored copy is safe to use. Restore the most recent backup to an isolated test host, not to a machine that can reach production mail, payment or integration endpoints. Use Odoo's database duplication with neutralization so that outgoing email, scheduled actions and external connectors are disabled in the copy, and confirm the neutralization took effect. Compare record counts for key models, check that the filestore attachments open, and log the restore duration and any errors. Keep the restore log, the checksum of the backup file and the signed-off checklist together. Ask your independent assessor which evidence format they accept before you start, so the record is useful for the next assessment, not only for this one.

Hardening is not finished at go-live. The controls you set up in the first weeks only stay effective if someone reviews them on a schedule, and the most common gaps appear months later, after staff change roles, a certificate quietly approaches expiry, or a module is installed for a one-off project and forgotten. Plan these recurring tasks with named owners before the system goes live, and treat each one as part of the operating model rather than a project deliverable. Start with access. Review users, access groups and their memberships on a fixed cadence and whenever someone changes role or leaves. Focus on the groups that grant administrative rights, the Settings and Technical features, and any group that can export data or change record rules. If you use LDAP or another external sign-in, confirm that a disabled directory account also stops Odoo access, because a local Odoo user with a password can otherwise remain active. Check who holds the master password and confirm that the database manager is still restricted to the people who need it. Next, make the logs useful. Forward the Odoo server log and the reverse proxy access and error logs to a central location where someone can search them. Build a short list of signals to review: repeated failed sign-ins for one account, sign-ins from unusual addresses, changes to users or access groups, module installs and upgrades, and database manager actions. Ask your team which log retention period your policies require and confirm that the proxy and application logs keep the same time source so events can be correlated.

Keep the transport layer current. Track the expiry dates of every TLS certificate on the reverse proxy and any load balancer in front of it, and automate renewal where your certificate authority supports it. After each renewal or proxy configuration change, test the public endpoint and check that the Odoo login page and longpolling traffic still work. Review the proxy's supported protocol versions and cipher settings on a schedule set by your security standard, and record the date of each review. Backups need the same discipline. The database and the filestore are two parts of one system: attachments, images and generated documents live in the filestore, while the records that reference them live in PostgreSQL. Take both in the same backup window, store copies off the application server, and encrypt them. Then test restores on a regular schedule into a separate environment, using a database duplicate with neutralization for test copies where that suits your process. Measure how long the restore takes, confirm the restored instance starts, and check that a sample of attachments opens. A backup that has never been restored is an assumption, not a control.

Patch and version management is the control most often lost. Odoo security patches are provided only during standard support, so record the version you run and its standard support end date in your asset register. Standard support for Odoo 19.0 runs until September 2028, and Odoo 20.0 is supported until September 2029. Odoo 18.0 is supported until September 2027, while Odoo 17.0 standard support ended in September 2026. If your instance runs 17.0 or an older version, treat that as an open risk and confirm with Odoo and your partner what options remain before planning the next step. Put the end-of-support date on a calendar with a review point well before it, because upgrades of custom code take longer than the upgrade of core. Finally, document every third-party module. For each module, record its name, source, exact version, the Odoo version it targets, the person who approved it, the date of the last security review, and whether it is active in production. Remove modules that are no longer used, and re-review any module after an Odoo upgrade. Keep this register next to your configuration and access review records so an auditor or a new administrator can see the whole picture in one place. Ask your implementation partner to hand over this register as a deliverable at go-live.