> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arkatech.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# Sécurité de votre code

> La sécurité des applications est un processus continu, de la conception à la mise en production, visant à protéger les données et les fonctionnalités contre les menaces externes et internes.

# OWASP Top 10 (Open Web Application Security Project)

L'OWASP Top 10 est un document de référence qui identifie les **dix menaces de sécurité les plus critiques** pour les applications web. C'est un point de départ essentiel pour toute stratégie de sécurité.

| Vulnérabilité                                        | Description                                                                                                                           | Exemple d'Attaque                                                                                        | Prévention (Bonne Pratique)                                                                                                                                      |
| :--------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Injection**                                     | Envoyer des données non fiables à un interpréteur (SQL, NoSQL, OS Command).                                                           | **SQL Injection :** `SELECT * FROM users WHERE user='admin' OR 1=1--'`                                   | **Utiliser des requêtes préparées** (Prepared Statements) ou des ORM. Valider et échapper toutes les entrées utilisateur.                                        |
| **2. Liens Brisés & Contrôle d'Accès Déficient**     | L'application ne restreint pas correctement l'accès aux fonctions ou données sensibles.                                               | Un utilisateur normal accède à la page d'administration via une URL directe.                             | Implémenter des **contrôles d'accès côté serveur** à chaque point d'accès. Ne jamais faire confiance au client.                                                  |
| **3. Stockage de Données Sensibles**                 | Les données sensibles (mots de passe, numéros de carte) ne sont pas correctement protégées.                                           | Mots de passe stockés en clair ou hachés faiblement.                                                     | **Chiffrer toutes les données sensibles au repos et en transit.** Utiliser des fonctions de hachage fortes (bcrypt, Argon2) pour les mots de passe.              |
| **4. Entités Externes XML (XXE)**                    | Un parseur XML vulnérable traite des références à des entités externes non fiables.                                                   | Un attaquant lit des fichiers système ou exécute du code à distance via XML.                             | Désactiver le traitement des entités externes dans les parseurs XML.                                                                                             |
| **5. Erreur de Configuration Sécurisée**             | Configuration par défaut non sécurisée, fichiers inutilisés, messages d'erreur détaillés.                                             | Un attaquant trouve des fichiers de sauvegarde ou des répertoires d'administration non protégés.         | Appliquer une **stratégie de *Hardening*** (durcissement) : désactiver les fonctionnalités inutiles, supprimer les exemples, restreindre les accès aux fichiers. |
| **6. Cross-Site Scripting (XSS)**                    | Injection de scripts côté client (JavaScript) malveillants dans une page web vue par d'autres utilisateurs.                           | Un attaquant injecte un script qui vole les cookies de session.                                          | **Échapper toutes les données affichées** côté client. Utiliser des frameworks qui protègent nativement contre le XSS (React, Vue).                              |
| **7. Désérialisation Dangereuse**                    | Désérialisation d'objets non fiables, pouvant entraîner l'exécution de code à distance.                                               | Un attaquant injecte un objet malveillant qui exécute une commande système.                              | Éviter la désérialisation de sources non fiables. Utiliser des formats de données sécurisés (JSON simple).                                                       |
| **8. Composants Vulnérables**                        | Utilisation de bibliothèques, frameworks ou autres composants avec des vulnérabilités connues.                                        | Une bibliothèque tierce avec une faille de sécurité permet une exécution de code à distance.             | Mettre à jour régulièrement les dépendances. Utiliser des outils d'analyse de vulnérabilités (OWASP Dependency-Check).                                           |
| **9. Log & Monitoring Insuffisants**                 | Absence de journaux d'événements (logs) ou de supervision adéquate des attaques.                                                      | Une attaque réussie n'est pas détectée avant des mois.                                                   | Implémenter une **journalisation centralisée** et des systèmes d'alerte pour les activités suspectes (tentatives de connexion échouées, erreurs API).            |
| **10. Falsification de Requête Côté Serveur (SSRF)** | L'application ne valide pas l'URL fournie par l'utilisateur et effectue une requête vers une ressource interne ou externe inattendue. | Un attaquant force l'application à accéder à des serveurs internes ou à scanner des ports sur le réseau. | Valider toutes les URLs fournies par l'utilisateur. Utiliser une liste blanche d'hôtes autorisés.                                                                |

