It's a dilemma.

Database Storage

Storing sensitive data in the database ensures it's only accessible via valid Mendix credentials, providing good security as long as proper entity access rules are applied. The downside is that if you move a database from production to an acceptance environment (e.g., for debugging), production settings might also be transferred. This could result in issues like sending emails to production users from the acceptance environment. To mitigate this, ensure you have environment-specific configurations, or scrub sensitive data before moving databases.

Constants

Constants offer an easier implementation and reduce the risk of misconfigurations when moving databases. However, since constants are stored in the deployment settings, they can be accessed by admins during deployment. Additionally, constants only allow for simple key-value pairs, not complex structures. For critical data that might be altered less frequently, constants can be a safe and straightforward choice, but for highly sensitive information, consider more secure methods.

Client-Side Widgets

Storing sensitive information in a widget is the least secure option, as anything in the client is exposed and can be intercepted. For this reason, avoid storing any sensitive configuration on the client side. But if security is not a worry, it can be a quick and effective way.

While constants are often the simplest and safest option for configuration management, always ask yourself whether something truly needs to be configurable. Unnecessary configurability can quickly increase complexity and costs.

It depends on if you need to be able to setup different configurations in the frontend. Like the email connector you need to be able to setup multiple accounts. Hence you need to store passwords etc. in the database.

Otherwise I would probably use constants. But do note that those values are in the configuration file so anybody with access to the model can grab those values.

Regards,

Ronald

Storing credentials: I prefer encrypted in the database over constants even if there is only a single account. Because constants are not encrypted and might end up in version control (e.g. if you configure them as default values / project configuration / documentation).

Sharing credentials: For localdev the data-snapshot can be used to quickly share the project runtime configuration with other developers, but note: this also ends up in version control and thus isn't that secure.

Always use separate between keys used for production and keys used for other environments, this makes revoking and rotation a lot easier.

Another option would be to use a password vault that allows you to have something like shared collections/ways to share keys in a safe manner.

For non-prod many providers allow you to use either test keys or paid keys with a limit amount of calls - which if they leak because of shared db's cause less harm. Because they are easy to revoke (no production disruption) and have a limit number of credits/calls so you wont rake up much costs.