bbqs-uploader is a fully static, backend-free page (see package.json's description) — there is no server to hold a session, set an httpOnly cookie, or otherwise keep a credential out of client-side JavaScript. Any credential used to call the DANDI API (the pasted API key before this PR, the OAuth access/refresh tokens since) has to live somewhere the browser's JS can read it back out. That constraint doesn't go away; the sections below are about managing it deliberately instead of by accident.

A token sitting in localStorage/sessionStorage is only exploitable remotely if an attacker can first get JavaScript to execute on this origin (XSS) — at which point they could just make authenticated requests directly, credential theft is a bonus, not the primary damage. So before treating a "clear text storage of sensitive information" scanner alert as something to dismiss or work around, actually check whether that precondition holds:

grep -rn "innerHTML\|outerHTML\|insertAdjacentHTML" src/

For every hit, confirm any dynamic (user-supplied, API-returned, or otherwise non-literal) string is assigned via .textContent (or an element.value type property) rather than concatenated into the HTML string itself. A fixed, hardcoded template assigned via innerHTML is fine — the risk is interpolating untrusted data into HTML source, not the property name. As of this writing, all three innerHTML uses in src/ (fileRow.ts, fileTree.ts, the "What's New" modal) follow this pattern: static skeleton via innerHTML, then .textContent for anything dynamic (file names, dandiset titles, usernames). Keep it that way — this is the property that makes accepting client-side token storage a reasonable call for this app.

Also keep an eye on:

• Third-party runtime scripts are opt-in only. index.html loads Google Analytics' gtag.js (see "Google Analytics" below), but only after the user explicitly accepts via the consent banner; nothing else loads a CDN <script> tag. A compromised third-party script is the other realistic way a token in storage gets exfiltrated even without a bug in this app's own code, so keep the list of scripts that load unconditionally at page load empty.
• Minimal runtime dependencies. Currently just spark-md5. Every added runtime dependency is something that could be compromised upstream and ship code that reads localStorage; don't add one without a reason.

src/lib/dandisets.ts's listIncomingDandisets calls a companion service (not part of this repo, currently hosted on PythonAnywhere) to check whether a BBQS/EMBER admin co-owns an "Incoming: " dandiset, forwarding the signed-in user's live DANDI OAuth access token in the Authorization header on every load of the picker.

This is a real, deliberate expansion of the trust boundary: previously the token only ever went to DANDI itself. Now it also goes to a third-party host this repo doesn't control. If that host is compromised, misconfigured, or just logs request headers by default, a live token capable of acting as the signed-in user leaks. Before pointing this at a different or newly-deployed instance of that service, confirm it does not log the Authorization header or the token it extracts from it, and that it's served over HTTPS.

This is also not a hard access-control boundary even when working correctly: real upload authorization is still enforced entirely by DANDI's own dandiset ownership permissions. The service's adminOwned answer only curates what this app's picker shows; it grants no capability on its own.

index.html loads GA (gtag.js, measurement ID G-8W96QLN0W8) gated behind a cookie-consent banner, copied from the pattern used by dandi/usage-page:

• The consent choice ('accepted' / 'declined' / unset) is stored in localStorage under bbqs-uploader.analytics-consent and re-checked on every page load.
• Declining (or leaving the banner unanswered) never fetches gtag.js, never sets window.dataLayer/window.gtag, and never touches a GA cookie. Accepting is the only path that appends the gtag.js <script> tag.
• This is not sensitive data: the stored value is a UI preference, not a credential, so it doesn't fall under the "clear text storage" checklist above.

1. Run the innerHTML/XSS check above. If it turns up a real injection point, fix that — it's a bigger problem than where the token sits, and no storage choice below fixes it.
2. If it doesn't, decide how much persistence the credential actually needs, in order of decreasing exposure:
   • localStorage — survives browser restarts. Lowest friction, largest exposure window (persists until explicitly cleared or signed out).
   • sessionStorage — survives reloads, clears on tab close. Meaningfully smaller window than localStorage, but scanners (CodeQL included) generally flag this the same way — expect to still need step 3.
   • In-memory only (a plain module variable, no Storage API) — cleared on any reload/navigation, not just tab close. Removes the flagged sink entirely, at the cost of re-authenticating on every page load.
3. If you land on localStorage or sessionStorage, dismiss the resulting alert as an accepted, documented trade-off (link this file) rather than trying to "encrypt" the value client-side first — any decryption key reachable by this app's own JS is reachable by an attacker's injected JS too, so client-side encryption of a client-held secret is not a real mitigation, just a false sense of one.

Precedent: PR #16 proposed dropping persistence entirely for the pasted API key (in-memory / re-enter-each-session, option 2's strictest form above) rather than dismissing its alert. PR #19 replaced that key with OAuth tokens persisted in localStorage — decide the same question for those tokens using the checklist above rather than assuming the OAuth migration made #16's alert moot; it's the same sink, just renamed.

• Access tokens use django-oauth-toolkit's unconfigured default lifetime (~10 hours on the EMBER archive, per its settings). ensureFreshOAuth() in src/main.ts refreshes the access token automatically (60s before expiry) on every connection check and upload, using the refresh_token — so in practice a signed-in user isn't prompted to re-authenticate every 10 hours, only when the refresh token itself is invalidated, the user explicitly signs out (which revokes it via /oauth/revoke_token/), or stored settings are cleared.