Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

configprops endpoint prefix selector also returns beans of sibling prefixes (spring.data matches spring.datasource)

Open Beginner friendly
  • Is something wrong?
#52,347 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java, spring-boot
Domain
backend, testing

Research direction

Read ConfigurationPropertiesReportEndpoint.getConfigurationProperties and the existing ConfigurationPropertiesReportEndpointFilteringTests.filterByPrefixMultipleMatches test. Reproduce the sibling-prefix case with spring.data and spring.datasource, then add a regression test for the selector boundary. Done means exact prefixes and dotted descendants still match while sibling prefixes do not.

Written by the indexing model from the issue text.

Description

status: waiting-for-triage

GET /actuator/configprops/{prefix} (and the JMX operation configurationPropertiesWithPrefix) is documented as returning "the @ConfigurationProperties beans mapped under a certain prefix" and "a more general prefix will return all beans mapped under that prefix stem". The filter is a plain string startsWith (ConfigurationPropertiesReportEndpoint.getConfigurationProperties: bean.getAnnotation().prefix().startsWith(prefix)), so a bean whose prefix merely starts with the same characters is returned too:

GET /actuator/configprops/spring.data   (spring-boot-actuator 4.1.1, same on 3.5.x)
   spring.data.redis      (expected)
   spring.datasource      (sibling, unexpected)

GET /actuator/configprops/spring.web
   spring.web             (expected)
   spring.webflux         (sibling, unexpected)
   spring.webservices     (sibling, unexpected)

spring.data / spring.datasource and spring.web / spring.webflux / spring.webservices are all real Spring Boot namespaces, so this happens with ordinary applications. The trailing-dot form (spring.data.) and exact names behave as expected. (Not a data-exposure issue — /actuator/configprops already returns everything with the same sanitization — just incorrect filtering.)

Suggested fix: treat the selector as a dotted property-name prefix — a bean matches when its prefix equals the selector or continues with a . (a selector that already ends in ., as in ConfigurationPropertiesReportEndpointFilteringTests.filterByPrefixMultipleMatches, keeps matching every descendant). I have the change with a regression test ready against 3.5.x.

Dominant language
Java
Stars
81.7k
Forks
45.1k
Avg merge
3d 11h
Merged PRs (30d)
54

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from spring-projects/spring-boot

All issues in spring-projects/spring-boot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.