MuleSoft Secure Properties: How to Protect Sensitive Configuration Values in Mule 4

Every enterprise integration has sensitive configuration values.

These may include database passwords, API keys, OAuth client secrets, access tokens, private endpoints, encryption keys, or third-party credentials.

In development, it may feel easy to keep these values in a configuration file. But in production, that creates serious security risks.

If credentials are stored as plain text, they may be exposed through:

• Source code repositories
• Deployment packages
• Shared configuration files
• Logs
• Screenshots
• Developer machines
• Misconfigured access permissions

This is why MuleSoft secure properties are important.

Secure properties help protect sensitive values by encrypting them and referencing them safely inside Mule applications.

Why secure properties matter

A Mule application usually depends on multiple external systems.

*For example:
*
Mule API
↓
Salesforce
↓
Database
↓
ERP
↓
Payment gateway
↓
External REST API

Each system may require credentials or secret values.

A simple configuration file may look like this:

salesforce.username: [e-mail]
salesforce.password: MyPlainTextPassword
database.username: db_user
database.password: PlainTextDBPassword
payment.apiKey: abc123secret

This is risky because anyone with access to the file can read the credentials.

A better approach is to encrypt sensitive values and keep only encrypted versions in the application configuration.

What should be secured?

Not every property needs encryption.

For example, these may not be sensitive:

app.name: order-api
http.port: 8081
environment: dev
retry.count: 3

But these should usually be protected:

database.password
salesforce.clientSecret
oauth.clientSecret
jwt.signingKey
payment.apiKey
sftp.password
private.token
encryption.key

A good rule is simple:

If the value can give someone access to a system, data, or transaction, secure it.

Basic secure properties idea

In Mule 4, secure properties allow encrypted configuration values to be stored and referenced in the application.

Instead of keeping this:

database.password: PlainTextPassword

You keep something like:

database.password: "![encrypted-value-here]"

Then the Mule runtime decrypts the value using the correct secure properties configuration.

The application can use the value without exposing the original secret in the file.

Example: separating normal and secure configuration

A clean Mule project can separate normal properties and secure properties.

Example structure:

src/main/resources/
├── config-dev.yaml
├── config-qa.yaml
├── config-prod.yaml
└── secure-config.yaml

Normal configuration:

api.name: customer-api
http.port: 8081
salesforce.url: https://login.salesforce.com
database.host: db.example.com

Secure configuration:

salesforce.clientSecret: "![encrypted-secret]"
database.password: "![encrypted-password]"
payment.apiKey: "![encrypted-api-key]"

This makes the application easier to manage and review.

Developers can understand the structure without seeing actual secret values.

Environment-based configuration

Most MuleSoft projects have multiple environments:

DEV
QA
UAT
PROD

Each environment should have its own credentials.

Do not reuse development credentials in production.

A safer pattern is:

config-dev.yaml
config-qa.yaml
config-uat.yaml
config-prod.yaml

Each environment can have different values for:

Database credentials
API endpoints
OAuth clients
External system credentials
Queue names
Object Store settings
Logging levels

This prevents accidental use of production secrets in lower environments.

Avoid committing plain-text secrets

One of the biggest mistakes is committing credentials into Git.

Even if the secret is later removed, it may still exist in Git history.

Avoid committing files like:

local-passwords.txt
secrets.yaml
prod-config.yaml with plain text credentials
.env files with secrets

Use secure properties, CI/CD secret variables, or platform-level secret management wherever possible.

A good .gitignore strategy is also important.

Example:

*.key
*.pem
.env
local-secrets.yaml
credentials.txt
How secure values are usually referenced

Once secure properties are configured, Mule flows can reference them like normal properties.

Example:

host="${database.host}"
user="${database.username}"
password="${secure::database.password}" />
/db:config

The exact syntax may vary based on the project configuration, but the principle remains the same:

Normal values are referenced as normal properties.
Sensitive values are referenced through secure property resolution.

Common mistakes in secure properties implementation

1. Encrypting everything

Some teams encrypt all properties, including non-sensitive ones.

This makes configuration harder to maintain.

Only encrypt values that need protection.

1. Keeping encryption keys in the same repository

If encrypted secrets and the key to decrypt them are stored together, the protection becomes weak.

The encryption key should be managed separately and securely.

1. Reusing the same secrets across all environments

Development, QA, and production should not share the same passwords or API keys.

If one lower environment is compromised, production should remain protected.

1. Logging sensitive values

Even encrypted configuration is not enough if the application logs secrets after decryption.

Avoid logging:

Authorization headers
Access tokens
Passwords
API keys
Client secrets
JWTs
Personal data

Use masking wherever required.

1. Sharing secrets in screenshots or tickets

Production issues often require collaboration, but credentials should not be pasted into tickets, chats, emails, or screenshots.

Use approved secret-sharing tools or access-controlled vaults.

Secure properties and CI/CD

In mature MuleSoft delivery pipelines, secrets should be handled carefully during deployment.

A simple CI/CD flow may look like this:

Developer commits code
↓
Pipeline builds artifact
↓
Environment-specific variables are injected
↓
Secure keys are retrieved from protected storage
↓
Application is deployed
↓
Secrets are never printed in logs

This avoids manual handling of credentials.

It also reduces the chance of exposing secrets during deployment.

Production checklist for secure properties

Before moving a Mule application to production, review this checklist:

Are all passwords and secrets encrypted?
Are API keys protected?
Are OAuth client secrets secured?
Are production secrets different from lower environments?
Is the encryption key stored outside the code repository?
Are secrets excluded from logs?
Are secrets excluded from screenshots and support tickets?
Are access permissions limited?
Is secret rotation planned?
Are old or unused credentials removed?
Is the deployment pipeline protecting secret values?
Is the team trained on how to handle secrets safely?

If any answer is unclear, the application may need more review before production deployment.

Example secure properties review table
Area What to Check
Source code No plain-text passwords or API keys
Config files Sensitive values encrypted
Git history No exposed secrets
Logs No tokens, passwords, or secret headers
CI/CD Secrets not printed in pipeline logs
Environments DEV, QA, UAT, PROD use separate values
Access Only authorized users can manage secrets
Rotation Secrets can be changed without code changes
Final thoughts

Secure properties are not just a MuleSoft configuration feature. They are part of a larger security practice.

A good MuleSoft security setup should protect secrets across the full lifecycle:

Development
↓
Version control
↓
Build pipeline
↓
Deployment
↓
Runtime
↓
Monitoring
↓
Support

The main goal is simple:

Sensitive values should never be casually visible, copied, logged, or committed.

For a more detailed implementation-focused guide, you can refer to this article on MuleSoft secure properties.