Odoo Security Best Practices:
Production Hardening Guide

The Real Odoo Threat Landscape in 2026

Most Odoo breach post-mortems we review share a common thread: the attacker did not exploit a zero-day in the Odoo core. They walked through a door the operator left open — a default master password, an exposed PostgreSQL port, an admin account with a six-character password, a backup bucket with public read. Odoo itself is reasonably well-audited; the operational environment around it is usually not. Before you harden anything, you need to know what you are defending against.

Credential stuffing is the single most common attack we see in production logs. Attackers take password dumps from unrelated breaches and replay them against /web/login at low rates — ten attempts per minute per IP, rotating through thousands of proxies. Odoo 19's native rate limiting is minimal. Without an edge WAF or fail2ban, a patient attacker will eventually find an employee who reused a password.

SQL injection is rare in core Odoo because the ORM parameterizes queries. It becomes a serious risk in custom modules that bypass the ORM — any developer using self.env.cr.execute() with f-string interpolation creates an injection point. We have seen this pattern in third-party modules from the OCA and from boutique shops. Always audit custom code for raw cursor usage.

XSS in custom QWeb templates follows a similar pattern. Odoo's QWeb engine auto-escapes by default, but developers reach for t-raw when they want to render HTML from a field. If that field is user-editable — a product description, a website snippet, a contact note — an attacker with contributor access can plant a script tag that fires in an admin's browser. Session cookie theft follows within minutes.

Session hijacking matters most on multi-tenant infrastructure and on public Wi-Fi. Odoo session cookies are not bound to IP or fingerprint; if an attacker obtains a valid session_id, they become the user. TLS prevents sniffing in transit, but cookies stolen via XSS, malware, or logged-in laptops left in cafes are equally effective.

Denial-of-service against Odoo usually targets the most expensive endpoints: report generation, CSV exports, the website's search endpoint, and the /web/database/manager page. A single attacker with a residential proxy pool can tip an undersized instance into worker starvation in under five minutes. Worker process limits and an edge rate limiter are non-negotiable.

Ransomware via backups is the 2026 growth area. Attackers gain a foothold on the app server, enumerate the filestore and cron-based backup scripts, then encrypt both the live database and the backup directory before ransom. If your backups sit on the same host as the database — or on a mounted NFS share the app server can write to — you have no backup, you have a second copy of the ransomware.

Finally, insider threat. The offboarded developer who kept an SSH key, the finance manager downloading the full customer list the week before they resign, the consultant with base.group_system long after the project ended. Access reviews catch this; logs prove it after the fact. Most Odoo deployments have neither.

Application Security: Passwords, MFA, Access Groups, and Sessions

With the network locked down, the next attack surface is the Odoo application itself. Four controls matter more than anything else: strong password policies, multi-factor authentication on every privileged account, least-privilege access groups, and aggressive session timeouts. Getting these four right eliminates most of the credential-based attack vectors in our threat model.

Password Policy (Odoo 19 Native)

Odoo 19 ships with a native password policy configurable in Settings > General Settings > Permissions > Password Policy. Set a minimum length of 12 characters. Longer is better, but 12 is the practical floor that balances usability and entropy. Combine this with a complexity rule (upper, lower, number, symbol) and a history check that prevents reuse of the last five passwords.

<odoo>
  <data noupdate="0">
    <record id="auth_password_policy.minlength" model="ir.config_parameter">
      <field name="key">auth_password_policy.minlength</field>
      <field name="value">12</field>
    </record>
    <record id="auth_password_policy.minclasses" model="ir.config_parameter">
      <field name="key">auth_password_policy.minclasses</field>
      <field name="value">3</field>
    </record>
  </data>
</odoo>

MFA / 2FA via auth_totp

Odoo 19 includes auth_totp in the community edition. Install it, enforce it for every user in the base.group_system group, and strongly encourage it for everyone else. The auth_totp_mail module adds email as a fallback second factor for users who lose their authenticator. We disable email-only 2FA for admins — it is too easy to compromise via mailbox takeover — and require TOTP or hardware keys instead.

from odoo import models, api
from odoo.exceptions import ValidationError

class ResUsers(models.Model):
    _inherit = 'res.users'

    @api.constrains('groups_id', 'totp_secret')
    def _check_admin_totp_required(self):
        admin_group = self.env.ref('base.group_system')
        for user in self:
            if admin_group in user.groups_id and not user.totp_secret:
                raise ValidationError(
                    f"User {user.login} is an administrator. "
                    "TOTP two-factor authentication is mandatory "
                    "before administrative privileges can be granted."
                )

