Dolibarr security should prioritize supported-version hygiene, strong access controls, and careful module governance.
Dolibarr security reports are considered valid for the current stable release and the development branch. Do not run outdated production releases.
Recommended:
- track stable releases actively
- apply security updates quickly after validation in staging
- remove abandoned or unmaintained external modules
Dolibarr can be extended with official ecosystem 2FA modules (TOTP/U2F) documented in the project wiki and DoliStore ecosystem.
Minimum hardening:
- enforce HTTPS only
- enforce strong password policy
- enable 2FA for administrators and finance users
- restrict admin access to trusted networks where possible
Dolibarr’s flexibility comes from modules; that also increases security risk if unmanaged.
- disable unused modules
- review permissions required by each enabled module
- install modules only from trusted/maintained sources
- document module ownership and update cadence
¶ 4) Protect data layer and host
- isolate DB from public exposure
- use dedicated DB credentials with least privileges
- keep PHP/web stack patched
- back up DB + documents + module config; test restore
- monitor admin/configuration changes
- monitor failed login attempts and suspicious API actions
- keep an internal patch-and-rollforward plan for vulnerabilities
- Dolibarr GitHub Security Policy: https://github.com/Dolibarr/dolibarr/security
- Dolibarr Wiki: TwoFactorAuth module: https://wiki.dolibarr.org/index.php/Module_TwoFactorAuth
- DoliStore: Two-Factor Authentication module listing: https://www.dolistore.com/en/modules/816-Two-Factor-Authentication.html
Any questions?
Feel free to contact us. Find all contact information on our contact page.