AI coding assistants can draft Odoo models, wizards, controllers and XML views in seconds. That speed is real, and so is the blind spot that comes with it.

AI models learn from public code. They know the syntax and common patterns, but they don’t know your data, your company boundaries or the details of Odoo’s security model. This article is part of our Odoo security series.

The hidden risks in AI-written ERP code

• Missing security files. The Python logic and views look complete, but ir.model.access.csv is missing or not listed in the manifest.
• Privilege escalation with .sudo(). During trial-and-error prompting, “access denied” errors get solved by appending .sudo(), which exposes administrator-level data to ordinary users.
• Wrong controller authentication. Endpoints marked auth='public' that return or change business data, available to anyone on the internet.
• Outdated patterns. Code written for an older Odoo version that ignores newer security behaviour — for example the Odoo 20 move from record rules to domains on access rights.

A safe workflow for AI-assisted development

1. Treat AI code as a draft. Nothing goes to staging or production without review by an experienced Odoo developer.
2. Search for every .sudo() and every auth= in the diff, and justify each one.
3. Check the security files for each new model before reviewing the business logic.
4. Test with restricted personas. Log in as a standard employee and as a portal user and try to see what you should not.
5. Run automated checks — linters and tests in your CI pipeline — so obvious problems are caught before review.
6. Don’t paste secrets or customer data into prompts. Use sample data when you ask an assistant for help.

The OWASP Top 10 is a useful checklist for reviewers, and our complete guide to Odoo AI covers where AI adds the most value inside Odoo itself.

How Mediod can help

Mediod helps teams set up a safe AI-assisted development workflow: review checklists, CI checks and expert code reviews by our Odoo developers. Your team keeps the speed, and the code stays safe. Earlier in this series: custom module security debt.

More from our Odoo security series

• Custom Modules and Security Debt: Writing Safe Odoo Apps from Scratch
• Hardening a Dedicated Odoo Server (VPS or On-Premise): An Infrastructure Blueprint
• Odoo.sh Security: What’s Handled for You and What You Still Need to Protect

See all Odoo Security articles →

Frequently Asked Questions

Is AI-generated Odoo code safe to use?

It can be, after review. AI often misses access rights, overuses sudo() and misconfigures controller authentication, so every change needs a human code review and testing as a restricted user.

Why is sudo() dangerous in Odoo?

sudo() runs code as the superuser and skips access rights. If its results reach the user, they can see or change records they should never have access to.

The post The AI Coding Boom: Reducing Vulnerabilities in AI-Generated Odoo Code appeared first on Mediod Consulting.

Odoo’s modular architecture is its biggest advantage: you can shape the ERP around how your business really works. It is also its largest attack surface. Custom add-ons written in-house, by an outsourced agency or with rapid prototyping tools often build up security debt.

When a module ignores Odoo’s security framework, it quietly bypasses the access controls the rest of the system relies on. This article is part of our Odoo security series.

The flaws we find most often

• Missing access rights. A new models.Model without rows in security/ir.model.access.csv. Standard users either hit errors, or someone “fixes” it by granting everything to everyone.
• Rules that are too broad. No multi-company or departmental restriction, so any internal user can read or edit sensitive financial or HR records.
• Unsafe controllers. @http.route endpoints with auth='public' or auth='none' that change data, or that switch off CSRF checks.
• Raw SQL built with string formatting. cr.execute() with f-strings or % formatting opens the door to SQL injection.
• .sudo() as a shortcut. Used to silence an access error, and then returning privileged data to the user.

Secure development practices

1. Least privilege by default. Give each group (internal users, portal, your own groups) only the read, write, create and delete rights it needs.
2. Restrict records, not just models. Up to Odoo 19 that means record rules; in Odoo 20, put the domain on the access right. Always include the company restriction for multi-company databases.
3. Stay in the ORM. When raw SQL is truly needed for performance, use parameter binding (cr.execute(query, params)) or Odoo’s SQL wrapper, never string formatting.
4. Lock down controllers. Declare auth explicitly, validate every input, check record ownership before returning data, and keep CSRF protection on for forms.
5. Review sudo(). Keep it to the smallest operation and never pass sudo-ed recordsets back to the browser.
6. Test as a normal user. Log in as a restricted employee and a portal user before every release.

