Harden data access, document uploads, and secret handling#42
Open
kveton wants to merge 1 commit intowillchen96:mainfrom
Open
Harden data access, document uploads, and secret handling#42kveton wants to merge 1 commit intowillchen96:mainfrom
kveton wants to merge 1 commit intowillchen96:mainfrom
Conversation
- lock Supabase app tables behind backend service-role APIs - add safe profile endpoints and stop exposing user API keys to the browser - encrypt user LLM API keys at rest - require dedicated download signing and API-key encryption secrets - validate uploaded PDF/DOC/DOCX bytes before storage - tighten tabular-review and chat project authorization - remove sensitive raw LLM/document logging - update vulnerable dependencies and add focused backend security tests
Lef-F
added a commit
to Lef-F/mike
that referenced
this pull request
May 8, 2026
PR willchen96#32 (commit 284890d) added the user_mcp_servers table holding MCP connector configuration, including request "headers" (typically a Bearer token) and "oauth_tokens" (refresh + access tokens) for OAuth 2.1 connectors. PR willchen96#42 (commit 9979566) introduced 004_security_ lockdown.sql which revokes anon and authenticated grants from every user-data table — but user_mcp_servers was added between PRs and slipped through. The result: a user authenticated via Supabase could query their own oauth_tokens / headers row directly through PostgREST, bypassing the "backend service-role only" pattern PR willchen96#42 established. Worse, any future regression of the per-row RLS policy would expose every users credentials, not just app data. Add the missing revoke to both 004 and the equivalent block at the bottom of 000_one_shot_schema.sql so fresh deployments are locked down too. Also alter table ... enable row level security for explicitness even though migration 002 already enables it.
Lef-F
added a commit
to Lef-F/mike
that referenced
this pull request
May 8, 2026
Threat model: a database compromise or stolen backup of user_mcp_servers
should not yield usable bearer tokens or refresh tokens for third-party
connectors. Migration 003 explicitly deferred encryption ("Per-row
encryption is intentionally deferred to a separate hardening PR"); this
is that PR.
Storage format: serialize the JSON value, encrypt the resulting string
with the existing AES-256-GCM "enc:v1:" envelope from apiKeys.ts, and
store the ciphertext as a JSON-string scalar in the existing jsonb
column (a JSON string is itself valid jsonb, so no schema change is
needed). Encrypting the whole blob keeps the format trivial, avoids
leaking shape ("this row has a refresh_token"), and minimizes cipher
operations vs per-leaf encryption. On read we sniff
typeof === "string" && startsWith("enc:v1:") to distinguish from legacy
plaintext objects.
New helpers encryptJsonBlob / decryptJsonBlob / needsJsonBlobUpgrade
live alongside the existing per-string helpers in apiKeys.ts and reuse
them underneath. Call sites updated: DbOAuthProvider.tokens() /
saveTokens() encrypt+decrypt oauth_tokens; saveCodeVerifier() /
codeVerifier() encrypt the PKCE verifier (using the per-string helper
since it's a single text column); mcpServers.ts POST/PATCH/test
encrypt+decrypt headers; loadEnabledMcpServersForUser decrypts each
row in place and fires off a best-effort UPDATE to upgrade legacy
plaintext rows in the background, mirroring the lazy-upgrade pattern
PR willchen96#42 introduced for LLM provider keys (commit 701535b). The
upgrade write is fire-and-forget so a failing-forever encryption
write cannot block the chat hot path on every turn, but errors are
logged so they can be detected. oauth_metadata stays plaintext —
it's discovery + DCR data, not secret. If
USER_API_KEYS_ENCRYPTION_KEY is unset, encryptApiKey throws and the
write fails closed, which is the correct behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR implements a focused security hardening pass across the backend, frontend, migrations, and dependency locks.
What changed
user_profilesaccess with safe backend profile APIs.has_*_api_keybooleans to the browser.DOWNLOAD_SIGNING_SECRETandUSER_API_KEYS_ENCRYPTION_KEYsecrets.Validation
backend:npm testpassed, 9 tests.backend:npm run buildpassed.frontend:npm run buildpassed with placeholder public env values.backend+frontend:npm audit --jsonreports 0 vulnerabilities./healthreturned 200./loginand/signuprender, protected routes redirect to/login, and no Next error overlays or material console errors appeared.Notes
Authenticated Supabase/R2 flows were not smoke-tested locally because this workspace only has example env files, not real local secrets.