Sécurité
Comment nous protégeons vos données
Vos clés d'échange et vos données de compte sont sensibles. Voici exactement ce que nous faisons pour assurer leur sécurité : pas de vagues promesses.
AES-256
au repos
TLS 1.3
en transit
No Withdrawal
Portée de la clé API
HttpOnly
cookies de session
1. Chiffrement au repos
Cryptage de base de données
Toutes les données de compte, journaux de signaux, configurations d'alertes et paramètres utilisateur sont stockés dans PostgreSQL sur une infrastructure qui applique le chiffrement complet du disque au repos. Les sauvegardes de base de données sont chiffrées séparément avant d'être écrites dans le stockage.
Chiffrement par clé API
Les clés et secrets Exchange API ne sont jamais stockés en texte brut. Chaque clé est chiffrée avec AES-256-GCM à l'aide de clés de chiffrement dérivées par utilisateur. La clé de chiffrement elle-même n'est jamais stockée avec le texte chiffré.
Portée du décryptage
Le déchiffrement de la clé API se produit uniquement dans le cadre du processus d'exécution de transaction isolé, uniquement lorsqu'un ordre de robot doit être soumis et uniquement pour la clé d'échange spécifique utilisée. Les clés déchiffrées sont conservées en mémoire uniquement pendant la durée de la demande.
2. Chiffrement en transit
TLS1.3
Toutes les connexions entre votre navigateur et nos serveurs utilisent TLS 1.3. Les anciennes versions de TLS (1.0, 1.1) et les suites de chiffrement faibles sont désactivées. HTTPS est appliqué avec les en-têtes HTTP Strict Transport Security (HSTS).
Connexions API
Toutes les connexions sortantes vers les échanges et les fournisseurs de données externes utilisent TLS avec épinglage de certificat lorsqu'il est pris en charge. Nous n’envoyons aucune requête HTTP en texte clair à un fournisseur de données.
3. Sécurité des clés API
Aucune autorisation de retrait
Nous imposons que les clés API connectées ne doivent pas inclure d'autorisations de retrait. Lors de la configuration de la clé, nous vous avertissons si la clé semble avoir un accès au retrait et vous recommandons de la régénérer avec une portée de trading uniquement.
Isolement de la portée
Chaque connexion de clé API est limitée à un seul échange et à un seul utilisateur. Il n’y a pas de mutualisation ni de partage de clés entre utilisateurs ou robots. Une clé de la bourse A ne peut pas être utilisée pour passer des ordres sur la bourse B.
Rotation des clés
You can revoke and replace your API keys from Settings to Exchanges at any time. Les anciennes clés sont immédiatement marquées comme inactives et ne peuvent pas être utilisées pour de nouvelles commandes.
4. Authentification et sessions
Cookies de session JWT
Les jetons d'authentification sont stockés sous forme de cookies HttpOnly, Secure, SameSite=Strict. Ils ne sont pas accessibles à JavaScript et ne peuvent pas être volés via XSS. Les jetons expirent après 24 heures d'inactivité ou 30 jours avec Remember me.
Sécurité OAuth
Les flux OAuth (Google, GitHub) utilisent PKCE et les paramètres d'état pour empêcher les attaques CSRF et d'interception de code d'autorisation. Nous recevons uniquement les étendues de profil minimales requises pour la création de compte.
Hachage de mot de passe
Les mots de passe sont hachés à l'aide de bcrypt avec un facteur de travail de 12 avant stockage. Nous ne stockons ni ne transmettons jamais de mots de passe en clair.
5. Infrastructures
Isolation du réseau
La base de données et les services de travail ne sont pas exposés à l'Internet public. Toutes les communications de service internes s'effectuent sur un réseau privé. Le serveur API est le seul point d'entrée public.
Sécurité des dépendances
Nous effectuons des analyses automatisées des vulnérabilités des dépendances sur chaque déploiement. Critical-severity CVEs in dependencies are patched within 48 hours of disclosure.
Gestion secrète
Les secrets de production (informations d'identification de la base de données, clés de chiffrement, jetons du fournisseur API) sont injectés au moment de l'exécution via des variables d'environnement provenant d'un gestionnaire de secrets. Les secrets ne sont jamais soumis au contrôle de source.
6. Divulgation responsable
Signaler une vulnérabilité
Si vous découvrez une vulnérabilité de sécurité dans CryptoSignal Pro, veuillez envoyer un e-mail à security@cryptosignalpro.com avec plus de détails. Ne divulguez pas publiquement le problème avant que nous ayons eu l'occasion d'enquêter et de le corriger.
Que faut-il inclure
Veuillez inclure : une description de la vulnérabilité, les étapes pour la reproduire, l'impact potentiel et tout code de preuve de concept. Plus vous fournissez de détails, plus vite nous pouvons évaluer et remédier au problème.
Délai de réponse
Nous accuserons réception de votre rapport dans les 48 heures, fournirons une première évaluation dans les 5 jours ouvrables et vous tiendrons informé des progrès des mesures correctives. Nous créditons les chercheurs qui signalent des vulnérabilités valides (avec leur permission).
Vous avez trouvé une vulnérabilité ?
Envoyez un e-mail à notre équipe de sécurité – nous répondons dans les 48 heures.
Des questions de sécurité générales ?
Contacter l'assistance