Memorex implements multiple security layers to protect user data and prevent abuse. This document outlines the security measures in place and known considerations.

All inputs are validated using Zod schemas with additional security checks:

// Query sanitization - prevents FTS5 injection
sanitizeFtsQuery(query: string): string
// - Escapes: " * ( ) ^ - ~
// - Removes boolean operators: AND OR NOT NEAR
// - Limits length to 200 characters

// Path validation - prevents directory traversal
isValidProjectPath(path: string): boolean
// - Rejects null bytes
// - Validates path depth
// - Restricts to home directory

// Tag validation
validateTags(tags: string[]): boolean
// - Max 20 tags
// - Max 50 chars per tag
// - Rejects control characters

Session operations use atomic file locking:

// mkdir-based locking (atomic on most filesystems)
acquireLock(lockDir: string): boolean

This ensures concurrent access to session counters is safe.

• Local data protection (file permissions)
• Input validation and sanitization
• Resource exhaustion prevention
• Concurrent access safety

• Network security (local-only application)
• Encryption at rest (relies on OS permissions)
• Multi-user isolation (single-user design)

1. Lock Persistence: If the process dies while holding a lock, it may persist until manual cleanup
2. Error Silencing: Some permission errors are silently caught to ensure functionality
3. No Encryption: Data is stored in plaintext SQLite (protected by OS permissions)

If you discover a security vulnerability, please:

1. DO NOT open a public issue
2. Email the maintainer directly
3. Allow time for response before public disclosure

• Input validation on all entry points
• SQL injection prevention (parameterized queries)
• FTS5 injection prevention (query sanitization)
• Path traversal prevention
• Resource limits enforced
• File permissions restricted
• Race condition protection
• Error handling without information leakage