langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Security concern: Embedded chatbot can be hijacked by third-party domains using token in client-side script #12423

New Issue
Closed
opened 2026-02-21 19:07:20 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 19:07:20 -05:00
Owner
Copy Link
Copy Source

Originally created by @codeMonkey-shin on GitHub (Apr 1, 2025).

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I noticed a potential security concern when embedding the chatbot via the provided script like this:

window.difyChatbotConfig = {
  token: 'xxxxxxxxxxxx',
  baseUrl: 'xxxxxxxxxxx'
}

Since the token is exposed in the client-side JavaScript and there doesn’t seem to be a domain restriction set by default, it seems that anyone can copy this code and embed the chatbot on their own website—even a malicious one.

  • Third parties can reuse the bot token and host the chatbot on unauthorized websites.
  • Abuse of API resources or token quotas.

Let me know if there’s already a solution or if a security mechanism is in place that I might have missed.

Thanks again for your hard work!

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @codeMonkey-shin on GitHub (Apr 1, 2025). ### Self Checks - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. I noticed a potential **security concern** when embedding the chatbot via the provided script like this: ```javascript window.difyChatbotConfig = { token: 'xxxxxxxxxxxx', baseUrl: 'xxxxxxxxxxx' } ``` Since the token is exposed in the client-side JavaScript and there doesn’t seem to be a domain restriction set by default, it seems that **anyone can copy this code** and embed the chatbot on their own website—even a malicious one. - Third parties can reuse the bot token and host the chatbot on unauthorized websites. - Abuse of API resources or token quotas. Let me know if there’s already a solution or if a security mechanism is in place that I might have missed. Thanks again for your hard work! ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo closed this issue 2026-02-21 19:07:20 -05:00
yindo commented 2026-02-21 19:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 1, 2025):

I found two similar unsolved discussions that might be relevant to your concern:

  1. How to implement third-party application authentication when embedding Dify into a website? [1].
  2. Inquiry: How to Secure Bot Access with Login Password or Authentication? [2].

Regarding your concern, the Dify codebase does not currently provide specific security mechanisms to restrict the use of chatbot tokens to specific domains or to protect the token from being misused when embedded in client-side scripts. However, the web/public/embed.js file includes comments on how to securely embed the chatbot, emphasizing the need to define the difyChatbotConfig with the token in the HTML file before including the script [3].

For regenerating or rotating chatbot tokens, Dify uses the TokenManager class's generate_token method, which handles the revocation of old tokens and the generation of new ones [4].

If you are looking for a solution to restrict domain usage, you might need to implement additional server-side validation or domain restriction mechanisms yourself, as these features are not currently documented or available in the Dify codebase.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 1, 2025): <!-- Answer --> I found two similar unsolved discussions that might be relevant to your concern: 1. [How to implement third-party application authentication when embedding Dify into a website?](https://github.com/langgenius/dify/discussions/15624) <sup>[[1]](https://github.com/langgenius/dify/discussions/15624)</sup>. 2. [Inquiry: How to Secure Bot Access with Login Password or Authentication?](https://github.com/langgenius/dify/discussions/11684) <sup>[[2]](https://github.com/langgenius/dify/discussions/11684)</sup>. Regarding your concern, the Dify codebase does not currently provide specific security mechanisms to restrict the use of chatbot tokens to specific domains or to protect the token from being misused when embedded in client-side scripts. However, the `web/public/embed.js` file includes comments on how to securely embed the chatbot, emphasizing the need to define the `difyChatbotConfig` with the token in the HTML file before including the script <sup>[[3]](https://github.com/langgenius/dify/blob/main/web/public/embed.js)</sup>. For regenerating or rotating chatbot tokens, Dify uses the `TokenManager` class's `generate_token` method, which handles the revocation of old tokens and the generation of new ones <sup>[[4]](https://github.com/langgenius/dify/blob/main/api/libs/helper.py)</sup>. If you are looking for a solution to restrict domain usage, you might need to implement additional server-side validation or domain restriction mechanisms yourself, as these features are not currently documented or available in the Dify codebase. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/0dcb7102-498a-48b9-9c42-4ddc796cd308?feedback_type=other)</sup>
yindo commented 2026-02-21 19:07:20 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Apr 1, 2025):

For self-hosted version, you can change CORS settings to restrict domains.

https://github.com/langgenius/dify/blob/7f70cadacbdb4ebcd0ed9ef15047189feb5c8040/docker/docker-compose.yaml#L79-L80

For other security related problems, you can see these settings as well.

https://github.com/langgenius/dify/blob/7f70cadacbdb4ebcd0ed9ef15047189feb5c8040/docker/docker-compose.yaml#L414

@crazywoola commented on GitHub (Apr 1, 2025): For self-hosted version, you can change `CORS settings` to restrict domains. https://github.com/langgenius/dify/blob/7f70cadacbdb4ebcd0ed9ef15047189feb5c8040/docker/docker-compose.yaml#L79-L80 For other security related problems, you can see these settings as well. https://github.com/langgenius/dify/blob/7f70cadacbdb4ebcd0ed9ef15047189feb5c8040/docker/docker-compose.yaml#L414
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#12423
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?