Fix Mass Assignment on Save Custom Template

[christopherholland-workday]

Flowise-323 (See comments on CustomTemplate)

Moved from #6059 because the branches got messed up

[gemini-code-assist]

Code Review

This pull request introduces the stripProtectedFields utility to the saveCustomTemplate logic in both the controller and service layers to mitigate mass assignment vulnerabilities. It also ensures workspaceId is handled separately from the request body. Feedback suggests replacing the stripProtectedFields approach with an explicit whitelist of allowed properties for better security and to align with best practices.

[gemini-code-assist]

While using stripProtectedFields fixes the mass assignment vulnerability, a more robust and secure pattern is to use a whitelist by explicitly mapping only the allowed properties. This aligns with the repository rule to 'explicitly map allowed properties' and prevents accidental exposure of any new sensitive fields. Sensitive fields like workspaceId must be set from a trusted source (e.g., user session) rather than being mapped from the request body.

Note: framework is omitted from this mapping because its value is overwritten by logic later in the function.

customTemplate.name = body.name
customTemplate.description = body.description
customTemplate.badge = body.badge
customTemplate.usecases = body.usecases
customTemplate.type = body.type

References

1. Avoid mass assignment from request bodies to entities. Instead of using a generic assignment like Object.assign(entity, body), explicitly map allowed properties. Sensitive fields like workspaceId must be set on the server from a trusted source (e.g., user session), not from the client request body, to prevent IDOR vulnerabilities.