Standardize DTO validation: enable global ValidationPipe and annotate DTOs with class-validator

[memplethee-lab]

Summary

What: Implement a robust request/response validation layer and standardize DTOs with class-validator/class-transformer across the codebase.
Why: Reduces runtime errors, improves API reliability, and provides consistent developer experience.
Which part: DTOs, controllers, global pipes, and tests.

Problem Statement

Current limitation

• Some DTOs are missing validation decorators; global ValidationPipe may not be applied consistently.
• Inconsistent DTO structure increases risk of runtime errors and inconsistent API contracts.

Pain point

• Developers and clients receive unclear errors; tests may be flaky due to missing input validation.

Why it matters

• Proper validation improves API safety, developer productivity, and reduces potential security issues.

Proposed Solution

How it should work

• Audit all DTOs under src/**/dto and ensure they use class-validator and class-transformer decorators.
• Enforce a global ValidationPipe in src/main.ts with whitelist, forbidNonWhitelisted, and transform options.
• Add unit tests for controllers to validate input rejection/acceptance.

Expected behavior

• All incoming requests are validated and transformed to DTO instances.
• Controllers throw clear validation errors with HTTP 400 and structured messages.

Important notes

• Start with public API DTOs; prioritize portfolio, auth, and investment modules.

Implementation Guidance

Files/folders likely affected

• src/main.ts
• src//dto//*.ts
• test/** (add validation tests)

Modules/Services involved

• Global bootstrap (ValidationPipe)
• DTOs and controllers

Dependencies/prerequisites

• class-validator, class-transformer (already in package.json or add), jest tests

Suggested steps

1. Add or update global ValidationPipe in src/main.ts.
2. Add missing decorators to DTOs: @IsString, @isnumber, @IsUUID, etc.
3. Add tests verifying validation.
4. Update README with validation conventions.

Acceptance Criteria

Acceptance Criteria

• Global ValidationPipe enabled with whitelist and transform
• All public DTOs updated with class-validator decorators
• Unit tests added for validation behavior
• Documentation updated with DTO/validation conventions
• Feature passes linting and existing CI checks

Technical Notes

API changes

• Responses unchanged; request payloads will be validated more strictly, which may break bad clients.
  Database changes
• None.
  Security
• Reduces injection and malformed payload attacks.
  Performance
• Minor overhead for validation; acceptable for API servers.
  Accessibility
• Validation errors should be clear and machine-readable.
  Edge cases
• Backwards compatibility: consider a migration strategy to avoid breaking clients.

Definition of Done

• All acceptance criteria met
• Tests added and passing
• README updated

Labels

• enhancement, backend, api, documentation

Priority

• High

Estimated Difficulty

• Intermediate

Estimated Effort

• M

[sadeeq6400]

Hello maintainer,
i have thoroughly read the requirements and i am confident that i can handle this issue

[grantfox-oss]

🦊 GrantFox — @sadeeq6400 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #96)
2. Your PR will be reviewed by the SourceXXL maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@sadeeq6400's PR #101 was approved and merged by @memplethee-lab.

🏆 @sadeeq6400: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (624 total points). Track your full progress on GrantFox.

👏 Great work, @sadeeq6400! Keep contributing to SourceXXL.