Pages annexes, exemples et details techniques dans une mise en page plus lisible.
L'API Militant implémente plusieurs couches de sécurité pour protéger contre les attaques courantes.
X-Frame-Options: DENY - Protection contre le clickjackingX-XSS-Protection: 1; mode=block - Protection XSSX-Content-Type-Options: nosniff - Prévention du MIME sniffingReferrer-Policy: strict-origin-when-cross-originContent-Security-Policy - Politique de sécurité du contenuStrict-Transport-Security - HSTS (si HTTPS activé)Lorsqu'un compte a la 2FA activée, le processus d'authentification se déroule en deux étapes :
1. Étape 1 : L'utilisateur envoie son username et password. L'API renvoie une erreur 401 (ou un succès partiel) avec le flag two_factor_required: true.
2. Étape 2 : Le client doit demander le code TOTP à l'utilisateur et renvoyer la même requête de login en incluant le paramètre totp dans le JSON.
3. Codes de Récupération : L'API accepte également les codes de récupération (8-12 caractères) dans le paramètre totp. Un code de récupération utilisé est automatiquement invalidé.
Dans /api/.env :
API_REQUIRE_HTTPS=true
Dans /api/.env :
API_CORS_ORIGINS=https://app.example.com,https://mobile.example.com
Décommenter dans /api/.htaccess :
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Décommenter dans /api/.htaccess :
RewriteCond %{HTTPS} off
RewriteRule ^(.)$ https://%{HTTP_HOST}/$1 [R=301,L]
Dans /api/.env :
API_DEBUG=false
CREATE USER 'api_user'@'localhost' IDENTIFIED BY 'mot_de_passe_fort';
GRANT SELECT, INSERT, UPDATE, DELETE ON militant.* TO 'api_user'@'localhost';
FLUSH PRIVILEGES;
Dans /api/.env :
API_DB_USER=api_user
API_DB_PASS=mot_de_passe_fort
UFW (Ubuntu)
sudo ufw allow 443/tcp
sudo ufw enableFail2Ban pour l'API
sudo cp /path/to/fail2ban/filter.d/militant-api.conf /etc/fail2ban/filter.d/
sudo systemctl restart fail2ban
Logs de sécurité
tail -f /var/log/apache2/error.log | grep "API Security"Logs d'accès
tail -f /var/log/apache2/access.log | grep "/api/"
1. Stockage sécurisé des tokens - Ne jamais stocker en clair dans le code - Utiliser le keychain/keystore du système - Chiffrer si stockage en base de données locale
2. Gestion des tokens - Rafraîchir avant expiration - Révoquer lors de la déconnexion - Ne jamais partager entre utilisateurs
3. HTTPS uniquement - Toujours utiliser HTTPS en production - Vérifier les certificats SSL - Épingler les certificats si possible
4. Gestion des erreurs - Ne jamais afficher les tokens dans les logs - Ne pas exposer les détails techniques aux utilisateurs - Logger les erreurs côté serveur uniquement
5. Rate limiting côté client - Implémenter un cache local - Limiter les requêtes automatiques - Gérer les erreurs 429 avec backoff exponentiel
1. Surveillance - Monitorer les tentatives de login échouées - Alertes sur les patterns d'attaque - Vérifier régulièrement les tokens actifs
2. Mises à jour - Garder PHP à jour (8.2+) - Mettre à jour les dépendances régulièrement - Appliquer les patches de sécurité
3. Backups - Sauvegarder la base de données régulièrement - Tester les restaurations - Chiffrer les backups
4. Audits - Audit de sécurité régulier - Tests de pénétration - Revue du code
Si vous découvrez une vulnérabilité de sécurité :
1. NE PAS créer d'issue publique 2. Envoyer un email à : security@militant.example.com 3. Inclure : - Description détaillée - Steps pour reproduire - Impact potentiel - Suggestions de correction (optionnel)
Nous nous engageons à répondre sous 48h et à corriger les vulnérabilités critiques en priorité.
Avant de déployer en production :
L'API Militant respecte :