Potential fix for code scanning alert no. 84: Unvalidated dynamic method call #5746
+6
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Potential fix for https://github.com/FlowiseAI/Flowise/security/code-scanning/84
In general, to fix this issue you must ensure that the function you dynamically call is both (a) associated with an allowed identifier and (b) actually a function that is safe to invoke. For objects used as maps, that means rejecting keys that are not own properties and confirming the retrieved value has the expected type before invocation; alternatively, you can migrate to a
Mapand usehas/getwith the same checks.The best minimal fix here, without changing existing functionality, is to add validation around the dynamic lookup and invocation in
getRateLimiter(and keepgetRateLimiterByIdsafe as well). Specifically, after you deriveidfromreq.params.id, you should: (1) ensureidis a non-empty string, (2) ensurethis.rateLimitershas thatidas an own property (not inherited from the prototype chain) usingObject.prototype.hasOwnProperty.call, and (3) ensurethis.rateLimiters[id]is a function before calling it. If any of these checks fail, fall back tonext()so that no unexpected method is invoked or runtime error thrown. This preserves current behavior for valid IDs (they’re still routed to the correct rate limiter) while hardening the code against malicious or malformed input.Concretely, in
packages/server/src/utils/rateLimit.ts, you need to modify the body ofgetRateLimiter()(lines 128–135) to add these checks before callingidRateLimiter. You can also slightly tightengetRateLimiterByIdin the same style (even though itsidparameter is not user-controlled in this context) for consistency and extra safety. No new imports are required; the validation uses built-inObject.prototype.hasOwnProperty.Suggested fixes powered by Copilot Autofix. Review carefully before merging.