No material or immediate-danger concern was identified in this review.
This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.
0 immediate danger0 material3 low
What this review found
No material or immediate-danger item was identified.
Contextual expected matches (3)
Gitleaks reported jwt
Expected behavior · high confidence
The flagged value is a Supabase anon key, which is designed to be embedded in client-side code. It only allows access that the backend explicitly permits through its security rules. This is a normal pattern for apps using Supabase.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule jwt. The match applies to this repository.
Contextual assessment: Gitleaks matched a JWT-like pattern on the SUPABASE_ANON_KEY constant at line 23. This is a Supabase anon public key, explicitly designed to be shipped in client-side code. Supabase anon keys are not secret credentials; they identify the project for client-side access and rely on Row Level Security for authorization. The key is used in the Authorization Bearer header for fetch calls to the project's own Supabase edge functions, matching the extension's stated purpose as a hosted memory service. The user's actual API key is stored separately in extension_settings and sent via x-api-key header. No secret credential is exposed.
The flagged value is a Supabase anon key, which is designed to be embedded in client-side code. It only allows access that the backend explicitly permits through its security rules. This is a normal pattern for apps using Supabase.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule jwt. The match applies to this repository.
Contextual assessment: Gitleaks matched a JWT-like pattern on the SUPABASE_ANON_KEY constant. This is a Supabase anon public key, which is explicitly designed to be shipped in client-side code. Supabase anon keys are not secret credentials; they identify the project for client-side access and rely on Row Level Security for authorization. The key is used in the Authorization Bearer header for fetch calls to the project's own Supabase edge functions, which matches the extension's stated purpose as a hosted memory service. The user's actual API key is stored separately in extension_settings and sent via x-api-key header. No secret credential is exposed.
The scanner flagged that the code has both network requests and code-execution-like patterns in the same file. In reality, the network responses are just displayed as text in the UI and the code-execution patterns are harmless UI helpers. No downloaded code is ever executed.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution. The match applies to this repository.
Contextual assessment: The scanner flagged a broad line range (332-893) correlating network retrieval (fetch) with a suspected code execution sink. Reviewing the actual code, the fetch calls go to the extension's own Supabase backend endpoints (ingest, retrieve, register, usage, delete). The responses are parsed as JSON and used to update DOM elements via jQuery .text() and .html() with static or locally-constructed strings. There is no eval(), new Function(), setTimeout with string argument, or other dynamic code execution sink that processes network-retrieved data. The setTimeout calls use function references. The inline onclick handlers in banner HTML templates execute only this.parentElement.remove(), not network data. This is a false-positive correlation.