web/.cursor/commands/security-audit.md

# Security Audit Command

Perform a comprehensive security audit of the FromChat application codebase.

## Project Context

**FromChat** is a 100% open source secure messaging application with:

- React/TypeScript frontend
- Python FastAPI backend
- Caddy reverse proxy with security headers
- WebSocket support for real-time features
- Electron support for desktop app

## Important Design Decisions (NOT Vulnerabilities)

When auditing, remember these are **intentional design choices**:

1. **Public messages endpoint** - Open forum accessible without authentication (by design)
  - The public chat is meant to be an open forum
  - Private DMs are properly E2E encrypted and require authentication
2. **Public user list** - All users visible in DMs tab (by design)
  - Users can see all registered accounts
  - This is intentional for a community-based chat app
3. **XSS protection** - Multi-layer defense already implemented:
  - React auto-escaping
  - DOMPurify for sanitization
  - Caddy CSP headers
  - Do NOT flag localStorage key storage as critical (already well-protected)
4. **File upload security** - Docker isolation in place:
  - Server runs in Docker without executable flags
  - Files cannot execute on server
  - PIL re-encodes images
  - Do NOT flag Content-Type validation as critical
5. **CSRF protection** - Not needed:
  - No cookies used
  - JWT tokens in Authorization headers only
  - CSRF attacks don't apply to this auth model
6. **Beta domain CSP** - 'unsafe-inline' is required:
  - Beta domain (beta.fromchat.ru) points to development machine
  - Vite dev server requires 'unsafe-inline' to function
  - Production domain has strict CSP
7. **Security logging** - Already implemented:
  - All events are logged including security-related activity
  - Do NOT flag as missing
8. **100% Open Source** - This is a security strength:
  - Full transparency
  - Community review capability
  - No hidden backdoors

## Android App

**EXCLUDE from all audits** - Android app is not production-ready and out of scope.

## Infrastructure (Caddy)

The application runs behind Caddy reverse proxy with comprehensive security controls:

### Key Infrastructure Protections

- ✅ **HTTPS enforcement** - Automatic SSL/TLS with Caddy
- ✅ **HSTS** - Strict-Transport-Security with preload
- ✅ **CSP** - Content Security Policy (strict on production, 'unsafe-inline' for scripts on beta for Vite)
- ✅ **Rate limiting** - 500 events/min (production), 1000 events/min (beta)
- ✅ **X-Frame-Options: DENY** - Prevents clickjacking
- ✅ **X-Content-Type-Options: nosniff** - Prevents MIME sniffing
- ✅ **X-XSS-Protection: 1; mode=block** - XSS protection
- ✅ **Permissions-Policy** - Restricts geolocation, allows camera/mic for calls

**Important:** These protections are already in place at the infrastructure level. Don't flag missing security headers or rate limiting in the application code.

## Audit Process

1. **Read the Caddyfile first** to understand infrastructure protections
2. **Check backend code** for authentication, authorization, input validation
3. **Review frontend code** for XSS protections, crypto implementation
4. **Verify E2E encryption** implementation (NaCl for DMs, AES-GCM for calls)
5. **Test CORS configuration** in backend/app.py
6. **Review password policies** in backend/validation.py
7. **Check file upload handling** in backend/routes/messaging.py and profile.py

## Rating Guidelines

- **Infrastructure (Caddy):** Should be 9/10 or higher (excellent security headers)
- **Cryptography:** Should be 8-9/10 (uses industry-standard libraries)
- **Frontend Security:** Should be 7-8/10 (multi-layer XSS protection)
- **Backend API:** Focus on CORS, password policies, rate limiting

## Output Format

Provide a **clean, concise report** with:

1. **Executive Summary** - Overall rating and production readiness
2. **Security Status** - Critical issues (if any) and recommendations
3. **Security Strengths** - What's done well
4. **Component Ratings** - Table format for quick reference
5. **Design Decisions** - Clarify what's intentional vs vulnerable
6. **Threat Analysis** - Current realistic threats only
7. **Recommendations** - Prioritized with time estimates
8. **Conclusion** - Clear production readiness statement

**Keep it under 500 lines** - focus on actionable findings, not verbose explanations.

## Common False Positives to Avoid

❌ **DO NOT FLAG THESE AS ISSUES:**

- Public messages endpoint (intentional)
- Username enumeration (users list is public by design)
- Keys in localStorage (XSS is well-protected)
- Content-Type validation (Docker isolation prevents execution)
- CSRF protection (not applicable - no cookies)
- Beta CSP 'unsafe-inline' (required for Vite)
- Security logging (already implemented)
- Android app security (out of scope)

## Key Security Features to Verify

✅ **MUST CHECK:**

- CORS configuration in backend/app.py
- Password validation in backend/validation.py
- JWT token generation and validation
- Encryption implementation (NaCl, AES-GCM)
- File upload sanitization
- Authorization checks on sensitive endpoints
- Rate limiting configuration
- Security headers in Caddyfile

## Example Good Finding Format

```markdown
### Password Policy (HIGH PRIORITY - Non-blocking)
**Current:** 5 character minimum
**Recommended:** 12+ characters with complexity requirements
**Risk:** Brute force attacks (mitigated by rate limiting)
**Estimated Fix:** 4-6 hours
**Code Location:** backend/validation.py:11-16
```

## Notes from Developer

- Application is production-ready after CORS fix
- Focus on practical, actionable improvements
- Don't overthink things that are already well-protected
- Open source is a feature, not a concern
- Community can audit the code themselves