Introduction

Keeping plaintext passwords in application.properties is a common security mistake that often leads to leaks through source control, logs, or build artifacts. Spring Boot supports safer patterns that separate secret values from committed configuration. The goal is not only hiding secrets, but enabling secure rotation and controlled access.

Use Placeholders and Runtime Injection

A simple baseline is placeholder-based config with environment injection.

spring.datasource.url=jdbc:postgresql://db.internal:5432/appdb
spring.datasource.username=app_user
spring.datasource.password=${DB_PASSWORD}

Set the secret at runtime:

export DB_PASSWORD='replace-me'
java -jar app.jar

This removes plaintext secrets from repository files and works in local and CI environments.

Keep Profiles Non-Sensitive

Avoid storing secrets in profile-specific files such as application-prod.properties. Keep all profiles referencing the same external secret source.

1# application-dev.properties
2spring.datasource.password=${DB_PASSWORD}
3
4# application-prod.properties
5spring.datasource.password=${DB_PASSWORD}

This prevents one profile from becoming an accidental security exception.

Use Secret Managers in Production

Environment variables are better than plaintext commits, but production systems usually need audit trails and rotation workflows.

Common options:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager

Spring-style Vault import example:

1spring.config.import=vault://
2spring.cloud.vault.uri=https://vault.internal:8200
3spring.cloud.vault.authentication=TOKEN
4spring.cloud.vault.token=${VAULT_TOKEN}

This keeps credentials out of static property files.

Encrypted Property Values as Transitional Option

If constraints require storing encrypted strings in config, keep decryptor key external and tightly controlled.

spring.datasource.password=ENC(encrypted-value)

Runtime key example:

export JASYPT_ENCRYPTOR_PASSWORD='decrypt-key'
java -jar app.jar

Encrypted values in Git still require strict key management. Encryption is not a replacement for secret governance.

Rotation and Revocation Workflow

A secure setup must support lifecycle operations:

• rotate secrets regularly
• update runtime source automatically
• restart or refresh app safely
• revoke compromised credentials quickly

Short-lived credentials reduce exposure window compared with static passwords.

Prevent Secret Leakage in Logs

Even externalized secrets can leak if you log full URLs or environment dumps. Log non-sensitive identifiers only.

log.info("Connecting to host={} db={}", host, dbName);

Also configure CI systems to mask secrets in build output and test traces.

Practical Local Development Pattern

Use a local .env or shell profile that is ignored by source control and populated per developer machine. Document expected variable names clearly so onboarding does not lead to temporary plaintext commits.

CI and Deployment Guardrails

Add automated checks that block commits containing likely secrets and validate that required environment variables are present in deployment manifests. Secret scanning in pull requests catches accidental leaks early, while startup validation prevents deployments with missing secret bindings.

Security improves when prevention and detection are both present across developer workflow and runtime platform. Keep emergency secret-rotation runbooks tested periodically so credential replacement can be executed quickly when exposure is suspected. Run post-rotation validation checks automatically to confirm applications have reloaded the new values successfully. Track rotation timestamps centrally for compliance and audit reporting.

Common Pitfalls

• Committing plaintext passwords in one profile file while others are externalized.
• Storing encrypted values and decryptor keys in the same repository.
• Assuming environment variables are secure without controlling process access.
• Logging full JDBC URLs including credentials.
• Ignoring rotation and keeping long-lived static passwords.

Summary

• Never store plaintext passwords in committed Spring property files.
• Use placeholders with runtime injection as a minimum baseline.
• Prefer managed secret stores for production deployments.
• Treat encryption as supplemental, not complete secret strategy.
• Combine storage controls with rotation, logging hygiene, and incident response.