Secrets & Secure Config in MuleSoft

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 .properties or .yaml files

  • Decrypt automatically at runtime using a key

Step 1: Add Secure Property Placeholder Module

In Anypoint Studio:

  1. Go to Exchange

  2. Search for Secure Configuration Properties

  3. 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:

<secure-properties:config
name=”secure-properties”
file=”secure-config.properties”
key=”${encryption.key}”
algorithm=”AES” />
  • file → path of encrypted property file

  • key → secret key used to decrypt

  • algorithm → AES (most common)

Step 4: Use It in Flows

<db:config name=”dbConfig”
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:

MyPassword123

Use: 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:

ED213F98A72878136D9FA3B1E45C9D21

Store 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.

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.

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

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.