Odoo security assessment

Odoo security assessment for on-premise instances: what it covers and why it is commissioned

A customer security review, a compliance requirement, a launch date or an insurer's questionnaire usually triggers this assessment of an on-premise Odoo system that holds business data. The assessment checks the deployment against Odoo's public security checklist for public deployments and tests the access control model, the reverse proxy and TLS setup, and the custom modules that sit on top of the standard code. The goal is a written view of what an outsider or an over-privileged internal user could reach, and what the buyer must fix before the system is trusted with customer or financial records. The risks addressed fall into four groups. The first is data exposure through access rights and record rules, where a user can read or change records that the business never meant to share, often because a group grants broader model access than intended or a record rule is missing on a custom model. The second is administrative surface left reachable, including the database manager, which should not be exposed to the public internet on a production instance. The third is weak transport security, such as plain HTTP paths, weak TLS settings or a proxy that forwards requests without the headers Odoo expects. The fourth is custom code. Odoo's framework protects against SQL injection through its ORM, against cross-site scripting through automatic escaping, and handles CSRF in the website engine. Those protections apply to standard code used as designed. They do not cover raw SQL, unescaped output, controllers that disable CSRF checks, sudo calls that bypass record rules, or misconfiguration of the web server in front of the application. Before commissioning the work, confirm which Odoo version and edition runs in production, which modules are custom or third-party, whether the instance is reachable from outside the client network, and who owns the reverse proxy configuration. Ask the provider how it will map findings to Odoo's checklist and to each custom module, and whether it will retest after fixes.

What can be in scope for an Odoo security assessment

Odoo scope is set by more than the URL of the login page. The production or staging choice, the web tier in front of Odoo, the database manager, company structure, roles and installed modules each change what a test can prove. Agree these decisions in writing before any testing starts.

Production or staging instance

Decide whether the test runs against the live instance, a staging copy or both. A staging copy only represents production if its version, installed modules, configuration and data shape match. Ask the client to confirm the Odoo version and edition, and to record every difference from production. Testing that could disrupt live orders, invoices or stock needs explicit rules of engagement and a agreed window.

Reverse proxy and TLS endpoints

Odoo's own documentation recommends running on-premise instances behind a web server such as Apache, Lighttpd or nginx for encryption and request proxying. List every hostname, port and path that reaches Odoo, including the longpolling or websocket path and any health endpoints. Include the proxy configuration and certificate chain in scope, since weaknesses often sit in the proxy rather than in Odoo.

Database manager exposure

Confirm whether the database manager interface is reachable from outside the admin network, and whether it is protected by a master password. Scope the test to check reachability through every path the proxy exposes, and to review how database creation, duplication and backup functions are restricted. Record the result against Odoo's public deployment security checklist.

Companies, roles and record rules

Odoo access control combines groups, access rights and record rules, and multi-company setups add another layer of separation. Agree which companies, business units and roles are in scope, and whether the test verifies that a user in one company cannot read or change another company's records. Ask the client for a documented role matrix so the tester can compare intended and actual access.

Test accounts for each role

Authenticated testing needs one test account per role that matters, such as an internal user, a portal user, a public visitor and an administrator. Agree who creates these accounts, what data they can see, and how they are removed afterward. Confirm whether administrator-level testing is included, because findings that depend on administrator rights are often judged differently from those reachable by ordinary users.

Custom modules and integrations

Custom modules and third-party apps often carry most of the risk in an Odoo instance. List every installed and custom module, its source and version, and any code that handles payments, file uploads or external calls. Include integrations for email, payment providers and API connections, and confirm which third-party endpoints the client has authority to test.

How the Odoo assessment runs, phase by phase

The sequence moves from a written scope and rules of engagement to configuration review, authenticated access testing, custom module review, severity-rated reporting and a retest, so each finding is confirmed and closed on evidence rather than assumption.

