# Web Sentinel – Cartographie OWASP Top 10 (07/11/2025)

## Méthodologie & périmètre
- **Sources analysées :** documentation (`README.md`, `STRUCTURE.md`), code applicatif (ex. `web_sentinel/checks/*`, `web_sentinel/auth/*`, `web_sentinel/gui/*`, `web_sentinel/payment/*`), scripts de packaging (`build_executables.ps1`) et dépendances (`requirements*.txt`).
- **Approche :** revue statique des contrôles existants, identification des protections alignées sur l’OWASP Top 10 (édition 2021) et cartographie des écarts résiduels.
- **Notation rapide :** `✅ Solide`, `🟡 Partiel`, `⚠️ Lacunaire`. Les recommandations se concentrent sur les mesures techniques réalisables dans le dépôt.

## Synthèse exécutive

| OWASP Top 10 (2021) | Couverture Web Sentinel | Modules / Artefacts clés | État global |
| --- | --- | --- | --- |
| A01 – Broken Access Control | Gestion locale des sessions, licence runtime (`web_sentinel/auth/auth_manager.py`, `web_sentinel/gui/sections/license.py`). | ✅ Contrôles présents mais limités à la GUI/CLI, pas de RBAC serveur central. | 🟡 |
| A02 – Cryptographic Failures | Vérification TLS (`web_sentinel/checks/tls.py`), dépendance `cryptography>=41`. Stockage local non chiffré (`auth_manager`). | Mix de forces (scanner TLS) et faiblesses (secrets en clair). | 🟡 |
| A03 – Injection | Module dédié (`web_sentinel/checks/injection.py`) + moteur SAST multi-langages (`web_sentinel/checks/source_code/scanner.py`). | Très bonne couverture technique. | ✅ |
| A04 – Insecure Design | Architecture modulaire, mais peu de preuves de threat modeling / exigences de sécurité explicites. | ⚠️ Manque de documentation et de garde-fous design. | ⚠️ |
| A05 – Security Misconfiguration | Multiples profils Docker/docker-compose, vérification TLS/headers. Pas de hardening unifié ni de baseline automatisée. | 🟡 |
| A06 – Vulnerable & Outdated Components | Dépendances récentes mais seulement contraintes par un `>=`. Pas de SCA ni d’audit automatique. | ⚠️ |
| A07 – Identification & Authentication Failures | Auth locale avec journalisation tentatives (`auth_manager`), mais pas de MFA, stockage des tokens en clair, pas de verrouillage. | 🟡 |
| A08 – Software & Data Integrity Failures | Vérification Stripe webhook (`web_sentinel/payment/stripe_service.py:200-230`), mais build PyInstaller non signé et distribution hors chaîne sécurisée. | 🟡 |
| A09 – Security Logging & Monitoring Failures | `web_sentinel/logging_config.py` uniformise les logs, mais absence d’alerting, corrélation et conservation structurée. | 🟡 |
| A10 – SSRF | Le scanner n’inclut pas de détection spécifique SSRF (au-delà des checks génériques). Pas de garde-fou quand l’outil effectue des requêtes basées sur saisies utilisateur. | ⚠️ |

## Détails par catégorie

### A01 – Broken Access Control
**Points forts**
- Stockage des utilisateurs/sessions locales dans une base SQLite avec journalisation des tentatives (`web_sentinel/auth/auth_manager.py:15-120`).
- Limitation dynamique des features via la couche licence/abonnement (`web_sentinel/gui/sections/license.py:16-120`), ce qui évite l’accès à des fonctions PRO sans droit.

**Lacunes / risques**
- Pas de politique d’expiration granulaire ni de verrouillage après X échecs : `_log_login_attempt` enregistre mais ne bloque pas (same file, lignes 70-110).
- Les contrôles d’accès sont surtout côté GUI/CLI. Les endpoints API (ex. `web_sentinel/payment/api_routes.py`) ne mentionnent pas de décorateurs d’authentification ni de scopes granulaires.
- Les rôles/tier sont manipulés côté client via la licence ; l’absence de contrôles server-side rend possible le contournement en modifiant les fichiers locaux.

**Recommandations**
1. Centraliser les décisions d’accès (API REST sécurisée) et exiger un jeton signé côté scanner.
2. Ajouter un mécanisme de verrouillage progressif (ex. 5 tentatives échouées → temporisation) et loguer l’IP + user agent.
3. Chiffrer les licences / sessions stockées localement et vérifier leur intégrité lors de l’import.

### A02 – Cryptographic Failures
**Points forts**
- Vérifications TLS étendues : dates de certificats, SAN, protocoles obsolètes, downgrade HTTP (`web_sentinel/checks/tls.py:1-170`).
- Utilisation de `cryptography>=41` et `ssl` natif pour l’écosystème licence.