For broader design advice, see our complete guide to Odoo custom modules and common customization mistakes.

How Mediod can help

Mediod’s Odoo development team runs source-code security reviews of custom modules: access rights, controllers, SQL and privilege escalation. We then fix what we find or refactor modules ahead of your next upgrade. Short on in-house capacity? You can also hire Odoo developers by the month.

More from our Odoo security series

• The AI Coding Boom: Reducing Vulnerabilities in AI-Generated Odoo Code
• Hardening a Dedicated Odoo Server (VPS or On-Premise): An Infrastructure Blueprint
• Odoo.sh Security: What’s Handled for You and What You Still Need to Protect

See all Odoo Security articles →

Frequently Asked Questions

What happens if a custom Odoo model has no access rights?

Odoo denies access to non-admin users and logs a warning. Teams often work around it by granting broad rights, which is where data exposure starts. Define explicit access rights for each group instead.

Is raw SQL safe in Odoo?

Only with parameter binding. Pass values separately (cr.execute(query, params)) or use Odoo’s SQL wrapper. Never build queries with string formatting.

Does Odoo 20 still have record rules?

According to the Odoo 20 release notes, record rules are removed and a domain is added directly on the access right to decide which records it applies to. Existing rules need to be reviewed during the upgrade.

The post Custom Modules and Security Debt: Writing Safe Odoo Apps from Scratch appeared first on Mediod Consulting.

Running Odoo on your own server — a VPS on AWS, DigitalOcean or Google Cloud, or hardware in your own data centre — gives you full root access and complete freedom over the architecture. It also means you carry 100% of the security responsibility.

A new Linux server on the public internet sees automated port scans and password-guessing attempts within minutes. Hardening is not optional. This is the blueprint Mediod uses for self-hosted Odoo. This article is part of our Odoo security series.

Common infrastructure weaknesses

• Open database ports: PostgreSQL listening on all interfaces invites remote password guessing.
• Default SSH settings: password logins on port 22 are the first thing bots try.
• Unprotected database manager: a weak or default master password lets anyone with the URL back up, duplicate or drop your databases.
• Unencrypted local backups: dumps and filestore copies sitting on the same disk, readable by other users.
• Verbose errors: tracebacks and debug mode exposing internal details to visitors.

The hardening blueprint

1. Lock down SSH

Disable password authentication and allow key-based logins only. Disable direct root login, use a named sudo user, and allow SSH only from known IP addresses where you can.

2. Keep PostgreSQL private

In postgresql.conf, set listen_addresses = 'localhost' (or the private network address if the database sits on its own server), restrict pg_hba.conf to the Odoo host, and give the Odoo database user no superuser rights.

3. Harden the Odoo configuration file

• Set a long, unique admin_passwd (the master password).
• Set list_db = False and a dbfilter so the database manager and selector are not public.
• Bind Odoo to localhost and enable proxy_mode when it runs behind a reverse proxy.
• Run Odoo as its own unprivileged system user, and keep the config file readable only by that user.

4. Put Nginx in front

Terminate SSL in Nginx, redirect HTTP to HTTPS, add security headers (HSTS, X-Content-Type-Options, a referrer policy) and rate-limit /web/login to slow down password guessing. Block /web/database from the internet.

5. Add intrusion prevention

Configure fail2ban to watch SSH and Odoo login failures and ban repeat offenders. Enable a host firewall (ufw or firewalld) that only allows ports 22, 80 and 443.

6. Encrypt and test backups

Back up both the PostgreSQL database and the filestore, encrypt them, and copy them to a different provider or location. Restore a backup to a test server regularly — a backup you have never restored is a guess, not a plan.

7. Patch and monitor

Apply OS and Odoo source updates on a schedule, monitor disk, memory and login failures, and alert someone when something looks wrong.

How Mediod can help

Self-hosting needs ongoing DevOps work. Mediod sets up hardened Odoo servers, automated encrypted backups and monitoring, and looks after them through our support and maintenance plans. Moving an existing server? Our migration team can rebuild it on a hardened base.

More from our Odoo security series

