How to Manage Application Properties Securely in Spring Boot

Spring Boot makes configuration convenient through application.properties and application.yml, but convenience can become a security risk when passwords, API tokens, database credentials, or signing keys are stored carelessly. A committed secret can remain in Git history long after the file has been edited, exposing an application to unauthorised access.

Secure configuration means separating ordinary settings from sensitive values, controlling who can access each value, and choosing a safe delivery method for every environment. This approach works for a small Melbourne consultancy, a Sydney fintech platform, or a distributed team deploying services across Australian cloud regions.

Keep Sensitive Values Out Of Source Control

Application properties should contain defaults that are safe to share. Database URLs, connection pool sizes, feature flags, logging levels, and timeout values are usually suitable for configuration files. Passwords, private keys, OAuth client secrets, payment gateway credentials, and encryption keys should be injected at runtime instead.

A local application.yml file might use environment variable placeholders:

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

payment:
  stripe:
    secret-key: ${STRIPE_SECRET_KEY}

The application reads the values without placing them directly in the repository. Add local secret files to .gitignore, use a secret-scanning tool in the CI pipeline, and rotate credentials immediately if a secret is accidentally pushed. Git history should be treated as permanent exposure, even when a branch has been deleted.

Use Profiles For Environment Configuration

Spring profiles help separate development, testing, staging, and production settings. Files such as application-dev.yml and application-prod.yml can define environment-specific behaviour, but profiles are not a security boundary. A production password inside application-prod.yml is still vulnerable if the file is committed or copied into a developer workstation.

Keep profile files focused on non-sensitive differences, such as service URLs, logging levels, connection pool settings, and permitted origins. Activate a profile through an environment variable or deployment setting:

SPRING_PROFILES_ACTIVE=prod

For Australian teams, profile separation is useful when a service runs in an AWS Sydney region while test workloads operate elsewhere. It also makes it easier to apply different data-retention, monitoring, and deployment rules for customer systems governed by the Australian Privacy Act.

Inject Secrets Through A Managed Store

For production systems, a managed secrets platform is generally safer than manually maintained environment variables. Spring Boot applications can retrieve credentials from services such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, or a company-operated Spring Cloud Config setup.

A managed store provides access policies, audit records, automatic rotation, and central revocation. The application should authenticate using a workload identity, IAM role, or managed identity rather than a long-lived cloud access key embedded in configuration. Grant the service account only the specific secrets it needs.

When deploying in Australia, an organisation may choose an Australian data centre region for operational, contractual, or data-residency reasons. Confirm where secrets are stored and backed up, especially for healthcare, government, and financial workloads. A secret manager does not remove compliance obligations; it supports the controls needed to meet them.

Protect Configuration During Deployment

Secrets can leak through Docker images, Helm charts, shell history, build logs, crash reports, and cloud task definitions. Never pass credentials as command-line arguments when they could appear in process listings or deployment logs. Ensure CI systems mask secret values and prevent debug output from printing the complete application environment.

Spring Boot Actuator also needs careful configuration. Endpoints such as /env, /configprops, and /heapdump may reveal property names or sensitive values if exposed publicly. Restrict actuator endpoints, secure them with authentication, and expose only the health checks required by the platform.

Use TLS for database, API, configuration-server, and secret-manager connections. In a Brisbane office, a remote worker in Perth, or a co-working space near Sydney’s Central Station, network traffic should be treated as untrusted unless it is encrypted and authenticated.

Validate, Rotate, And Monitor Access

Configuration validation catches missing or malformed values before the application handles customer traffic. Spring Boot’s @ConfigurationProperties with Jakarta validation provides a structured way to check required settings:

@ConfigurationProperties(prefix = "payment")
@Validated
public record PaymentProperties(
    @NotBlank String provider,
    @NotBlank String secretKey
) {}

Avoid logging configuration objects, request headers containing tokens, or full exception details from authentication and payment integrations. Use redaction for values that may appear in diagnostics, and review logs as part of normal operational monitoring rather than waiting for an incident.

Rotate database passwords, signing keys, and third-party credentials on a defined schedule and after staff changes or suspected exposure. Monitor secret access for unusual locations, excessive requests, and unexpected deployment activity. Australian businesses often coordinate releases around AEST or AEDT support windows, so document rotation procedures clearly enough for an on-call engineer to follow during an early-morning incident or a busy arvo.