Bonnes pratiques de sécurité
Recommandations pour sécuriser votre intégration en production.
Gestion des secrets
- Stocker l'API Secret en coffre-fort : AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Azure Key Vault.
- Ne jamais committer dans Git, ne jamais embarquer dans une app mobile publique ou un SPA.
- Variables d'environnement uniquement, pas de fichier en clair.
- Rotation périodique recommandée (tous les 90 jours).
- Restriction d'accès : seuls les serveurs backend doivent avoir le secret.
Signature HMAC
- Toujours signer avec
timestamp + bodyexact (pas de re-encodage JSON entre signature et envoi). - Synchroniser l'horloge serveur via NTP — un décalage > 300 sec entraîne un rejet 401.
- Utiliser
hash_equals()(PHP) ou équivalent constant-time pour comparer les signatures. - Logger les signatures invalides côté votre handler pour détecter les tentatives d'intrusion.
Anti-replay
- Vérifier que
X-NekaPay-Timestampest dans une fenêtre de ±300 secondes. - Optionnel : maintenir un cache Redis des timestamps déjà vus pour rejeter les replays exacts.
- Idempotence côté votre commande : ne traiter qu'une fois par
transaction_id.
Réseau et TLS
- HTTPS uniquement (TLS 1.2 minimum, TLS 1.3 recommandé).
- HSTS activé sur votre domaine de webhook.
- Whitelist d'IPs Neka Paie côté firewall si possible.
- Vérifier le certificat de l'API Neka Paie côté votre client HTTP.
- Pas de proxy non maîtrisé entre vous et Neka Paie.
Stockage des MSISDN
- Chiffrer au repos les numéros de téléphone clients (AES-256).
- Masquer dans les logs :
+223******56au lieu du numéro complet. - Conservation limitée selon la juridiction (RGPD/équivalent).
- Droit d'oubli : prévoir une procédure de purge sur demande.
Monitoring et alerting
- Taux d'erreur 401 / 422 / 5xx : alerter si > 2 % sur 5 min.
- Latence p95 : alerter si > 1,5 sec.
- Webhooks rejetés côté votre handler : log + alerte.
- Réconciliation : revue manuelle si écart > 0,1 %.
- Tableau de bord : surveillance quotidienne des KPI.