Agree scope and written rules of engagement
Before any testing, the team and the client agree in writing which Odoo instances, databases, companies, custom modules, hostnames and environments are in scope, which test accounts and roles will be provided, what testing is excluded, and who to contact if something breaks. Testing runs only against the client's own on-premise deployment inside their infrastructure. The step is complete when the signed scope document names every target, the test window and the escalation contacts, and the client has confirmed the test accounts they will supply.
Collect deployment and version facts
The assessor gathers the facts that determine what applies: the Odoo version and edition in use, the installed modules, the operating system, the web server or reverse proxy in front of Odoo, the database setup, backup and log locations, and how the instance is reached from the internet or internal networks. Odoo recommends running on-premise instances behind a web server such as Apache, Lighttpd or nginx that provides encryption and proxies requests, so the proxy configuration is recorded alongside the application settings. The output is an asset inventory the client confirms for accuracy.
Review configuration against the public deployment checklist
The assessor works through Odoo's security checklist for public deployments and checks the live configuration against each item, including TLS termination and certificate handling, how the reverse proxy forwards requests, whether the database manager is reachable from untrusted networks, debug and development settings, and administrator account hygiene. Each item is marked as met, not met, partially met or not applicable, with the evidence recorded. The step closes when every checklist item has a documented status and the evidence behind it.
Test access rights and record rules across roles
Using the test accounts agreed in scope, the assessor tests what each role can read, create, change and delete, both through the user interface and by direct requests to the same data. Odoo states that it does not rely on the user interface or hidden URLs for access control, so the test checks whether the server enforces access rights and record rules for each model and company, and whether users can reach records belonging to other departments, companies or customers. Results are logged per role and per model, and every unexpected access is reproduced and recorded with the request evidence needed for the fix.
Review and test custom modules
Custom and third-party modules are often where application-level weaknesses sit, so the assessor reviews their code for handling of user input, use of the ORM versus raw SQL, output encoding, file handling, access checks on controllers and any changes to standard security rules. Targeted testing then confirms the suspected issues against a running instance. The output lists each module with the weakness categories found and the code locations, and the client receives a list of modules that were reviewed, the version of each, and any that could not be reviewed.
Report findings with severity ratings
The assessor writes a report that lists each finding with a severity rating, a description of the weakness category, the affected component, reproduction steps at a level that lets the client's engineers confirm the issue without publishing exploit material, the evidence, and a recommended fix. The severity rating method should be agreed in advance so the client can compare results across tests. Each finding is traceable to a checklist item, a role test or a module review, which lets the client's auditor or customer follow the work.
Set remediation timelines by impact and priority
CIS Controls v8.1 Safeguard 16.13 asks for application penetration testing, and Safeguard 18.3 asks that findings from penetration tests be remediated on a timeline set by each finding's impact and priority. The client and assessor agree how each severity level maps to a remediation window within the client's own change process, and the client records an owner and target for each finding. The step is complete when the remediation plan is signed off and each finding has an owner and a status.
Retest fixed findings and confirm closure
Once the client reports fixes, the assessor retests each finding against the same scenario that produced it, confirms the fix on the affected component, and checks that the change did not open a neighbouring weakness. Findings are marked closed, still open, or accepted as a documented risk by the client. The output is a retest record that states what was checked, when, against which version and configuration, and it can be provided to the client's auditor or customer as evidence that the findings were addressed.

Why Odoo access rights and record rules need testing with several roles

Access control in Odoo lives in the data layer, so the assessment has to test it from the data layer. Odoo states that it does not rely on the user interface or hidden URLs to restrict access. Access rights define what a group may read, write, create and unlink on each model, and record rules narrow those permissions to specific records, often by company or by ownership of the record. An assessment therefore builds a matrix of roles against models and record sets, then checks what each role can actually do through the ORM, the JSON-RPC and XML-RPC interfaces, and the web client. Testers should use several accounts at different privilege levels, including portal and public users where the instance exposes them, and confirm that multi-company records stay within their company boundaries.

A user who can see a menu is not the same as a user restricted from data. Hiding a menu, a button or a form view changes what a person sees, but it does not change what the server returns when a record is requested directly. Weaknesses in this area tend to sit in a few places: record rules that were never created for a model added by a module, access rights granted broadly to an internal group that also holds portal or public accounts, and fields or related records that expose data a role should not see. Ask the client for its role design and any documented exceptions before testing, so the team can confirm which results are defects and which are approved business decisions.

