Security Policy

MagicTradeBot is a portable Rust binary that runs on infrastructure you control — your VPS, your bare metal, your local machine. This architectural choice has the most important security implication of all:

Our security responsibility covers the account management layer, license verification, payment processing, and the website. Your security responsibility covers the server running the binary itself. This document explains both halves.

• All HTTP traffic to magictradebot.com and subdomains is served over TLS 1.2+ with modern cipher suites
• HSTS preload list inclusion ensures browsers refuse insecure connections to our domain
• Internal service-to-service communication uses mTLS within our private network
• License verification API calls from your binary use HTTPS with certificate pinning
• Sensitive emails (account recovery, security alerts) include DKIM/DMARC/SPF authentication headers

• Account passwords are stored as Argon2id hashes — never plaintext, never reversible
• Sensitive database fields use AES-256-GCM encryption with keys managed through HSM
• Database backups are encrypted at rest with separate keys from the production cluster
• Payment data is never stored on our infrastructure — handled exclusively by NowPayments
• Audit logs are written to append-only storage with 7-year retention

• Multi-factor authentication. 2FA available for all user accounts and mandatory for staff administrative access. TOTP-based via standard authenticator apps (no SMS).
• Role-based permissions. Staff access is granted on a least-privilege basis with quarterly review and immediate revocation on role change or departure.
• Session management. JWT tokens with short TTL plus refresh-token rotation. Session invalidation on password change or detected suspicious activity.
• Audit logging. All administrative actions, payment events, and license operations are logged to an append-only system with 7-year retention.

• Production servers run on hardened Linux baselines with daily kernel patching
• All inbound traffic flows through a WAF with rate limiting, IP reputation filtering, and bot mitigation
• Database instances are isolated in private subnets with no direct internet exposure
• Continuous vulnerability scanning of dependencies and OS packages via Dependabot & Trivy
• Production deployments require code review approval and pass automated security tests
• Secrets management via Vault — no credentials in source code, environment files, or images

Our security operations posture includes:

• 24/7 automated monitoring of authentication anomalies, API abuse patterns, and infrastructure health
• Sentry-based error tracking for early detection of code-level security issues
• Behavioral analytics on user accounts to detect compromise indicators
• Quarterly third-party penetration testing with public summary disclosure
• Bug bounty program with researcher hall of fame and confidential disclosure path
• Real-time alerting on privileged action anomalies (mass deletions, bulk exports, role changes)

• OS hardening. Keep the operating system patched. Disable unused services. Use SSH keys (not passwords) for remote access.
• Firewall. Allow only the ports the bot needs. Restrict SSH to known IPs where possible.
• API key scope. Configure exchange API keys with the minimum permissions required — typically trade + read, never withdrawal.
• IP whitelisting. Where exchanges support it, whitelist your bot's outbound IP on the exchange side.
• YAML file permissions. Set chmod 600 on configuration files containing API keys so they aren't world-readable.
• Backup the config. Maintain encrypted backups of your bot configuration in case the server is lost.

If you discover a security vulnerability in MagicTradeBot, please report it confidentially via the Incident Reporting process rather than public channels.

We commit to a 90-day coordinated disclosure window, public credit (if you wish), and inclusion in our security researcher hall of fame for valid reports.