Please do NOT report security vulnerabilities through public GitHub issues.

Instead, use one of the following methods:

1. GitHub Security Advisories (preferred): Report a vulnerability
2. Email: Create a private security advisory on the repository

• Type of vulnerability (e.g., XSS, injection, authentication bypass)
• Location of the affected source code (file path, line number)
• Step-by-step instructions to reproduce
• Impact assessment
• Suggested fix (if any)

• All user inputs validated via Pydantic models with strict type checking
• Prompt injection defense via InputGuardrail (pattern matching + heuristic analysis)
• Path traversal prevention on skill/file operations
• Regex-based Notion page ID validation

• CORS configuration with explicit origin allowlist
• Request size limits on all endpoints
• Rate limiting middleware (configurable via RATE_LIMIT_RPM)
• Structured error responses (no stack trace leakage in production)

• Token validation before API calls
• Rate limiter with exponential backoff
• Automatic retry with circuit breaker pattern
• Token never logged or stored beyond session

• Connection timeout (10s) for unauthenticated sessions
• Per-connection message rate limiting
• Graceful disconnection on invalid state

• Automated dependency updates via Dependabot
• pip-audit in CI pipeline for known vulnerabilities
• Minimal dependency footprint

NotionForge is designed for self-hosted deployment. Operators should:

1. Use HTTPS in production (reverse proxy with TLS termination)
2. Restrict network access — do not expose the API to the public internet without authentication
3. Rotate Notion tokens periodically
4. Set environment variables securely (never commit .env files)
5. Enable rate limiting via RATE_LIMIT_RPM environment variable
6. Monitor logs for unusual activity patterns
7. Keep dependencies updated — run uv lock --upgrade regularly

• No built-in authentication: This is a self-hosted tool. Deploy behind a VPN or reverse proxy with auth (e.g., Cloudflare Access, OAuth2 Proxy, Authelia).
• In-memory state (single worker only): Task store, OAuth state, session settings, rate-limit counters, and metrics are all kept in-memory per process. Run with a single worker (uvicorn ... --workers 1). Multi-worker / multi-instance deployment is not supported — counters and state are not shared across processes. (A shared backend such as Redis is not yet implemented; it is a future roadmap item, not a current option.)
• No horizontal scaling: For higher throughput, scale vertically or place a queue/proxy in front; do not run multiple app workers expecting shared state.