Access Groups, Record Rules, and Least Privilege

Odoo's permission model has three layers: groups (coarse capabilities like "Accounting: Accountant"), access rights (per-model CRUD), and record rules (per-record filters via domain). The default distribution is too permissive for production. A fresh Odoo install gives any internal user read access to most HR, CRM, and accounting data. Least privilege means starting from zero and granting explicitly.

We document our full access-control playbook in Odoo 19 Access Control: Groups, Record Rules & Field-Level Security; the security-critical pattern is shown below. It restricts sales representatives to seeing only their own opportunities — even though they are in the Sales User group.

<record id="crm_lead_personal_rule" model="ir.rule">
  <field name="name">CRM Lead: Own Records Only</field>
  <field name="model_id" ref="crm.model_crm_lead"/>
  <field name="domain_force">
    [('user_id', '=', user.id)]
  </field>
  <field name="groups" eval="[(4, ref('sales_team.group_sale_salesman'))]"/>
  <field name="perm_read" eval="True"/>
  <field name="perm_write" eval="True"/>
  <field name="perm_create" eval="True"/>
  <field name="perm_unlink" eval="False"/>
</record>

<!-- Manager rule: team-wide visibility -->
<record id="crm_lead_manager_rule" model="ir.rule">
  <field name="name">CRM Lead: Team Access</field>
  <field name="model_id" ref="crm.model_crm_lead"/>
  <field name="domain_force">
    ['|', ('team_id.user_id', '=', user.id),
          ('team_id.member_ids', 'in', [user.id])]
  </field>
  <field name="groups" eval="[(4, ref('sales_team.group_sale_manager'))]"/>
</record>

Session Timeout and Cookie Security

Odoo sessions default to 7 days. For an ERP with financial data, that is a liability. A stolen laptop, a shared browser in a coworking space, or an unattended kiosk becomes a week-long window into your business. We set production session lifetimes to 8 hours for regular users and 1 hour for administrators, with idle timeout at 30 minutes.

# odoo.conf
session_cookie_secure = True
session_cookie_samesite = Lax
session_cookie_httponly = True
# Keep workers rotating to reduce session sprawl
max_cron_threads = 2
limit_time_real = 120
limit_request = 8192

from datetime import datetime, timedelta
from odoo import http
from odoo.http import request

class SessionSecurity(http.Controller):

    @http.route('/web/session/check', type='json', auth='user')
    def check_idle(self):
        last = request.session.get('last_activity')
        now = datetime.utcnow()
        is_admin = request.env.user.has_group('base.group_system')
        max_idle = timedelta(minutes=15 if is_admin else 30)

        if last and now - datetime.fromisoformat(last) > max_idle:
            request.session.logout(keep_db=True)
            return {'expired': True}

        request.session['last_activity'] = now.isoformat()
        return {'expired': False}

Content Security Policy and Frame Headers

A strict Content Security Policy stops most XSS from ever firing. Odoo 19's default CSP is permissive to support website builder features; for the backend, we tighten it significantly. Combine with X-Frame-Options: SAMEORIGIN to prevent clickjacking against logged-in admins, and X-Content-Type-Options: nosniff to stop MIME-sniffing attacks. These headers are set at the nginx layer (shown in the infrastructure section) because nginx gets the last word on response headers.

Backup and Recovery: 3-2-1, Encrypted, Tested

A backup strategy is not real until it has been restored. We have walked into ransomware incidents where the customer had six months of nightly backups — all of which were mounted on the same host the attacker owned, all of which were encrypted alongside the live database. The 3-2-1 rule exists specifically for this scenario: three copies of your data, on two different media, with one copy offsite and offline.

#!/usr/bin/env bash
set -euo pipefail

DB_NAME="production_db"
TS=$(date -u +%Y%m%dT%H%M%SZ)
STAGE="/var/backups/odoo/${DB_NAME}-${TS}"
AGE_RECIPIENT="age1xxxx...public-key"   # Public key; private key is offline
S3_BUCKET="s3://company-odoo-backups-glacier"

mkdir -p "${STAGE}"

