How we protect your Odoo credentials.

When you connect an Odoo instance, only these fields are persisted in our database. Nothing else — no cookies, no session tokens, no Odoo admin keys, no analytics data beyond what is needed to sync your invoices.

• Odoo URL — e.g. https://acme.odoo.com — used to reach your instance.
• Database name — the Odoo database identifier — required by the Odoo RPC protocol.
• Username — the login of the dedicated Odoo user you provision for us.
• Encrypted password — a ciphertext blob. The original plaintext leaves your browser, is encrypted on our server, and is never written to disk in readable form.

Here is the real shape of the table that holds your connection. Notice what is absent: no plaintext_password column, no password_hint, no recovery field.

# simplified shape of what sits in the database
odoo_connections (
  id                  SERIAL PRIMARY KEY,
  user_id             INTEGER,
  url                 TEXT,          -- e.g. https://acme.odoo.com
  database            TEXT,          -- e.g. acme-prod
  username            TEXT,          -- e.g. bot@acme.com
  encrypted_password  TEXT,          -- ciphertext only — never plaintext
  ...
)

Three things make this row safe to hold:

• The password column stores ciphertext only — the plaintext never exists on our infrastructure after encryption.
• Ciphertext without the master key is cryptographically useless — no dictionary, no brute force in any feasible timeline.
• Each row is bound to a user_id. Our API refuses to return a connection that does not belong to the caller.

We use Fernet, the encryption scheme from the well-audited Python cryptography library. Fernet is not a home-grown protocol — it is a specification built on top of primitives reviewed for decades.

Every password you save goes through the same two functions. That is literally all the code there is — no custom crypto, no shortcuts:

# backend/app/core/security.py (excerpt)
from cryptography.fernet import Fernet

def encrypt(value: str) -> str:
    return get_fernet().encrypt(value.encode()).decode()

def decrypt(value: str) -> str:
    return get_fernet().decrypt(value.encode()).decode()

Encryption is only as strong as key management. The master key — the one that can turn ciphertext back into your password — is deliberately kept far away from the data it protects.

• Injected into the server process at boot from a managed secrets store. It never touches the application database.
• Never committed to git, never written to application logs, never returned by any API endpoint.
• Only the FastAPI server and the Celery sync worker hold it in memory, and only for the lifetime of that process.
• Database backups, read replicas, and staging environments use different data and cannot decrypt production ciphertext.

Your password makes exactly two hops when you save a connection, and exactly one every time we sync. Both hops are protected by TLS with modern cipher suites.

We never accept credentials over an unencrypted connection. The password is decrypted into memory only for the duration of a single RPC call to your Odoo, then dropped.

The set of processes and people that can decrypt a stored password is deliberately tiny.

• Application code paths: exactly two — the connection-test endpoint and the background sync worker. Both live in the repository. Both are auditable.
• Humans: no Vizualizer team member has a routine workflow that calls decrypt(). Direct DB access is audited and used for migrations, not row inspection.
• Other tenants: cannot. Every query is scoped by user_id, enforced server-side from the JWT, not by the frontend.

Even with valid credentials, our code cannot modify your Odoo. The sync worker calls only read methods — search_read, read — against invoice, partner, and product models.

• No write, unlink, or create calls are ever issued against your Odoo.
• No automation, no workflow triggers, no side effects on your business data.
• You can further restrict by giving Vizualizer's Odoo user read-only access groups — then even a bug or compromise on our side cannot alter your data.

Security promises are only meaningful when measured against specific threats. Here is how each common scenario plays out:

Click the × next to a connection in the sidebar and the row — including the encrypted password — is deleted from our database immediately.

• The row is removed by a hard DELETE, not a soft flag.
• Daily database backups roll off within our retention window; after that, no copy of the ciphertext remains anywhere.
• Synced invoice data tied to that connection is removed in the same transaction.

We welcome security reviews. If you are a security researcher, a CISO evaluating the product, or a customer wanting to run your own audit, we will work with you.

Report a vulnerability, ask for architecture details, or request a pentest window: security@hazenfield.com