Currently supported versions with security updates:
| Version | Supported |
|---|---|
| 1.0.x | β |
| < 1.0 | β |
We take security seriously. If you discover a security vulnerability, please follow these steps:
Please do not disclose security vulnerabilities publicly until they have been addressed.
Send an email to: security@example.com (replace with actual email)
Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Acknowledgment: Within 48 hours
- Initial Assessment: Within 7 days
- Status Update: Every 7 days
- Fix Timeline: Depends on severity
- Critical: 7-14 days
- High: 14-30 days
- Medium: 30-60 days
- Low: 60-90 days
- β JWT with access & refresh tokens
- β Token blacklisting
- β bcrypt password hashing (12 rounds)
- β Two-Factor Authentication (TOTP)
- β Email verification
- β Password reset with expiration
- β Rate limiting on all endpoints
- β CORS configuration
- β Input validation & sanitization
- β SQL injection prevention (ORM)
- β XSS protection
- β CSRF protection
- β Encrypted 2FA secrets
- β Secure password storage
- β Environment-based secrets
- β No hardcoded credentials
- β Sensitive data redaction in logs
- β 2FA required
- β Time delays (10-60 minutes)
- β Manual approval for large amounts
- β Address validation
- β Blacklist checking
- β Row-level locking
- β MIME type verification
- β File size limits
- β Extension validation
- β Filename sanitization
- β Image dimension checks
- β EXIF metadata validation
- β Docker containerization
- β Network isolation
- β Read-only containers
- β Non-root users
- β Resource limits
Latest security audit: November 2025
Overall Score: 9/10
- Strong authentication with JWT + 2FA
- Comprehensive input validation
- SQL injection prevention
- Withdrawal security measures
- Audit logging
- Implement HSM/KMS for key management (in progress)
- Add security headers (CSP, HSTS)
- Implement anomaly detection
- Add DDoS protection
- Uses weak default secrets (auto-generated on install)
- Debug mode enabled
- Verbose error messages
- Email verification may be disabled
β Production Mode (recommended):
- Strong secrets required
- Debug mode disabled
- Generic error messages
- Full security measures enabled
- Set
FLASK_ENV=production - Set
DEBUG=False - Generate strong
SECRET_KEY(32+ chars) - Generate strong
JWT_SECRET_KEY(32+ chars) - Generate strong
ENCRYPTION_KEY(32+ chars) - Configure real SMTP settings
- Set up Binance API keys
- Configure CORS origins
- Enable SSL/TLS
- Set up Redis persistence
- Configure database backups
- Set up monitoring/alerting
- Review and update rate limits
- Enable security headers
-
Never commit secrets
- Use
.envfiles (git-ignored) - Use environment variables
- Use secret management services
- Use
-
Validate all input
- Backend validation required
- Frontend validation for UX
- Sanitize before database operations
-
Use parameterized queries
- Always use ORM methods
- Never concatenate SQL strings
- Use prepared statements
-
Handle errors securely
- Don't expose stack traces
- Log errors securely
- Return generic error messages
-
Keep dependencies updated
- Regularly run
npm audit - Regularly run
pip-audit - Monitor for security advisories
- Regularly run
-
Use strong passwords
- Minimum 12 characters
- Mix of letters, numbers, symbols
- Don't reuse passwords
-
Enable 2FA
- Required for withdrawals
- Use authenticator app (Google Authenticator, Authy)
- Save backup codes securely
-
Verify email addresses
- Double-check deposit addresses
- Use address whitelisting
- Start with small test amounts
-
Monitor account activity
- Check login history
- Review transaction history
- Report suspicious activity
Security Team: security@example.com
PGP Key: [Optional - add PGP public key]
We thank the following researchers for responsibly disclosing security issues:
- [Name] - [Vulnerability] - [Date]
Last Updated: November 2025