Security Analysis Report

[eovidiu]

Based on my analysis of the Quotio codebase, here are the main security concerns when importing and building this project in Xcode:
🔴 Critical Issues
App Sandbox Disabled - The app has sandboxing disabled (ENABLE_APP_SANDBOX = NO) with full network client/server access. This allows the app to:

• Access any network resource without restriction
• Execute arbitrary processes via CLIProxyManager
• Read/write files throughout the system
  Auto-Update Security Risk - Uses Sparkle for updates with a hardcoded Ed25519 key. While properly implemented, auto-updating bypasses App Store security controls.

🟡 Medium Concerns

• Third-Party Binary Downloads - The app automatically downloads CLIProxyAPI binary on first launch from GitHub releases. This could execute malicious code if repository is compromised.
• Extensive Network Access - Connects to multiple external APIs (OpenAI, Anthropic, Google Cloud, etc.) storing OAuth tokens and API keys locally.
• Local Proxy Server - Runs a local HTTP proxy on localhost that routes all AI API traffic, potentially exposing sensitive data.

🟢 Good Practices

• No Hardcoded Secrets - All API keys, tokens, and credentials are properly stored in user configuration files, not hardcoded.
• Secure Package Management - Uses Swift Package Manager with verified Sparkle dependency (up to version 2.0.0+).
• Proper Build Configuration - Separates debug/release builds with local configuration overrides that are gitignored.

[nguyenphutrong]

Thanks for the note about No Hardcoded Secrets. I'd like to clarify this point with additional context.

Quotio does not hardcode any API keys, tokens, or credentials in the source code. However, credential storage behavior depends on the authentication flow, which is split between Quotio and the external CLIProxyAPI component.

The authentication architecture is documented here:
https://raw.githubusercontent.com/nguyenphutrong/quotio/refs/heads/feat/universal-provider-architecture/docs/provider-authentication-architecture.md

Please note that this design is implemented in PR #140, which is not merged yet. The documentation reflects the intended and upcoming architecture, not the current main branch behavior.

In short:
• OAuth-based providers (Gemini, Claude, Codex, Qwen, iFlow, Antigravity, Copilot)
OAuth flows are handled by CLIProxyAPI. Tokens are created and stored by CLIProxyAPI in ~/.cli-proxy-api/*.json. Quotio does not generate, embed, or hardcode these tokens.
• API-key-based providers using the UniversalProvider architecture (PR #140)
API keys are stored securely in macOS Keychain via KeychainService, not in code or plaintext config files.

Because OAuth token storage is owned by CLIProxyAPI, Quotio cannot currently change how those tokens are persisted without modifying that external component. This is a limitation of the proxy architecture, not a hardcoding issue.