# Gestion des Secrets

Les "secrets" sont des informations sensibles (clés API, identifiants de base de données, certificats) qui ne doivent jamais être exposées publiquement ou stockées de manière non sécurisée.

**<u>Bonnes Pratiques de Gestion des Secrets</u>**

* **Ne Jamais Commiter de Secrets :**
  * **À Faire :** Utiliser des variables d'environnement (`process.env.DB_PASSWORD`), des fichiers de configuration ignorés par Git (`.env` avec `.gitignore`).
  * **À Éviter :** Mettre des identifiants et clés API directement dans le code source ou dans les fichiers de configuration sous contrôle de version.
* **Systèmes de Gestion de Secrets :**
  * Pour les environnements de production, utiliser des solutions dédiées comme **HashiCorp Vault**, **AWS Secrets Manager**, **Azure Key Vault**, ou **Google Secret Manager**. Ces systèmes injectent les secrets de manière sécurisée au moment du déploiement ou de l'exécution.
* **Rotation des Secrets :** Modifier régulièrement les clés et mots de passe pour minimiser les risques en cas de fuite.

**Exemple de Code (Utilisation de Variables d'Environnement)**

```typescript theme={null}
// Au lieu de: const DB_PASSWORD = "MySuperSecretPassword";

// Utiliser les variables d'environnement (Node.js)
const DB_PASSWORD = process.env.DB_PASSWORD; 

if (!DB_PASSWORD) {
  console.error("Erreur: Le mot de passe de la base de données n'est pas configuré.");
  process.exit(1); // Arrêter l'application
}

// Utilisation sécurisée du mot de passe
connectToDatabase(DB_PASSWORD);
```

# Tests Automatisés (Sécurité Incluse)

Les tests automatisés ne sont pas seulement pour la fonctionnalité, ils sont une première ligne de défense contre les régressions de sécurité et les vulnérabilités introduites.

**<u>Types de Tests Clés</u>**

| Type de Test                                     | Description                                                                                                  | Impact Sécurité                                                                                                                                 | Outils Courants                                                               |
| :----------------------------------------------- | :----------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------- |
| **Unit Tests**                                   | Vérifient le comportement de petites unités de code (fonctions, méthodes).                                   | Détectent les erreurs logiques qui pourraient mener à des vulnérabilités (ex: vérification d'autorisation incorrecte dans une fonction).        | Jest, Vitest (JS), JUnit (Java), Pytest (Python)                              |
| **Integration Tests**                            | Vérifient l'interaction entre plusieurs unités de code (ex: service et base de données, deux microservices). | S'assurent que les contrôles d'accès et de validation fonctionnent correctement à travers les couches de l'application.                         | Similaires aux tests unitaires, mais avec des mocks et stubs moins agressifs. |
| **End-to-End (E2E) Tests**                       | Simulent le parcours d'un utilisateur réel à travers l'application entière.                                  | Vérifient que les flux d'authentification/autorisation complexes fonctionnent comme prévu de bout en bout.                                      | Cypress, Playwright (Web), Detox (React Native), Appium (Mobile)              |
| **Tests de Sécurité (DDoS, Pentest, SAST/DAST)** | Tests spécialisés pour identifier des vulnérabilités de sécurité.                                            | **SAST (Static Analysis Security Testing) :** Analyse le code source pour trouver des vulnérabilités connues (ex: injection SQL).               | SonarQube, Snyk, Checkmarx                                                    |
|                                                  |                                                                                                              | **DAST (Dynamic Analysis Security Testing) :** Attaque l'application en cours d'exécution pour trouver des vulnérabilités (ex: XSS, injection). | OWASP ZAP, Burp Suite (manuels/automatisés)                                   |
|                                                  |                                                                                                              | **Tests de pénétration (Pentest) :** Menés par des experts pour simuler des attaques réelles.                                                   | Outils manuels, expertise humaine.                                            |

**<u>Bonne Pratique (DevSecOps)</u>**

Intégrer les outils de sécurité (SAST, DAST légers) directement dans le pipeline de CI/CD (intégration continue/déploiement continu) pour détecter les vulnérabilités le plus tôt possible dans le cycle de développement.