Albert
0ed2d6c0b3
- Increase logo size (48x48 desktop, 56x56 mobile) for better visibility - Add logo as favicon - Add logo to mobile header - Move user menu to navigation bars (sidebar on desktop, bottom bar on mobile) - Fix desktop chat layout - container structure prevents voice controls cutoff - Fix mobile bottom bar - use icon-only ActionIcons instead of truncated text buttons - Hide Create Node/New Conversation buttons on mobile to save header space - Make fixed header and voice controls work properly with containers 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
63 lines
2.2 KiB
Markdown
63 lines
2.2 KiB
Markdown
# Security Considerations
|
|
|
|
## 🚨 KNOWN SECURITY ISSUES
|
|
|
|
### Voice Transcription API Key Exposure
|
|
|
|
**Status:** Known issue - needs fix before production
|
|
|
|
**Issue:** The Deepgram API key is currently exposed to the frontend when users click the microphone button for voice transcription.
|
|
|
|
**Location:** `app/api/voice-token/route.ts`
|
|
|
|
**Risk:** Users with browser dev tools can extract the API key and use it for their own purposes, potentially incurring charges or exhausting API quotas.
|
|
|
|
**Why this exists:**
|
|
- Temporary tokens from `deepgram.auth.grantToken()` fail with WebSocket connections
|
|
- Direct API key usage is currently the only working approach for client-side WebSocket transcription
|
|
|
|
**Temporary mitigations:**
|
|
- API key only exposed when user actively requests voice transcription
|
|
- Usage can be monitored through Deepgram dashboard
|
|
- Can implement rate limiting on the `/api/voice-token` endpoint
|
|
|
|
**Proper fix options:**
|
|
1. **Server-side proxy (recommended):**
|
|
- Implement a WebSocket proxy server that handles Deepgram communication
|
|
- Client connects to our proxy, proxy forwards to Deepgram with API key
|
|
- Requires stateful server infrastructure (not serverless)
|
|
|
|
2. **Usage-limited keys:**
|
|
- Use Deepgram API keys with strict usage limits
|
|
- Rotate keys frequently
|
|
- Implement server-side rate limiting per user
|
|
|
|
3. **Alternative transcription approach:**
|
|
- Record audio client-side
|
|
- Send audio files to server endpoint
|
|
- Server transcribes using Deepgram API
|
|
- Less real-time but more secure
|
|
|
|
**Action Required:** Choose and implement one of the above solutions before production deployment.
|
|
|
|
---
|
|
|
|
## Other Security Best Practices
|
|
|
|
### Environment Variables
|
|
All sensitive credentials must be stored in `.env` and never committed to git:
|
|
- `DEEPGRAM_API_KEY`
|
|
- `GOOGLE_GENERATIVE_AI_API_KEY`
|
|
- `SURREAL_JWT_SECRET`
|
|
- Database credentials
|
|
|
|
### Authentication
|
|
- JWT tokens stored in httpOnly cookies
|
|
- SurrealDB permission system enforces data access controls
|
|
- OAuth flow validates user identity through ATproto
|
|
|
|
### Input Validation
|
|
- All API endpoints validate inputs server-side
|
|
- AI-generated content is sanitized before display
|
|
- GraphQL queries use parameterized inputs
|