TeamMemberSplitDto.role (src/teams/dto/create-team.dto.ts), CreateMilestoneDto.title/description (src/milestones/dto/create-milestone.dto.ts), and CreatePoolDto.name (src/maintenance-pool/dto/create-pool.dto.ts) are all validated with only @IsString() (or @IsOptional() @IsString()), with no @MaxLength(...). The corresponding entity columns (TeamMemberSplit.role, Milestone.title/description, MaintenancePool.name) are declared @Column({ type: 'varchar', ... }) with no explicit length, which Postgres via TypeORM leaves unbounded (character varying with no limit) rather than capped.
A client can submit an arbitrarily large string for any of these fields — megabytes of text in a role label or a pool name — with no validation error at any layer, only eventually constrained by whatever HTTP body-size limit Express's default body-parser applies. This is a resource-exhaustion / data-quality concern rather than an exploit, but it's inconsistent with fields elsewhere in the same DTOs that do get range-checked (e.g. IsMoneyAmount's explicit upper bound).
Fix: add reasonable @MaxLength(...) constraints to these free-text DTO fields and matching length on their entity columns.
TeamMemberSplitDto.role(src/teams/dto/create-team.dto.ts),CreateMilestoneDto.title/description(src/milestones/dto/create-milestone.dto.ts), andCreatePoolDto.name(src/maintenance-pool/dto/create-pool.dto.ts) are all validated with only@IsString()(or@IsOptional() @IsString()), with no@MaxLength(...). The corresponding entity columns (TeamMemberSplit.role,Milestone.title/description,MaintenancePool.name) are declared@Column({ type: 'varchar', ... })with no explicitlength, which Postgres via TypeORM leaves unbounded (character varyingwith no limit) rather than capped.A client can submit an arbitrarily large string for any of these fields — megabytes of text in a
rolelabel or a poolname— with no validation error at any layer, only eventually constrained by whatever HTTP body-size limit Express's default body-parser applies. This is a resource-exhaustion / data-quality concern rather than an exploit, but it's inconsistent with fields elsewhere in the same DTOs that do get range-checked (e.g.IsMoneyAmount's explicit upper bound).Fix: add reasonable
@MaxLength(...)constraints to these free-text DTO fields and matchinglengthon their entity columns.