# 1. PostgreSQL dump (custom format, parallel)
pg_dump -h 127.0.0.1 -U odoo_prod -F c -j 4 \
  -f "${STAGE}/db.dump" "${DB_NAME}"

# 2. Filestore
tar -C /var/lib/odoo/filestore -czf "${STAGE}/filestore.tar.gz" "${DB_NAME}"

# 3. Encrypt both artifacts with age (never decrypt on this host)
age -r "${AGE_RECIPIENT}" -o "${STAGE}/db.dump.age" "${STAGE}/db.dump"
age -r "${AGE_RECIPIENT}" -o "${STAGE}/filestore.tar.gz.age" "${STAGE}/filestore.tar.gz"
rm -f "${STAGE}/db.dump" "${STAGE}/filestore.tar.gz"

# 4. Upload to Glacier with SSE-KMS
aws s3 cp "${STAGE}/" "${S3_BUCKET}/${DB_NAME}/${TS}/" \
  --recursive \
  --storage-class DEEP_ARCHIVE \
  --sse aws:kms \
  --sse-kms-key-id alias/odoo-backups

# 5. Local retention: keep last 3 hours on disk
find /var/backups/odoo -maxdepth 1 -type d -mmin +180 -exec rm -rf {} +

logger -t odoo-backup "Backup ${DB_NAME} ${TS} uploaded"

RPO, RTO, and the Monthly Restore Drill

Declare your recovery objectives explicitly. For typical mid-market Odoo deployments we target RPO of 1 hour (maximum tolerable data loss) and RTO of 4 hours (maximum tolerable downtime). These numbers drive the backup frequency and the hot-standby architecture. Once per month, on a scheduled Tuesday, we run a full restore drill: pull the most recent Glacier snapshot into a clean VM, restore the database, boot Odoo, verify a known-good record set. If the drill fails or takes longer than the RTO, we fix it that week. Untested backups are not backups.

Monitoring, Logging, and Alerting

You cannot respond to an incident you cannot see. Production Odoo generates four signal streams worth monitoring: application errors, authentication events, database performance, and availability. We pipe all four into a central stack — Loki or ELK for logs, Sentry or Glitchtip for errors, Prometheus and Grafana for metrics, and PagerDuty for alerting.

# In a small custom module, addons/security_monitoring/__init__.py
import os
import sentry_sdk
from sentry_sdk.integrations.logging import LoggingIntegration

dsn = os.environ.get('SENTRY_DSN')
if dsn:
    sentry_sdk.init(
        dsn=dsn,
        environment=os.environ.get('ODOO_ENV', 'production'),
        release=os.environ.get('ODOO_RELEASE', 'unknown'),
        traces_sample_rate=0.05,
        send_default_pii=False,  # Never ship PII to error tracker
        integrations=[LoggingIntegration(
            level=None,           # Capture all levels as breadcrumbs
            event_level='ERROR',  # Send ERRORs as Sentry events
        )],
    )

Centralized Logs and Failed-Login Alerts

Ship Odoo, nginx, PostgreSQL, and auth logs to a central collector. We use Promtail -> Loki -> Grafana for most deployments; ELK works just as well if you already have the infrastructure. Critical alerts include: 10+ failed logins from a single IP in 60 seconds, any successful login by a base.group_system user outside business hours, any query exceeding 30 seconds, any uptime probe failure lasting more than 2 minutes, and any backup job that exits non-zero.

groups:
  - name: odoo-security
    interval: 30s
    rules:
      - alert: OdooLoginBruteForce
        expr: |
          sum by (remote_addr) (
            count_over_time(
              {job="odoo"} |~ "Login failed" [1m]
            )
          ) > 10
        for: 1m
        labels: { severity: critical, team: security }
        annotations:
          summary: "Brute-force login attempt on {{ $labels.remote_addr }}"
      - alert: OdooAdminLoginOffHours
        expr: |
          sum(count_over_time(
            {job="odoo"} |~ "admin.*login success" [5m]
          )) > 0 and ON() (hour() < 7 or hour() > 20)
        for: 0m
        labels: { severity: high, team: security }

Finally, set up synthetic uptime monitoring from a location outside your cloud provider. UptimeRobot, Better Stack, or a custom Pingdom check that loads /web/login, confirms a 200 response, and times the TLS handshake. If your own infrastructure goes down, your internal monitoring goes with it — external checks are the only alert that survives a full-region outage.

Frequently Asked Questions

Optimization Metadata