Custom modules, overridden methods and public-facing website pages each need their own review, because they can bypass controls the standard modules enforce. An overridden create, write or search method may drop a domain filter that the original applied. A custom controller may return records without checking the caller's rights. A website page or form may accept input from an unauthenticated visitor and write it into a model that internal users rely on. Confirm with the implementation team which modules and overrides exist, and ask for the Odoo security checklist items the deployment claims to meet, since those become the reference points for findings.

Weakness categories in an on-premise Odoo deployment

This table lists the weakness categories we typically check in a self-hosted Odoo instance, with what each looks like in practice and why it matters to the business. Use it to see which areas your own deployment should be checked against before a test is scoped. Most findings cluster around the proxy layer, access rules and custom code rather than the core framework.

Weakness category	What it looks like	Why it matters
Database manager exposed	The database management interface is reachable from a public address or is left without access protection after installation	It allows database creation, backup, restore and deletion by anyone who can reach it, so the whole data set is at risk
Weak TLS or plain HTTP at the proxy	Odoo sits behind Apache, Lighttpd or nginx, but TLS settings are outdated, HTTP is not redirected to HTTPS, or internal traffic is unencrypted	Credentials and business records can be intercepted, and Odoo's own guidance expects the front-end web server to provide encryption
Access rights and record rules gaps	Users can read or edit records belonging to another company, department or role because record rules are missing or too broad	Multi-company setups depend on record rules for separation, so a gap exposes customer, supplier or financial data across boundaries
Admin functions reachable by low-privilege users	Settings, module installation or technical menus are accessible to standard users through direct URLs or misconfigured group membership	Odoo does not rely on hidden URLs for access control, so every privileged action must be governed by groups and rules that assessors can trace
Custom modules bypassing the ORM	Custom code uses raw SQL with string concatenation, or disables escaping in templates, weakening the protections the framework normally provides	Framework protections against SQL injection and cross-site scripting only hold when custom code uses them, so this is where bespoke code tends to add risk
Public website and portal forms	Website, portal or contact forms accept input without validation, or custom controllers skip the framework's CSRF handling	Public forms are reachable by anyone, and weak handling can lead to data corruption, spam abuse or account actions on behalf of users
Outdated Odoo versions or modules	The instance runs a release or third-party module version that no longer receives fixes, or updates are applied inconsistently across modules	Known fixes stay unapplied, and assessors compare the running version and module versions against the vendor's security information
Debug or development settings enabled	Debug mode, developer tools or verbose error output remain active on a production or public-facing instance	Detailed errors expose code paths, configuration and data structures that help an attacker plan further attacks
Integration credentials in configuration	API keys, mail or payment connector passwords are stored in plain text in configuration files, database fields or custom module settings	Compromise of the configuration exposes every connected system, so credential storage and access are a common review point

Which compliance frameworks and customer reviews ask for Odoo testing

Customers and vendor risk teams usually send a questionnaire before signing, and many ask whether the application has been penetration tested, how findings are fixed and whether the hosting configuration follows the vendor's own guidance. For a self-hosted Odoo instance, the reviewer is often less interested in the Odoo version alone and more interested in whether the deployment behind the reverse proxy was tested as a whole. Questions tend to focus on whether the test covered the web application and its access model, not just the login page.

Test scope statement: A dated summary of what was tested, including the Odoo version, custom modules and the reverse proxy, so the answer to the questionnaire matches a real scope.
Remediation record: Evidence that findings were tracked and closed, which maps to the expectation in CIS Controls v8.1 Safeguard 18.3 that findings are remediated on a timeline set by impact and priority.
Configuration evidence: Screenshots or exported settings showing the database manager is disabled or restricted, TLS is enforced and public deployment checklist items are addressed.
Retest confirmation: A short note confirming that high-impact findings were verified as fixed after the original report.