• The AI Coding Boom: Reducing Vulnerabilities in AI-Generated Odoo Code
• Custom Modules and Security Debt: Writing Safe Odoo Apps from Scratch
• Odoo.sh Security: What’s Handled for You and What You Still Need to Protect

See all Odoo Security articles →

Frequently Asked Questions

Should PostgreSQL be reachable from the internet for Odoo?

No. PostgreSQL should only accept connections from the Odoo server itself, either on localhost or a private network.

How do I hide the Odoo database manager?

Set list_db = False and a dbfilter in the Odoo configuration file, use a strong master password (admin_passwd), and block /web/database at the reverse proxy.

Do I need Nginx in front of Odoo?

For production, yes. A reverse proxy such as Nginx handles SSL, security headers and rate limiting, and Odoo runs with proxy_mode enabled behind it.

The post Hardening a Dedicated Odoo Server (VPS or On-Premise): An Infrastructure Blueprint appeared first on Mediod Consulting.

When a business moves to Odoo.sh, the platform-as-a-service run by Odoo S.A., a lot of infrastructure work disappears: server provisioning, OS patching, SSL certificates and daily backups are all automated. That relief often turns into a risky assumption — that “cloud-managed” means “secure by default”.

Odoo.sh gives you a strong infrastructure foundation. Application security, repository hygiene and who can deploy what are still your team’s responsibility. This article is part of our Odoo security series.

The shared responsibility model on Odoo.sh

• What Odoo.sh handles (infrastructure): hosting and network protection, container isolation, operating-system updates, SSL/TLS certificates, and automated backups of your production database.
• What you handle (application and operations): the quality of your custom modules, who can push to your GitHub repository, where API keys and passwords are stored, which collaborators have access to the Odoo.sh project, and the access rights of every Odoo user.

If you are still choosing a hosting model, our comparison of Odoo Online vs Odoo.sh vs on-premise explains what each option leaves to you.

Common risks in Odoo.sh projects

• Careless staging branches. Staging builds start from a copy of production data. Connecting them to live third-party services, sharing their URLs widely or leaving verbose debug logging on can expose real customer records.
• Weak GitHub accounts. A developer account without multi-factor authentication (MFA) is enough for an attacker to push code that Odoo.sh then builds and deploys.
• Secrets in the repository. Payment gateway keys, API tokens or database passwords hardcoded in module files stay in Git history even after you delete them.
• Forgotten collaborators. Former employees, agencies and CI tools that still hold deploy keys or project access.

Odoo.sh security checklist

1. Protect the production branch. Limit who can push to it, and require reviewed pull requests before merging.
2. Require MFA on GitHub for every member of the organisation that owns the repository.
3. Keep secrets out of Git. Store keys in Odoo’s system parameters or the relevant app configuration on each database, and rotate any key that has ever been committed.
4. Review access every quarter. Remove collaborators, SSH keys and integrations that are no longer needed.
5. Treat staging data as live data. Restrict who can open staging builds and disconnect live payment, shipping and email integrations there.
6. Enable two-factor authentication in Odoo for administrators and other high-privilege users.

How Mediod can help

Mediod’s Odoo support and maintenance team runs Odoo.sh security reviews: branch and collaborator permissions, deployment pipeline, secrets handling and user access rights. You get a short report with the fixes ranked by risk. If your project is built on custom code, our development team can review it too.

More from our Odoo security series

• The AI Coding Boom: Reducing Vulnerabilities in AI-Generated Odoo Code
• Custom Modules and Security Debt: Writing Safe Odoo Apps from Scratch
• Hardening a Dedicated Odoo Server (VPS or On-Premise): An Infrastructure Blueprint

See all Odoo Security articles →

Frequently Asked Questions

Is Odoo.sh secure?

Odoo.sh provides a secure, managed infrastructure. Application security still depends on your custom code, GitHub access, how you store secrets and how you configure user access rights.

Who is responsible for security on Odoo.sh?

It is shared. Odoo S.A. runs the infrastructure: hosting, patching, SSL and backups. The customer and their developers are responsible for code, repository access, secrets and Odoo user permissions.

Does an Odoo.sh staging branch contain real data?

Yes. Staging builds are created from a copy of the production database, so they should be protected like production.

The post Odoo.sh Security: What’s Handled for You and What You Still Need to Protect appeared first on Mediod Consulting.