Trust Boundary Input Sanitization (Cross-Boundary Data Validation)
Description
Enforce explicit validation and sanitization at every architectural trust boundary — points where data crosses from a less-trusted context into a more-trusted one. Trust boundaries include: user input entering server-side session state, external API responses being incorporated into internal data structures, deserialized objects from untrusted sources being used as trusted application state, and inter-service communication where the calling service has different privilege levels. At each boundary, apply type validation, range checking, schema enforcement, and contextual sanitization before the data is stored or used in the trusted context. This prevents an attacker from injecting malicious data that propagates through the application as if it were trusted — for example, poisoning session attributes via crafted input, or injecting control-plane directives via a deserialized object that bypasses authorization checks. Framework-level enforcement (validation middleware, schema-validated DTOs, explicit trust-zone annotations) is preferred over ad-hoc per-field checks because it provides systematic coverage and fails closed on unannotated boundaries.
CVSS Vector Impacts
| Metric | Transition | Rationale |
|---|---|---|
| Attack Complexity (AC) | L → H | The attacker must find a trust boundary crossing that lacks validation — systematic boundary enforcement via framework middleware and schema-validated DTOs eliminates the most common paths, requiring the attacker to discover an unannotated or misconfigured boundary |
| Integrity (I) | H → L | Untrusted data cannot propagate into trusted application state (session objects, internal data structures, deserialized configuration) because validation and sanitization at the boundary strips or rejects malicious content before it enters the trusted context |
CWE Relationships
Verification
Review application architecture documentation for explicit trust boundary identification. Verify that validation middleware or schema enforcement is configured at each identified boundary. Check deserialization paths for type-safe, allowlist-based deserializers.
# Expected: Trust boundary entry points use framework validation annotations or schema enforcement
# Expected: No unsafe deserialization — use type-safe alternatives (ObjectInputFilter, pickle with allowlist, yaml.safe_load)
# Expected: No direct assignment of user input to session state without validation
Remediation
JAVA_SEC=$(java -XshowSettings:all 2>&1 | grep 'java.home' | awk '{print $NF}')/conf/security/java.security; echo "Using $JAVA_SEC"
cp "$JAVA_SEC" "${JAVA_SEC}.bak-cme-1321-$(date +%Y%m%d)"
grep -q '^jdk.serialFilter=' "$JAVA_SEC" && sed -i 's|^jdk.serialFilter=.*|jdk.serialFilter=!*|' "$JAVA_SEC" || echo 'jdk.serialFilter=!*' >> "$JAVA_SEC"
SITE_DIR=$(python3 -c 'import site; print(site.getsitepackages()[0])'); echo "Using $SITE_DIR"
printf 'import yaml\nyaml.warnings({"YAMLLoadWarning": True})\n# CME-1321: Override yaml.load to require explicit Loader argument\n_original_load = yaml.load\ndef _safe_load_wrapper(data, Loader=None):\n if Loader is None:\n raise TypeError("yaml.load() requires an explicit Loader argument. Use yaml.safe_load() or pass Loader=yaml.SafeLoader for untrusted data.")\n return _original_load(data, Loader=Loader)\nyaml.load = _safe_load_wrapper\n' > "$SITE_DIR/cme_1321_yaml_safe.pth"
grep -q 'spring.mvc.throw-exception-if-no-handler-found' <app>/src/main/resources/application.properties 2>/dev/null || printf '# CME-1321: Trust boundary validation enforcement\nspring.mvc.throw-exception-if-no-handler-found=true\nserver.error.whitelabel.enabled=false\n' >> <app>/src/main/resources/application.properties
grep -q '@Validated' <app>/src/main/java/**/controller/*.java 2>/dev/null || echo 'WARNING: Controllers missing @Validated annotation — add @Validated to controller classes to enforce @Valid on request bodies at trust boundaries'