Before sending a questionnaire response, check that the test date, the Odoo version and the scope statement all describe the same instance the customer will use.

What you receive from an Odoo security assessment

The assessment produces a set of documents that a technical team can act on and a summary that a customer or auditor can read. Each card describes one part of that package and how it ties back to Odoo's own deployment guidance. Whether a reviewer accepts the result is their decision, and the report is built to support that review rather than replace it.

Executive summary and scope

The executive summary states what was tested, which Odoo version and deployment model were in scope, what was excluded, and the overall risk picture in plain language for leadership. The scope section lists hostnames, the reverse proxy, database manager access, custom modules and user roles covered, so the reader can see the boundary of the work. Ask for the exclusions to be written out, since gaps in scope are where reviewers look first.

Environment and version details

This section records the Odoo version, the Python and PostgreSQL versions where relevant, the web server in front of the instance, TLS configuration and installed modules as observed at the time of testing. It gives the reader a baseline to compare against later. Confirm that the version record matches what your operations team runs, because a mismatch changes which findings apply.

Findings with severity and defensive evidence

Each finding states the weakness category, the affected component, a severity rating with the rationale behind it, and evidence described at a defensive level. Evidence shows that a condition exists, such as an exposed administrative path or a permissive access rule, without publishing exploit steps. Ask for the rating method to be stated so that the same issue is rated the same way on retest.

Affected modules and configuration keys

Findings name the custom module, record rule, access right or configuration setting involved, so the engineer who fixes it knows where to look. Where the issue sits in the web server or reverse proxy, the report names the relevant configuration file or directive. Ask for the affected items to be listed in a table so they can be filtered and tracked in your own ticketing system.

Remediation tied to Odoo's checklist

Remediation guidance maps each finding to the relevant item in Odoo's security checklist for public deployments, and gives a fix that the team can apply without redesigning the system. Where a fix needs a code change in a custom module, the report says so and separates it from configuration changes. Ask whether remediation advice is prioritized by exposure, since that order usually decides what gets fixed first.

Retest results and customer-ready summary

After fixes are applied, a retest confirms which findings are closed, which remain open and which were partly addressed, and records the evidence for each status. A separate summary letter describes the test, its scope and the outcome in terms a customer security team or auditor can read without the technical detail. Acceptance of that summary stays with the customer or auditor, and DeployOpen does not issue audit reports or certifications.

How the Odoo assessment changes by hosting architecture

In the simplest on-premise layout, one host runs the Odoo application server, the PostgreSQL database and the file store, with a web server such as Apache, Lighttpd or nginx in front. Odoo recommends placing an on-premise instance behind a web server that provides encryption and proxies requests, so the proxy is the main trust boundary between the internet or internal users and the application. The assessment concentrates on what the proxy exposes and what the host allows if the application is compromised.

Proxy routing: whether the database manager and other administrative paths are reachable through the public hostname.
TLS configuration: protocol versions, cipher choices, certificate handling and whether plain HTTP is redirected or served.
Host separation: whether the database service listens only on localhost and whether the Odoo process runs under a restricted account.
Backups and file store: where backups are written and who can read them, since they hold the same data as the live database.
Odoo's public deployment checklist: compared item by item against the configuration actually in place.

Ask the team to confirm exactly which paths the proxy forwards, because a single host makes one misrouted location expose everything behind it.

What you prepare before an Odoo assessment starts

The most useful thing you can do before an Odoo assessment starts is assemble an accurate picture of the instance as it runs today. Confirm the exact Odoo version and edition, export the list of installed modules, and gather the server configuration file and the reverse proxy configuration for the public hostname. Odoo's own guidance is to run on-premise instances behind a web server such as Apache, Lighttpd or nginx that provides encryption and proxies requests, so the proxy rules, TLS settings and any blocked or allowed paths are as important to review as the application itself. Name one technical contact who can answer questions about hosting, databases and custom code, and who can approve access to the servers when testing begins.