**Lacunes / risques**
- Les jetons d’accès/refresh sont sérialisés en clair dans `~/.web-sentinel/auth-config.json` (`web_sentinel/auth/auth_manager.py:90-135`).
- `StripeConfig` garde des valeurs par défaut (price IDs, URLs) directement dans le code (`web_sentinel/payment/config.py:15-80`), ce qui accroît l’exposition en cas de compromission du dépôt.
- Absence d’enveloppe de chiffrement pour les historiques (`HistoryStore` écrit sur disque sans protection).

**Recommandations**
1. Chiffrer les secrets au repos (Fernet, DPAPI, Apple Keychain suivant l’OS).
2. Déplacer les identifiants Stripe “LIVE” vers un coffre (seulement les noms symboliques restent dans Git).
3. Étendre le scanner TLS pour vérifier HSTS, OCSP Stapling et politiques de certificats courts.

### A03 – Injection
**Points forts**
- Module actif de fuzzing SQL/XSS et découverte OpenAPI (`web_sentinel/checks/injection.py:1-180`).
- Moteur SAST multi-langages couvrant 24 langages / 81 extensions (`web_sentinel/checks/source_code/scanner.py:1-160`), avec exclusions intelligentes.

**Axes d’amélioration**
- Les payloads intégrés restent limités (principalement SQL et XSS). Pas de templates pour NoSQL, LDAP ou GraphQL.
- Le moteur d’injection ne journalise pas finement les retours (pas de corrélation à un ID de requête pour faciliter les reproductions).

**Recommandations**
1. Enrichir les charges utiles (NoSQL, XXE, template injection) et permettre leur personnalisation par profil.
2. Ajouter un mode “evidence bundle” (requête brute + réponse tronquée) pour investiguer les faux positifs.

### A04 – Insecure Design
**Constats**
- L’architecture modulaire est claire (`web_sentinel/gui/sections/*`, `web_sentinel/checks/*`), mais il n’existe pas de documents de threat modeling ni de tests de sécurité automatisés attachés aux user stories.
- Plusieurs fonctionnalités sensibles (paiement, licence) sont implémentées directement dans la GUI sans pattern “service boundary” bien défini.

**Recommandations**
1. Documenter les flux critiques (auth, paiement, mise à jour licence) sous forme de diagrammes + STRIDE/LINDDUN.
2. Ajouter des contrôles de cohérence (ex. signatures des profils de tiers, double validation des actions destructrices).
3. Introduire des tests d’abus (unitaires ou BDD) pour les scénarios négatifs.

### A05 – Security Misconfiguration
**Points forts**
- Scanner TLS + headers (module `web_sentinel/checks/headers.py`) inspiré des bonnes pratiques OWASP ASVS.
- Multiples fichiers de déploiement (Docker, traefik, nginx) qui détaillent les configurations attendues.

**Lacunes**
- Pas de baseline “secure-by-default” centralisée : chaque utilisateur doit deviner quel `docker-compose.*.yml` utiliser.
- Les scripts (`build_executables.ps1`) ne durcissent pas l’environnement (ex. pas de `--noconfirm` vs. `pip install`, pas de sandbox).
- Certaines valeurs sont codées en dur (ports par défaut dans `web_sentinel/checks/tls.py` ou `config/defaults`) sans validation.

**Recommandations**
1. Fournir un manifeste unique (ex. `security-hardening.md`) résumant les variables obligatoires et les valeurs sûres.
2. Ajouter des checks CI (Yamllint + kube-score) pour les manifests.
3. Ajouter une commande `web-sentinel doctor` qui valide la configuration locale (permissions, fichiers sensibles).

### A06 – Vulnerable & Outdated Components
**Constats**
- Les dépendances Python sont fixées uniquement avec une contrainte minimale (`requirements.txt` et `requirements-api.txt` utilisent `>=`). Aucun verrouillage par hash (`pip-tools`/`poetry.lock`) ni SCA.
- Le dépôt contient des bibliothèques packagées (ex. `integrations/vscode/out/extension.js`) sans procédure d’audit.

**Recommandations**
1. Mettre en place une résolution reproductible (`pip-compile` ou `uv pip sync`) et scanner régulièrement via `pip-audit`/`safety`.
2. Ajouter un job CI “Dependency Review” (GitHub) + une page `docs/DEPENDENCY_POLICY.md`.
3. Surveiller les runtimes embarqués (PyInstaller) et publier les hashes des binaires.

### A07 – Identification & Authentication Failures
**Points forts**
- AuthManager journalise chaque tentative et sauvegarde les sessions avec métadonnées appareil (`web_sentinel/auth/auth_manager.py:60-130`).
- GUI moderne affiche l’état licence/tier et met à jour les permissions (`web_sentinel/gui/sections/license.py:50-140`).

**Faiblesses**
- Pas de MFA, ni même de challenge secondaire pour les opérations sensibles (ex. génération de clés, export rapports).
- Les sessions persistent jusqu’à suppression manuelle du fichier JSON : aucune expiration configurable.
- L’API de paiement ne vérifie pas l’auth utilisateur avant d’exposer certaines routes (ex. `web_sentinel/payment/api_routes.py`).

