Security is one of the most important aspects of any integration project. MuleSoft applications often handle API keys, DB credentials, JWT secrets, OAuth tokens, passwords, and more. If these values are not protected properly, your API or application becomes vulnerable to leaks and unauthorized access.
This blog covers how to securely store and manage sensitive values in MuleSoft using Secure Property Placeholder, AES encryption, and the best practices + misconfiguration pitfalls you must avoid.
Why Secure Configuration Matters in MuleSoft
Many developers mistakenly hard-code sensitive information inside Mule flows, connectors, or YAML/Property files.
This makes your project vulnerable because:
Secrets can leak through Git commits
Dev, QA, and Prod teams get unnecessary access
Anyone opening Anypoint Studio can see your credentials
Application logs can accidentally print sensitive data
MuleSoft provides Secure Property Placeholder to encrypt sensitive values and decrypt them dynamically at runtime.
1. Using Secure Property Placeholders in MuleSoft
Secure Property Placeholder lets you:
Encrypt sensitive values
Store them in
.propertiesor.yamlfilesDecrypt automatically at runtime using a key
Step 1: Add Secure Property Placeholder Module
In Anypoint Studio:
Go to Exchange
Search for Secure Configuration Properties
Add it to your project
It appears as a configuration element in your mule-app.
Step 2: Create Properties File
Example:
db.password=![jzhy2+df983j2…] # Encrypted value
client.secret=![89fd823kd9d9…]
Step 3: Configure Secure Property Placeholder
In your global-config.xml:
name=”secure-properties”
file=”secure-config.properties”
key=”${encryption.key}”
algorithm=”AES” />
file→ path of encrypted property filekey→ secret key used to decryptalgorithm→ AES (most common)
Step 4: Use It in Flows
password=”${db.password}” />
Mule will automatically decrypt the password at runtime.
You don’t need to manually decrypt anything.
2. AES Encryption Examples (Using DevGlan / OpenSSL / Studio)
Most MuleSoft teams use AES-128 or AES-256 encryption for secure properties.
Example: Encrypting a Value Using AES
Suppose you want to encrypt:
MyPassword123Use: https://www.devglan.com/online-tools/aes-encryption-decryption
(You already use this tool ✔)
Choose:
Algorithm: AES
Mode: ECB
Key Size: 128-bit
Key: your encryption key (example:
abcd1234abcd1234)
Encrypt the value → You get something like:
ED213F98A72878136D9FA3B1E45C9D21Store it inside properties file:
db.password=![ED213F98A72878136D9FA3B1E45C9D21]Now Mule decrypts this automatically using the secure-properties module.
Decrypting (If Needed)
Use the same:
encrypted text
encryption key
same mode
same algorithm
This is useful only if you need to verify values.
FAQs
1. Why should I use Secure Property Placeholder instead of normal properties in MuleSoft?
Secure Property Placeholder encrypts sensitive values like passwords, tokens, and API keys.
Normal properties store values in plain text, making them visible to developers, Git repositories, and logs. Secure config ensures that secrets remain encrypted at rest and decrypted only at runtime.
2. What encryption algorithm should I use for MuleSoft secure properties?
MuleSoft commonly supports AES-128 and AES-256.
AES-128 (ECB mode) is the most compatible and easy to configure.
If using AES-256, you must ensure your environment supports strong encryption policies; otherwise, decryption may fail.
3. Where should I store the encryption key for secure properties?
Never store your encryption key inside your Mule project.
Use one of these secure storage options instead:
CloudHub Environment Variables
Runtime Manager → Secure Properties
Kubernetes Secrets
HashiCorp Vault / AWS Secrets Manager
On-premise secure vault systems
4. Can I mix plain text and encrypted values in the same properties file?
Yes, you can mix them, but only encrypted values should be prefixed with:
![ENCRYPTED_VALUE]For example:
environment=dev db.password=![C8273F9AB7129D990BB2398E3C12F9]
Plain text is allowed for non-sensitive values like environment names or URLs. Sensitive fields should always be encrypted.