Prepare test accounts for each role the business actually uses, such as a portal user, an internal user with sales or purchasing rights, a manager and an administrator, and agree in writing which records each account may touch. Access rights and record rules are where most multi-company and multi-team weaknesses sit, so testers need realistic ownership boundaries to check, and that means data agreed in advance. Where possible, run the assessment against a non-production copy restored from a recent backup. Production data carries personal and financial records, and a test that creates orders, invoices or stock moves can change business figures that someone must later reverse. If production testing is unavoidable, agree the record types, volumes and cleanup steps before work starts.

Also provide the list of integrations, including payment providers, email gateways, e-commerce connectors, single sign-on and any custom APIs, along with the change-freeze windows that apply to your month-end, sales peaks or audit periods. Confirm backup and rollback arrangements: who can restore the database and filestore, how long that takes, and where the last verified backup is stored. These details feed a written rules of engagement document that sets permitted test windows, source addresses, prohibited actions such as denial-of-service testing, escalation contacts and the stop conditions that pause activity if a business process is affected. Agreeing these rules protects operations and gives your auditors and insurers a clear record of what was authorized.

What to check before choosing a provider for Odoo testing

A provider's answers on Odoo's access model, its method against Odoo's public checklist, and how it handles your data will tell you more than a sample report. The cards below cover what to ask and what to put in writing before you sign.

Odoo architecture and access model

Ask whether the testers have worked with Odoo's ORM, its record rules and access rights, and its website engine. Odoo states that it does not rely on the user interface or hidden URLs for access control, so a good provider tests object-level permissions directly rather than only menus and buttons. Ask for a description of the roles they would test with and how many accounts they expect to use.

Method against the public checklist

Ask how the provider maps its work to the security checklist for public deployments in Odoo's documentation, and which items it treats as out of scope for your instance. A useful answer names each checklist area, states what evidence will be captured for it, and explains how items that depend on your own infrastructure will be confirmed.

Review of custom modules

Ask how custom and third-party modules are selected, reviewed and tested. A credible answer covers code review for access checks, sudo usage, raw SQL, file handling and controllers, plus a dependency check on each module's version compatibility. Confirm whether the review reads source only or also runs the modules in a staging copy of your instance.

Sample report and evidence

Request a redacted sample report before you commit. It should show a severity rating, the affected Odoo version and module, reproduction steps written for your developers, a remediation note and a clear statement of what was not tested. Ask whether the report can be mapped to the control references your auditor or customer uses.

Retest terms and remediation support

Ask what retest is included, how many retest rounds apply, and the time window after the report in which retesting happens. Confirm whether retesting is part of the fixed price or billed separately, and who decides when a finding is closed. Your remediation timeline should follow the finding's impact and priority, as CIS Controls v8.1 Safeguard 18.3 describes.

Handling of sensitive data

Ask where testing happens, whether the provider uses a copy of your database or production data, how credentials and exports are stored, and how long they are kept. Ask who on the provider's team can access them and how data is destroyed at the end. For Odoo, personal and financial records in the database are the main concern, so a masked or synthetic dataset is worth requesting.

Independence from implementation work

If the same firm would implement, customize or harden your Odoo instance, ask how it will avoid testing its own configuration without a second review. DeployOpen implements and hardens self-hosted platforms and also runs security testing, so buyers should ask for the separation of duties in writing, including who reviews the findings on work the team built.

Odoo security assessment questions buyers ask

How much does an Odoo security assessment cost?

The cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The main drivers are the number of Odoo instances and databases in scope, whether the reverse proxy, TLS termination and the database manager are included, how many custom modules need code review, the number of user roles whose access rights and record rules are tested, and whether the test is an assessment only or includes active testing of authenticated workflows. Ask for a quote that lists each component separately: configuration review, access control testing, custom module review, reporting and retest. Assessments are normally a one-time cost, while retesting and any ongoing hardening support are separate items you can scope later.

How long does an Odoo security assessment take?

Duration is set by the number of instances, the size of the custom code, and how many roles need testing, and it is agreed in the written scope before work starts. Time is also lost waiting for access, test accounts and change windows, so a well-prepared environment usually finishes faster. Ask your provider to break the timeline into scoping, configuration review, authenticated testing, reporting and the readout, and to state which of those depend on your team. Because DeployOpen works on fixed-scope engagements, the agreed timeline should appear in the statement of work.

