[GH-ISSUE #9211] /api/config route is open to the public exposing google client and api keys #102416

Closed
opened 2026-05-17 23:45:39 -05:00 by GiteaMirror · 8 comments
Owner

Originally created by @jamie1911 on GitHub (Feb 1, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/9211

Bug Report


Installation Method

docker run -p 3000:8080 -e OLLAMA_BASE_URL=http://192.168.1.120:11434 -e GOOGLE_DRIVE_CLIENT_ID="sssx" -e GOOGLE_DRIVE_API_KEY="xgdkjhgdfg" -v /etc/open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui

Environment

  • Open WebUI Version: 0.5.7

  • Operating System: Ubuntu 24.04

Confirmation:

  • I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

If you curl the sites configuration while being an unauthenticated anonymous user, you get denied:

curl https://aibot.mysite.com/api/config
{"detail":"Not authenticated"}

Actual Behavior:

Using an unauthenticated curl call, the sites configuration is dumped, specifically, the Google API client Id and API key:

curl https://aibot.mysite.com/api/config
{
    "status": true,
    "name": "Open WebUI",
    "version": "0.5.7",
    "default_locale": "",
    "oauth": {
        "providers": {}
    },
    "features": {
        "auth": true,
        "auth_trusted_header": false,
        "enable_ldap": false,
        "enable_api_key": false,
        "enable_signup": false,
        "enable_login_form": true,
        "enable_websocket": true
    },
    "google_drive": {
        "client_id": "sssx",
        "api_key": "xgdkjhgdfg"
    }
}

Description

Bug Summary:
Looking at https://github.com/open-webui/open-webui/pull/7900 it seems the lines of code where this is introduced: https://github.com/open-webui/open-webui/blob/main/backend/open_webui/main.py#L1010-L1012

I'm wondering if a mistake was made and it should have been placed within the lines of: https://github.com/open-webui/open-webui/blob/main/backend/open_webui/main.py#L995-L1008

Originally created by @jamie1911 on GitHub (Feb 1, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/9211 # Bug Report --- ## Installation Method ``` docker run -p 3000:8080 -e OLLAMA_BASE_URL=http://192.168.1.120:11434 -e GOOGLE_DRIVE_CLIENT_ID="sssx" -e GOOGLE_DRIVE_API_KEY="xgdkjhgdfg" -v /etc/open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui ``` ## Environment - **Open WebUI Version:** 0.5.7 - **Operating System:** Ubuntu 24.04 **Confirmation:** - [x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior: If you curl the sites configuration while being an unauthenticated anonymous user, you get denied: ``` curl https://aibot.mysite.com/api/config {"detail":"Not authenticated"} ``` ## Actual Behavior: Using an unauthenticated curl call, the sites configuration is dumped, specifically, the Google API client Id and API key: ``` curl https://aibot.mysite.com/api/config { "status": true, "name": "Open WebUI", "version": "0.5.7", "default_locale": "", "oauth": { "providers": {} }, "features": { "auth": true, "auth_trusted_header": false, "enable_ldap": false, "enable_api_key": false, "enable_signup": false, "enable_login_form": true, "enable_websocket": true }, "google_drive": { "client_id": "sssx", "api_key": "xgdkjhgdfg" } } ``` ## Description **Bug Summary:** Looking at https://github.com/open-webui/open-webui/pull/7900 it seems the lines of code where this is introduced: https://github.com/open-webui/open-webui/blob/main/backend/open_webui/main.py#L1010-L1012 I'm wondering if a mistake was made and it should have been placed within the lines of: https://github.com/open-webui/open-webui/blob/main/backend/open_webui/main.py#L995-L1008
Author
Owner

@tjbck commented on GitHub (Feb 1, 2025):

@taylorwilsdon

<!-- gh-comment-id:2629129134 --> @tjbck commented on GitHub (Feb 1, 2025): @taylorwilsdon
Author
Owner

@taylorwilsdon commented on GitHub (Feb 3, 2025):

👀 let me take a look today!

<!-- gh-comment-id:2631517630 --> @taylorwilsdon commented on GitHub (Feb 3, 2025): 👀 let me take a look today!
Author
Owner

@taylorwilsdon commented on GitHub (Feb 3, 2025):

Sorry about that, yeah it's basically as simple as just moving it into the authenticated block. For what it's worth, these are secrets in the loosest sense of the term - an oauth client ID & the key that allows the picker API to be invoked, but they're not providing access to any particular resource. The user must complete their own oauth flow and authorize the application to view their own files before access is in play. developer-key (the "API_KEY" value here) is required for the picker API component and Google considers it acceptable to expose to non-admin users in the frontend so long as you strictly scope and restrict it in the Google Cloud console (for example, limiting allowed referrers to your domain and permitting access only to the specific API). This ensures that even if someone manages to extract the key, it won’t be usable outside your approved domains and services. PR to move inside authenticated block, I verified it continues to work as expected.

https://github.com/open-webui/open-webui/pull/9287

<!-- gh-comment-id:2631601453 --> @taylorwilsdon commented on GitHub (Feb 3, 2025): Sorry about that, yeah it's basically as simple as just moving it into the authenticated block. For what it's worth, these are secrets in the loosest sense of the term - an oauth client ID & the key that allows the picker API to be invoked, but they're not providing access to any particular resource. The user must complete their own oauth flow and authorize the application to view their own files before access is in play. `developer-key` (the "API_KEY" value here) is required for the picker API component and Google considers it acceptable to expose to non-admin users in the frontend so long as you strictly scope and restrict it in the Google Cloud console (for example, limiting allowed referrers to your domain and permitting access only to the specific API). This ensures that even if someone manages to extract the key, it won’t be usable outside your approved domains and services. PR to move inside authenticated block, I verified it continues to work as expected. https://github.com/open-webui/open-webui/pull/9287
Author
Owner

@taylorwilsdon commented on GitHub (Feb 3, 2025):

PR #9287 will ensure only authenticated users can retrieve the Drive config items when merged

<!-- gh-comment-id:2631608002 --> @taylorwilsdon commented on GitHub (Feb 3, 2025): PR #9287 will ensure only authenticated users can retrieve the Drive config items when merged
Author
Owner

@jamie1911 commented on GitHub (Feb 3, 2025):

Sorry about that, yeah it's basically as simple as just moving it into the authenticated block. For what it's worth, these are secrets in the loosest sense of the term - an oauth client ID & the key that allows the picker API to be invoked, but they're not providing access to any particular resource. The user must complete their own oauth flow and authorize the application to view their own files before access is in play. developer-key (the "API_KEY" value here) is required for the picker API component and Google considers it acceptable to expose to non-admin users in the frontend so long as you strictly scope and restrict it in the Google Cloud console (for example, limiting allowed referrers to your domain and permitting access only to the specific API). This ensures that even if someone manages to extract the key, it won’t be usable outside your approved domains and services. PR to move inside authenticated block, I verified it continues to work as expected.

#9287

Thanks, that makes sense! While these are client-side secrets/keys, it does make sense to logically put them in the updated location as your https://github.com/open-webui/open-webui/pull/9287 has it.

<!-- gh-comment-id:2631616983 --> @jamie1911 commented on GitHub (Feb 3, 2025): > Sorry about that, yeah it's basically as simple as just moving it into the authenticated block. For what it's worth, these are secrets in the loosest sense of the term - an oauth client ID & the key that allows the picker API to be invoked, but they're not providing access to any particular resource. The user must complete their own oauth flow and authorize the application to view their own files before access is in play. `developer-key` (the "API_KEY" value here) is required for the picker API component and Google considers it acceptable to expose to non-admin users in the frontend so long as you strictly scope and restrict it in the Google Cloud console (for example, limiting allowed referrers to your domain and permitting access only to the specific API). This ensures that even if someone manages to extract the key, it won’t be usable outside your approved domains and services. PR to move inside authenticated block, I verified it continues to work as expected. > > [#9287](https://github.com/open-webui/open-webui/pull/9287) Thanks, that makes sense! While these are client-side secrets/keys, it does make sense to logically put them in the updated location as your https://github.com/open-webui/open-webui/pull/9287 has it.
Author
Owner

@jamie1911 commented on GitHub (Feb 3, 2025):

PR #9287 will ensure only authenticated users can retrieve the Drive config items when merged

I think some frontend code will need to be tweaked to support this, specifically from my glance at the code, https://github.com/taylorwilsdon/open-webui/blob/main/src/lib/utils/google-drive-picker.ts#L7-L13 . I believe the json path would now be different.

<!-- gh-comment-id:2631628625 --> @jamie1911 commented on GitHub (Feb 3, 2025): > PR [#9287](https://github.com/open-webui/open-webui/pull/9287) will ensure only authenticated users can retrieve the Drive config items when merged I think some frontend code will need to be tweaked to support this, specifically from my glance at the code, https://github.com/taylorwilsdon/open-webui/blob/main/src/lib/utils/google-drive-picker.ts#L7-L13 . I believe the json path would now be different.
Author
Owner

@taylorwilsdon commented on GitHub (Feb 3, 2025):

@jamie1911 no it's still returned in the same payload with the same key to access it, just doesn't get returned if you're not signed in now.

<!-- gh-comment-id:2631632605 --> @taylorwilsdon commented on GitHub (Feb 3, 2025): @jamie1911 no it's still returned in the same payload with the same key to access it, just doesn't get returned if you're not signed in now.
Author
Owner

@jamie1911 commented on GitHub (Feb 3, 2025):

@jamie1911 no it's still returned in the same payload with the same key to access it, just doesn't get returned if you're not signed in now.

You're right, thanks!!

<!-- gh-comment-id:2631635853 --> @jamie1911 commented on GitHub (Feb 3, 2025): > [@jamie1911](https://github.com/jamie1911) no it's still returned in the same payload with the same key to access it, just doesn't get returned if you're not signed in now. You're right, thanks!!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#102416