VNX-1173: Improper Use of Validation Framework

Reports Java code that has a validation framework available but leaves an input path out of it. Reported: in a Spring @Controller/@RestController that validates request bodies with @Valid elsewhere in the same file, a handler parameter bound with @RequestBody (including @RequestBody(required = false) and with other annotations such as @NotNull beside it) to an application type (a DTO, or a List/Set of one) without @Valid or @Validated (fully qualified @jakarta.validation.Valid counts), so that endpoint accepts the object unchecked; Bean Validation constraints (@Size, @Pattern, @Max, @NotBlank and the rest) on a @RequestParam, @PathVariable or @RequestHeader parameter in a controller with no @Validated anywhere in the file, which Spring before Framework 6.1 silently ignores (skipped when the project pins Spring Boot 3.2+ or Spring Framework 6.1+ in pom.xml (parent, spring-boot.version property or spring-boot-dependencies import), build.gradle(.kts), a Gradle version catalog or gradle.properties, where controller method validation is built in); and a Struts 1 <action> mapping with validate="false", which skips the ActionForm and Validator checks. Not reported: bodies bound to String, Map, JsonNode and other raw types, controllers that never use @Valid (the rule cannot tell which DTOs carry constraints), a @Validated controller, validate="true", XML comments, and test files. A BindingResult that is declared and never read is VNX-20's finding.

Field	Value
Rule ID	`VNX-1173`
Severity	Low
SARIF level	`note`
Kind	`sast`
Languages	Java, Any file
CWE	CWE-1173
CAPEC	CAPEC-66
ATT&CK	T1190
CWSS vector	`CWSS:1.0/TI:L/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:L/DI:H/EX:L/EC:N/P:L`
Tags	`improper-use-validation-framework` `cwe-1173`
Source	`internal/sast/rules/vnx-1173.rego`

Overview

VNX-1173 maps to CWE-1173: Improper Use of Validation Framework. Reports Java code that has a validation framework available but leaves an input path out of it. Reported: in a Spring @Controller/@RestController that validates request bodies with @Valid elsewhere in the same file, a handler parameter bound with @RequestBody (including @RequestBody(required = false) and with other annotations such as @NotNull beside it) to an application type (a DTO, or a List/Set of one) without @Valid or @Validated (fully qualified @jakarta.validation.Valid counts), so that endpoint accepts the object unchecked; Bean Validation constraints (@Size, @Pattern, @Max, @NotBlank and the rest) on a @RequestParam, @PathVariable or @RequestHeader parameter in a controller with no @Validated anywhere in the file, which Spring before Framework 6.1 silently ignores (skipped when the project pins Spring Boot 3.2+ or Spring Framework 6.1+ in pom.xml (parent, spring-boot.version property or spring-boot-dependencies import), build.gradle(.kts), a Gradle version catalog or gradle.properties, where controller method validation is built in); and a Struts 1 mapping with validate=“false”, which skips the ActionForm and Validator checks. Not reported: bodies bound to String, Map, JsonNode and other raw types, controllers that never use @Valid (the rule cannot tell which DTOs carry constraints), a @Validated controller, validate=“true”, XML comments, and test files. A BindingResult that is declared and never read is VNX-20’s finding.

Why This Matters

This weakness class (Improper Use of Validation Framework) creates a concrete exploit surface: the rule searches for the concrete source-level patterns most commonly associated with CWE-1173 and surfaces them for review. Each finding should be evaluated in context, the rule catches the pattern, not the context.

What Gets Flagged

@PostMapping
public OrderDto create(@Valid @RequestBody CreateOrderRequest req) { ... }

@PutMapping("/{id}")   // FLAGGED: same controller, body not validated
public OrderDto update(@PathVariable long id, @RequestBody UpdateOrderRequest req) { ... }

// FLAGGED (no @Validated on the class, Spring < 6.1)
public List<Product> search(@RequestParam @Size(max = 64) String q) { ... }

<!-- struts-config.xml: FLAGGED -->
<action path="/transfer" type="com.example.TransferAction" validate="false">

Remediation

Review each flagged line and determine whether the pattern represents a real instance of CWE-1173 or a false positive.
Replace the flagged construct with a documented safe alternative appropriate to your language and framework.
For confirmed false positives, add a # vulnetix-ignore: VNX-1173 comment on the line.
Ensure equivalent test coverage exists to prevent regression.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-1173
// nosec vnx-1173

Or record an ignore rule: vulnetix ignore add --rule vnx-1173 --reason "...". See Suppressing findings.