[Luqmansonar]

Adds two opt-in rule parameters to S4684, excludedAnnotations and excludedTypes (comma-separated fully qualified names, default empty). A request-mapping parameter carrying a declared annotation or of a declared type is not reported. Declaring one is an assertion by the project about its own argument resolver; the analyzer does not verify it. Default behaviour is unchanged.

Related RSPEC PR documents the parameters : https://github.com/SonarSource/rspec/pull/8485.

Tests: PersistentEntityUsedAsRequestParameterCheckTest (3 tests), JavaRulesDefinitionTest and GeneratedCheckListTest pass locally. Ruling ITs not run locally.

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

SONARJAVA-7030

[aurelien-coet-sonarsource]

Maybe this sample method should be split in two samples, one with a parameter of type Other that is non-compliant, and another with a UserDetail that is compliant. I was initially surprised to see that an issue should be raised on this line even though UserDetail is added as an excluded type in the rule parameters, until I realized the issue is on other.

[gitar-bot]

Code Review ✅ Approved 🟡 Medium risk 1 closed / 1 findings

Configurable S4684 annotation/type exclusions could leave unsafe entity request parameters unflagged if project assertions do not match actual argument resolution.

Adds opt-in excludedAnnotations and excludedTypes parameters to S4684 so request-mapping parameters carrying a declared annotation or type are not reported, with default behavior unchanged. Rule parameters are now parsed once per method instead of for every parameter of every endpoint, addressing the repeated re-parsing finding. No open issues found.

✅ 1 closed

✅ Performance: Rule parameters re-parsed for every parameter of every endpoint

📄 java-checks/src/main/java/org/sonar/java/checks/spring/PersistentEntityUsedAsRequestParameterCheck.java:99-111
hasNoAllowedAnnotations and isNotExcludedType call split(excludedAnnotations) and split(excludedTypes) once for each request-mapping method parameter. Each call runs String.split, trims every entry, and builds a new stream. The property values don't change during an analysis, so this is repeated work across every controller method in the project. You could parse each property once, for example lazily into a List<String>/Set<String> on first visitNode, or in setContext, and reuse the result.

Verification Rules 2/2 met Repos 5 inspected · PRs 1 inspected

Functional validation No results

Rules 2 passed 2 not applicable

✅ Internal artifact registries
✅ Repository license compliance

Broader impact Repos 5 inspected PRs 1 inspected

Cross-repo 5 repositories inspected 0 open impacts

SonarSource/sonarqube Inspected
SonarSource/sonarlint-intellij Inspected
SonarSource/sonarlint-eclipse Inspected
SonarSource/sonarlint-vscode Inspected
SonarSource/sonar-java-symbolic-execution Inspected

Cross-PR 1 PR inspected 0 open impacts

PR 6308: SONARJAVA-7137 Optionally rely on source paths to resolve types during analyses Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[aurelien-coet-sonarsource]

LGTM !

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube