🔒 Fix: Prevent API key leak by using secure header authentication - #81
🔒 Fix: Prevent API key leak by using secure header authentication#81savvides wants to merge 1 commit into
Conversation
This commit addresses a security vulnerability where the API key for the LLM API was being passed as a query string parameter (`key=${apiKey}`) in the `fetch` request URL. This exposure was risky because URLs are routinely logged by intermediate proxies, server logs, and browser history, potentially compromising sensitive credentials.
The fix resolves the issue by removing the `key` parameter from the URL and securely passing the API key via the `x-goog-api-key` HTTP header in the `fetch` options. Existing functionality and parsing behavior are preserved. Tested locally by executing the extension and integration test suites.
Co-authored-by: savvides <1580637+savvides@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
1 participant
🎯 What
This PR fixes a critical security issue in the Chrome extension's background service worker (
extension/background/service-worker.js) where an API key used to query the Gemini API was directly appended to the request URL as a query string parameter.Transmitting sensitive authentication material such as an API key via the URL query string is a dangerous practice. URLs are often recorded in web server access logs, proxy logs, and client browser history. This exposes the API key to potential interception by attackers or unauthorized users who gain access to these logs, leading to credential theft, abuse of quota, and potential financial impact.
🛡️ Solution
The API request logic in the
callLlmApifunction has been updated to omit the API key from the URL entirely. Instead, theapiKeyis now transmitted securely inside thex-goog-api-keyHTTP header as part of thefetchrequest. This adheres to security best practices and prevents the credentials from being logged in transit. Tested against the project's internal test scripts (test-extension.sh,smoke-test.sh,integration-test.sh) to ensure functional parity.PR created automatically by Jules for task 13363544035838974845 started by @savvides