T09 · Insecure Skill Coding Practices
Warning
- Location
- datagate/app.py:35
- Finding
- Unbounded Schema Validation Can Cause Resource Exhaustion## Vulnerability Details **File Location**: `datagate/models.py:10-17`, `datagate/app.py:35-42` **Vulnerability Type**: Uncontrolled resource consumption **Risk Level**: Medium ### Vulnerable Code `datagate/models.py:10-17`: ```python class ValidateRequest(BaseModel): model_config = ConfigDict(extra="forbid") json_schema: dict[str, Any] = Field( ..., description="JSON Schema to validate against." ) payload: Any = Field(..., description="The data payload to validate.") ``` `datagate/app.py:35-42`: ```python for error in sorted(validator.iter_errors(request.payload), key=lambda e: list(e.path)): path = ".".join(str(p) for p in error.absolute_path) or "$" errors.append(ValidationError(path=path, message=error.message)) return ValidateResponse( valid=len(errors) == 0, error_count=len(errors), errors=errors, ) ``` ### Technical Analysis The API accepts arbitrarily sized and deeply nested schemas and payloads. It does not impose application-level limits on body size, nesting depth, schema complexity, validation duration, or the number of generated errors. `validator.iter_errors()` can produce a large number of validation errors for an adversarial payload. The call to `sorted()` materializes the complete iterator in memory before processing begins. The application then creates and retains a second collection of Pydantic `ValidationError` objects and serializes all of them into the response. Large or complex inputs can therefore consume substantial CPU and memory at several stages: 1. Parsing the request body. 2. Checking the supplied schema. 3. Traversing the payload during validation. 4. Materializing and sorting all validation errors. 5. Constructing and serializing the complete response. Certain combinations of nested schemas, combinatorial schema constructs, and payloads containing many invalid elements can amplify validation work and response s ...[truncated 1096 chars]
- Remediation
- ## Remediation Suggestions - Enforce a strict maximum HTTP request-body size at the reverse proxy and application layers. - Add limits for schema size, payload size, nesting depth, array length, object property count, and schema complexity. - Stop validation after a configured maximum number of errors instead of materializing every error. - Avoid `sorted()` over an unbounded iterator. Iterate incrementally and terminate once the error limit is reached. - Apply per-client rate limiting and concurrency controls to the endpoint. - Configure request and worker timeouts, along with container or process CPU and memory limits. - Consider executing complex validation in an isolated worker with a bounded execution budget. - Return a truncated-results indicator when additional validation errors exist beyond the configured cap.