Validate route-level :slug, :projectId, and :issueId params before fetching in detail pages

[Jagadeeshftw]

📌 Description

The router in src/app/App.tsx passes untrusted path params (:slug, :projectId, :issueId, :ecosystemId, :eventId) straight into detail pages via routeWrappers.tsx, which only null-checks presence. A malformed projectId is then interpolated directly into API endpoints like /projects/${projectId}. Add lightweight param-shape validation (allowed charset/length) in the wrappers so obviously invalid params render the NotFound/empty state instead of issuing a doomed request.

💡 Why it matters: Forwarding arbitrary path segments into API URLs wastes requests and can be abused to probe the backend.

🧩 Requirements and context

• Define a small validator for id/slug params (e.g. UUID-ish or [a-z0-9-] bounded length).
• Validate in ProjectDetailPageRoute, IssueDetailPageRoute, EcosystemDetailPageRoute, and the blog :slug path.
• Render the existing not-found/empty state for invalid params rather than fetching.
• Keep the existing presence null-guards.
• Test valid and malformed params per wrapper.

Non-functional requirements

• Must be secure, tested, and documented.
• Should be efficient and easy to review.

🛠️ Suggested execution

1. Fork the repo and create a branch

git checkout -b security/validate-route-params

2. Implement changes

• Write/modify the relevant source: src/features/dashboard/routeWrappers.tsx (+ blog article page)
• Write comprehensive tests: routeWrappers.test.tsx
• Add documentation: inline TSDoc on the validator
• Include TSDoc doc comments
• Validate security assumptions: params constrained before URL interpolation

3. Test and commit

• Run tests:

npm test -- routeWrappers

• Cover edge cases: empty, overly long, path-traversal-like, encoded params
• Include test output and security notes in the PR description.

Example commit message

security(routing): validate route params before detail fetches

✅ Acceptance criteria

• Shared param validator added
• Applied to all id/slug wrappers
• Invalid params show not-found/empty state
• Tests cover malformed params

🔒 Security notes

Reject path-traversal (.., /) and encoded variants before they reach apiRequest.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[Emmanuellsensai]

hi, i would like to work on this issue

[abdrassulov]

Hi! I would love to work on this issue to validate the route-level :slug, :projectId, and :issueId parameters before fetching in detail pages. Could you please assign it to me?

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.

[Marodrumz]

Hi Grainlify team,

I would like to work on this issue because route params are untrusted input and should be validated before being passed into detail pages or interpolated into API URLs. If malformed slug, projectId, issueId, ecosystemId, or eventId values are forwarded directly into requests, the frontend can waste API calls and expose the backend to unnecessary probing.

My plan is to study src/app/App.tsx, src/features/dashboard/routeWrappers.tsx, the affected detail pages, and the blog slug route first. Then I will add a small shared validator for route params and apply it before any detail fetch can happen.

I will focus on:

Keeping the existing presence/null guards
Adding lightweight shape validation for ID and slug params
Rejecting empty, overly long, path-traversal-like, and encoded unsafe params
Applying validation to ProjectDetailPageRoute
Applying validation to IssueDetailPageRoute
Applying validation to EcosystemDetailPageRoute
Applying validation to the blog :slug route
Rendering the existing not-found or empty state for invalid params
Avoiding doomed API requests for malformed params
Adding TSDoc documentation for the validator
Adding tests for valid and malformed params per wrapper
Running npm test -- routeWrappers and any configured lint/typecheck checks

I have experience with React routing, frontend security, TypeScript validation, API boundary safety, and test-focused fixes. I understand that this task should stay small and focused: validate route params before URL interpolation, preserve existing valid behavior, and avoid changing detail-page fetch logic unnecessarily.

If assigned, I can start immediately and submit a focused PR within the 96-hour timeframe with validation, tests, and security notes confirming malformed params are rejected before reaching apiRequest.

[gloskull]

Hi, I’d love to work on this issue. I have 4 years of experience across backend, frontend, full-stack, and smart contract development. I understand the task clearly and can deliver a clean, efficient, well-tested solution on time, with strong focus on code quality and maintainability. My PR will be submitted in under 10 hours.