What does our team need to provide before testing starts?

Plan to supply a clear architecture picture, the deployed Odoo version and installed module list, the source of any custom modules, and the reverse proxy and TLS configuration files. You will also need test accounts for each role you want covered (such as internal users, portal users and public visitors), a named technical contact, and a statement of which environments may be tested. Confirm with your team whether the database manager is reachable from the internet, and whether backups and logs can be shared. Testing should run against a staging copy or an agreed window on production, and that decision belongs in the scope document.

Can our own team run the Odoo checklist internally?

Yes, a capable internal team can work through Odoo's public deployment security checklist and check its own reverse proxy, TLS settings and database manager exposure. What an internal review usually finds harder is independent judgment on access rights and record rules, because the people who built them tend to test their own assumptions. Many organizations use an internal checklist pass for routine upkeep and bring in an external assessment for the initial baseline, for a compliance cycle, or before a major release. Be realistic about staff time and about whether your team has the skills to test custom module code.

Will an assessment report satisfy a customer or an auditor?

The report is evidence of testing performed against a stated scope and method. It is not an audit report, attestation or certification. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the opinions. Before you commission the test, ask what the framework or customer requires, such as whether they expect a test by an independent party, a particular methodology, or findings to be tracked to remediation. Relevant control ideas include CIS Controls v8.1 Safeguard 16.13, which asks for application penetration testing, and Safeguard 18.3, which asks for findings to be remediated on a timeline set by impact and priority. Confirm these expectations with your auditor before scoping.

How is retesting scoped and priced?

Retesting checks whether the agreed findings have been fixed, and it is usually a smaller, separate piece of work than the original assessment. Its cost depends on how many findings need verification, whether fixes touch custom modules that need re-review, and whether the retest covers the same environments. Ask the provider to state in the original statement of work whether one retest round is included, how findings are referenced between reports, and what happens to findings that you accept as risk. Retesting is best timed after your patch cycle, so the environment being verified matches what you run in production.

Do Odoo's built-in protections make testing unnecessary?

No. Odoo states that its framework protects against SQL injection through the ORM, against cross-site scripting through automatic escaping, and against CSRF in the website engine, and that it does not rely on hidden URLs for access control. Those protections reduce certain classes of defect, but they do not cover deployment choices, such as an exposed database manager, weak TLS or proxy rules, or an access rights and record rule design that does not match your business. Custom modules, third-party add-ons and integrations can also introduce weaknesses the core framework does not address. Testing checks how your specific deployment behaves.

How DeployOpen scopes, tests, reports and retests Odoo systems

DeployOpen plans, implements, hardens and documents self-hosted Odoo inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. Security testing is a separate service. We do not test systems we built and then certify them ourselves, and a team that wants independent assurance should be able to commission the test from a different scope and a clearly separated set of deliverables. Before any work starts, the scope is written down: which Odoo instances, databases, reverse proxy and TLS configuration, custom modules, user roles and access paths are in, what is out, which environments and accounts testing will use, and what the client receives at the end. Deliverables and timelines are agreed in the same document, so the client knows what evidence will exist and when.

Reports are written for two readers. Technical staff get each finding with the affected component, the evidence, the weakness category and the fix. The people who will show the result to an auditor or a customer get a summary that maps findings to the controls being assessed, along with a remediation plan. Findings are ranked by impact and priority so the client can set remediation timelines. Retesting follows the same written scope: once fixes are in place, we re-check the findings that were reported and record which ones are closed, which remain open and why. Ask any provider how retest results are documented and whether the retest is included in the quote or priced separately.

Some clients need more than a single assessment. Ongoing support, upgrades and continuous testing are available as retainers, which suit Odoo estates that change often through new modules, new users or regular version updates. Confirm with us during scoping which parts would sit under a retainer and which would stay as one-time work. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so confirm early which evidence your assessor will accept.