Skip to content

fix(feedback): scope getAllChatMessageFeedback to the caller workspace - #6701

Open
pri12ya871 wants to merge 1 commit into
FlowiseAI:mainfrom
pri12ya871:fix/feedback-idor-6694
Open

fix(feedback): scope getAllChatMessageFeedback to the caller workspace#6701
pri12ya871 wants to merge 1 commit into
FlowiseAI:mainfrom
pri12ya871:fix/feedback-idor-6694

Conversation

@pri12ya871

Copy link
Copy Markdown

What

GET /api/v1/feedback/:chatflowid was reachable without authentication and performed no ownership check, so anyone could read feedback for any chatflow by id.

Fixes #6694

Why this shape

/api/v1/feedback is in WHITELIST_URLS (packages/server/src/utils/constants.ts:20), so authenticateToken never runs and getAllChatMessageFeedback received chatflowid straight from the URL with no workspace scoping.

The obvious fix — dropping the entry from WHITELIST_URLS — would break embedded chatbots, because POST /api/v1/feedback (routes/feedback/index.ts:6) is how public widgets submit feedback and has to stay anonymous. The GET and the POST share one whitelist entry at two different trust levels.

/api/v1/leads sits immediately below feedback in that same whitelist and is not vulnerable — getAllLeadsForChatflow resolves req.user?.activeWorkspaceId and verifies chatflow ownership before reading, which fails closed for an anonymous caller. This PR mirrors that pattern in the GET handler and leaves WHITELIST_URLS untouched.

Tests

Adds packages/server/src/controllers/feedback/index.test.ts (5 tests): anonymous caller, chatflow outside the caller's workspace, workspace scoping of the ownership lookup, missing id, and the authorized path.

I checked that the tests actually catch the bug rather than passing vacuously — reverting the controller change makes 3 of the 5 fail, including the anonymous-caller case.

tsc --noEmit and prettier --check are both clean.

Still open

updateChatMessageFeedbackForChatflow (the PUT on the same whitelisted path) also performs no workspace check — validateFeedbackForUpdate only confirms the feedback row exists. I left it out to keep this PR to a single concern; happy to fold it in here or follow up separately, whichever you prefer.

Also asked on the issue: given the responsible-disclosure policy in SECURITY.md, tell me if you would rather handle security fixes internally and I will close this.

/api/v1/feedback is in WHITELIST_URLS, so getAllChatMessageFeedback was
reachable without authentication and performed no ownership check, letting
anyone read feedback for any chatflow by id.

Mirror the getAllLeadsForChatflow pattern: resolve req.user.activeWorkspaceId
and verify the chatflow belongs to that workspace before reading feedback.
This fails closed for anonymous callers without changing WHITELIST_URLS, so
the public POST path used by embedded chatbots is unaffected.

Adds tests covering the anonymous caller, a chatflow outside the caller's
workspace, and the authorized path.

Fixes FlowiseAI#6694
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Security] Unauthenticated IDOR via feedback endpoint - getAllChatMessageFeedback has zero ownership validation

1 participant