Task Management API Exposes XSS Risk: Unfiltered Title and Description Inputs Open to Script Injection

A critical security vulnerability exists in a task management API, where the endpoints for creating and updating tasks accept user input without any sanitization. The `POST /api/v1/tasks` and `PATCH /api/v1/tasks/:id` endpoints directly pass `title` and `description` strings to the database, creating a direct path for HTML and JavaScript injection. If a frontend application were to render this data as raw HTML, it could execute malicious scripts, leading to cross-site scripting (XSS) attacks. While the referenced React frontend currently escapes content by default, the API's design violates the principle of defense in depth by placing complete trust in client-side security.

The vulnerability is rooted in the current Python code, where the `TaskCreate` Pydantic model accepts payloads without validation. The task creation handler instantiates a `Task` object directly with user-provided `title` and `description` fields, with no filtering or sanitization logic in place. This oversight means that classic XSS payloads like `<script>alert(1)</script>` or `<img onerror=alert(1) src=x>` could be stored and potentially executed.

To mitigate this risk, the requirements specify implementing server-side input validation and sanitization. This includes adding Pydantic validators to the `TaskCreate` and `TaskUpdate` schemas to strip HTML tags from both fields before storage. Additional validation rules must reject empty titles and enforce a 255-character limit at the application layer, not solely relying on database constraints. Comprehensive testing for various XSS payloads is mandated to confirm the fixes. This exposure highlights a common but dangerous architectural flaw where backend services assume client applications will handle security, creating a single point of failure that could compromise user data and session integrity.