**Recommandations**
1. Ajouter un second facteur optionnel (TOTP ou clé FIDO2) côté AuthManager.
2. Implémenter des refresh tokens à durée courte + rotation systématique.
3. Protéger les routes API par OAuth2 client_credentials ou JWT signés.

### A08 – Software & Data Integrity Failures
**Points forts**
- Vérification de la signature Stripe webhook (`web_sentinel/payment/stripe_service.py:200-230`).
- Les licences peuvent être régénérées à partir de tiers connus (`web_sentinel/license/runtime_bridge.py`).

**Gaps**
- Les exécutables PyInstaller distribués via `dist/*.exe` ne sont ni signés ni publiés avec checksum (voir `build_executables.ps1`).
- Aucun mécanisme ne garantit l’intégrité des thèmes, scripts ou profils tiers téléchargés par l’utilisateur.
- `HistoryStore` et autres données locales ne sont pas scellés (risque de tampering).

**Recommandations**
1. Ajouter une étape de signature (Authenticode sur Windows) + génération automatique des SHA256 dans `dist/`.
2. Mettre en place une vérification de checksum pour les assets/tier profiles avant import.
3. Stocker les historiques dans une base chiffrée + HMAC pour détecter les modifications.

### A09 – Security Logging & Monitoring Failures
**Points forts**
- `web_sentinel/logging_config.py` centralise la configuration logging avec sortie console + fichier dans `~/.web-sentinel/logs`.
- Les modules critiques (ex. Stripe) loguent les erreurs et retours d’API avec contexte.

**Insuffisances**
- Pas de corrélation ou d’alerting : les journaux restent locaux au poste utilisateur.
- Aucun formatage structuré (JSON) ni rotation configurable côté client.
- Aucun guide sur la rétention et le monitoring (ex. comment intégrer avec SIEM).

**Recommandations**
1. Ajouter un mode “structured logging” (JSON) et la possibilité de pousser vers syslog/HTTP.
2. Introduire une tâche planifiée qui purge ou archive automatiquement les logs.
3. Documenter les événements critiques à surveiller (login, import licence, paiements, scan invasif).

### A10 – Server-Side Request Forgery (SSRF)
**Constats**
- Les modules `injection` et `tls` effectuent des requêtes réseau vers des domaines fournis par l’utilisateur, sans filtrage ni liste blanche (`web_sentinel/checks/injection.py`, `web_sentinel/checks/tls.py`).
- Le scanner ne propose pas de détection dédiée SSRF (pas de tests sur les endpoints internes, metadata AWS, etc.).

**Recommandations**
1. Ajouter un module de détection SSRF (tests HTTP ciblant `169.254.169.254`, fichiers `/etc/passwd`, etc.).
2. Permettre à l’utilisateur de définir des règles de restriction (ex. éviter que la GUI contacte des IP privées).
3. Journaliser explicitement toutes les requêtes outbound déclenchées par un scan et afficher un avertissement lorsqu’une cible résout vers une adresse privée.

---

**Prochaines étapes suggérées**
1. Prioriser A01/A02/A07 (surface authentification/secret) avant d’exposer davantage l’outil.
2. Mettre en place une chaîne CI dédiée à la sécurité (linting + dependency audit + tests d’abus).
3. Répéter cette revue à chaque version majeure et intégrer le fichier dans `docs/security/`.

## TODO – Renforcer le code existant
1. **Chiffrer les artefacts locaux** (sessions, licences, historique) dans `~/.web-sentinel` via Fernet/DPAPI/Keychain.
2. **Durcir AuthManager** : expiration configurable, verrouillage après X échecs, rotation des tokens et support MFA.
3. **Externaliser secrets Stripe** : supprimer les Price IDs “LIVE” du dépôt et charger les clés depuis un coffre.
4. **Mettre en place un verrouillage des dépendances** (`pip-compile` + `pip-audit` en CI) et publier les hash des binaires PyInstaller.
5. **Signer les exécutables** et publier automatiquement les checksum SHA256 dans `dist/`.
6. **Centraliser la décision d’accès** côté API (auth obligatoire sur `web_sentinel/payment/api_routes.py`, scopes par rôle).
7. **Ajouter un mode logging structuré** (JSON + export syslog/HTTP) et planifier la rétention/purge automatique.

## TODO – Fonctionnalités à implémenter pour viser l’excellence OWASP
1. **Module SSRF dédié** : tests ciblant IP internes/metadata, règles de blocage d’IP privées et journalisation des requêtes sortantes.
2. **Baseline de configuration « secure-by-default »** + commande `web-sentinel doctor` pour vérifier les environnements utilisateurs.
3. **Threat modeling documenté** (flux auth/paiement/licence) et tests d’abus automatisés dans la CI.
4. **Intégration SCA continue** (ex. Dependabot + SBOM) couvrant Python, JS et artefacts packagés.
5. **Protection d’intégrité des profils/plug-ins** (signature, vérification de checksum avant import).
6. **Monitoring centralisé** : possibilité d’envoyer les événements critiques vers un SIEM/service d’alerte.
7. **Guides de hardening publics** (docs/security/), mis à jour à chaque release majeure.