[GH-ISSUE #16539] feat: Add user-consent gate for external resources embedded in AI responses (images, iframes, etc.) #17948

New Issue

GiteaMirror · 2026-04-19T23:50:58-05:00

GiteaMirror commented

2026-04-19 23:50:58 -05:00

Originally created by @dynumo on GitHub (Aug 12, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16539

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

While testing Open WebUI’s image-generation tool settings, the Kimi K2 LLM model (which has no native image-generation capability) unexpectedly returned a response that embedded an image from a third-party service. The image was generated on-the-fly by passing my prompt as URL parameters to an external endpoint, then hot-linked back into the chat as an image. This happened silently - no warning, no consent prompt to load an external resource, and no indication that my prompt had been transmitted to an outside server. It was on inspection with my browser tools that I worked out what had happened.

If a malicious or compromised model were to do the same thing, it could:

leak user prompts, IP addresses, or browser fingerprints,
serve unwanted or harmful content, or
track users via invisible pixels or iframes.

Desired Solution you'd like

Implement a user-consent gate for all external resources embedded in AI responses (images, iframes, audio, video, etc.) - similar to the “Load images from this sender?” prompt in email clients.

Specifically:

Block-by-default sandbox: Render every AI message in a sandboxed container whose Content-Security-Policy disallows network requests (default-src 'none').
Placeholder UI: Replace each external URL embed with a small inline placeholder that shows the hostname and a “Load” button.
Per-resource consent: Clicking “Load” relaxes the CSP only for that resource and fetches it.
User-level toggle: Settings page with three modes:
- Always ask (default)
- Allow-list of trusted domains
- Block all external resources

Alternatives Considered

Server-side URL stripping: Breaks legitimate diagrams, documentation screenshots, and other helpful external assets.

Additional Context

No response

Originally created by @dynumo on GitHub (Aug 12, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16539 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description While testing Open WebUI’s image-generation tool settings, the Kimi K2 LLM model (which has no native image-generation capability) unexpectedly returned a response that embedded an image from a third-party service. The image was generated on-the-fly by passing my prompt as URL parameters to an external endpoint, then hot-linked back into the chat as an image. This happened silently - no warning, no consent prompt to load an external resource, and no indication that my prompt had been transmitted to an outside server. It was on inspection with my browser tools that I worked out what had happened. If a malicious or compromised model were to do the same thing, it could: - leak user prompts, IP addresses, or browser fingerprints, - serve unwanted or harmful content, or - track users via invisible pixels or iframes. ### Desired Solution you'd like Implement a user-consent gate for all external resources embedded in AI responses (images, iframes, audio, video, etc.) - similar to the “Load images from this sender?” prompt in email clients. Specifically: - Block-by-default sandbox: Render every AI message in a sandboxed container whose Content-Security-Policy disallows network requests (default-src 'none'). - Placeholder UI: Replace each external URL embed with a small inline placeholder that shows the hostname and a “Load” button. - Per-resource consent: Clicking “Load” relaxes the CSP only for that resource and fetches it. - User-level toggle: Settings page with three modes: - - Always ask (default) - - Allow-list of trusted domains - - Block all external resources ### Alternatives Considered Server-side URL stripping: Breaks legitimate diagrams, documentation screenshots, and other helpful external assets. ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-19 23:50:58 -05:00

GiteaMirror referenced this issue

2026-04-20 05:29:52 -05:00

[PR #17948] [MERGED] build(deps): bump chromadb from 1.0.20 to 1.1.0 in /backend #24616

GiteaMirror referenced this issue

2026-04-25 12:39:10 -05:00

[PR #17948] [MERGED] build(deps): bump chromadb from 1.0.20 to 1.1.0 in /backend #40246

GiteaMirror referenced this issue

2026-04-29 23:00:22 -05:00

[PR #17948] [MERGED] build(deps): bump chromadb from 1.0.20 to 1.1.0 in /backend #47664

Sign in to join this conversation.