My application.properties got exposed. What should I do?

01Understand what application.properties typically contains

Spring Boot aggregates all application configuration into this file. A typical production application.properties may include:

• spring.datasource.url / username / password — the JDBC connection URL and credentials for your primary database. Often points to a production PostgreSQL, MySQL, or Oracle instance.
• spring.security.oauth2 client secrets — credentials for OAuth2 providers like Google, GitHub, or an internal auth server.
• Messaging credentials — spring.rabbitmq.password, spring.kafka.properties.sasl.jaas.config with plaintext credentials.
• Custom API keys — properties like stripe.api.key, sendgrid.api.key, or any other third-party integration key.
• Spring Boot Actuator — if Actuator is enabled without authentication, the /actuator/env endpoint may also expose these values independently.

02Block access to the file

In a correctly deployed Spring Boot application, application.properties resides inside the JAR and is never accessible via HTTP. If it's reachable as a static file, it was deployed incorrectly — typically by deploying source files or an exploded directory to a web-accessible path. Fix the deployment, and add a web server deny rule as defence-in-depth:

location ~* \.(properties|ya?ml)$ {
    deny all;
    return 404;
}

Also check whether environment-specific files are accessible: application-production.properties, application-prod.yml, and similar variants.

03Rotate the database password and all credentials

Work through the file and rotate every credential. Start with the database, as it typically holds the most sensitive data:

-- connect as superuser
ALTER USER appuser WITH PASSWORD 'new-strong-password';

-- then update application.properties or env var
-- spring.datasource.password=new-strong-password

For each third-party service credential in the file, go to that provider's API key management page, revoke the old key, and generate a new one. Do not simply update the file — explicitly revoke the old key so it cannot be used even if an attacker captured it.

04Externalize secrets using Spring profiles and environment variables

Spring Boot's externalized configuration is designed to keep secrets out of files. Environment variables take precedence over application.properties and are never written to disk:

For cloud-native deployments, integrate Spring Cloud Config with a backend like HashiCorp Vault or AWS Secrets Manager. This ensures secrets are fetched at runtime, never stored in files, and can be rotated without a new deployment.

05Review access logs for the exposure window

Identify when the file first became accessible and when you blocked it, then look for requests during that window:

# nginx / apache combined log format
grep "application.properties\|application.yml" /var/log/nginx/access.log \
  | grep " 200 "

# filter for IPs that aren't yours
grep "application.properties" /var/log/nginx/access.log \
  | grep " 200 " | awk '{print $1}' | sort | uniq -c | sort -rn

For each suspicious IP, check your database logs for connections from that IP, your application logs for unusual API calls, and your third-party provider dashboards for activity originating from unfamiliar locations during that window.