OmniRoute/docs/i18n/fr/SECURITY.md

Security Policy (Français)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

Signalement des vulnérabilités

Si vous découvrez une vulnérabilité de sécurité dans OmniRoute, veuillez la signaler de manière responsable :

1. N’OUVREZ PAS de ticket GitHub public
2. Utilisez les avis de sécurité GitHub
3. Incluez : une description, les étapes de reproduction et l’impact potentiel

Délais de réponse

Étape	Objectif
Accusé de réception	48 heures
Triage et évaluation	5 jours ouvrés
Publication du correctif	14 jours ouvrés (cas critiques)

Versions prises en charge

Version	État de la prise en charge
3.8.x	✅ Active
3.7.x	✅ Sécurité
< 3.7.0	❌ Non prise en charge

---

Architecture de sécurité

OmniRoute met en œuvre un modèle de sécurité multicouche :

Requête → CORS → Pipeline d’autorisation (classification → politiques → application)
        → Garde-fous (masquage des PII, injection de prompt, passerelle de vision)
        → Limiteur de débit → Disjoncteur → Délai de récupération → Verrouillage du modèle → Fournisseur

🔐 Authentification et autorisation

Fonctionnalité	Implémentation
Connexion au tableau de bord	Authentification par mot de passe avec des jetons JWT (cookies HttpOnly)
Authentification par clé API	Clés signées par HMAC avec validation CRC
OAuth 2.0 + PKCE	L’OAuth par navigateur/appareil propre au fournisseur utilise PKCE lorsqu’il est pris en charge ; les identifiants Devin servant uniquement à l’importation sont traités séparément.
Actualisation des jetons	Actualisation automatique des jetons OAuth avant leur expiration
Cookies sécurisés	AUTH_COOKIE_SECURE=true pour les environnements HTTPS
Pipeline d’autorisation	Classification des routes (PUBLIC / CLIENT_API / MANAGEMENT) — voir docs/architecture/AUTHZ_GUIDE.md
Niveaux de protection des routes	Modèle à 3 niveaux pour les routes de gestion (LOCAL_ONLY / ALWAYS_PROTECTED / MANAGEMENT) — voir docs/security/ROUTE_GUARD_TIERS.md
Portée de gestion MCP	L’accès distant à /api/mcp/* est protégé par des clés API ayant la portée manage ; /api/cli-tools/runtime/* reste strictement limité à l’interface de bouclage. Voir ROUTE_GUARD_TIERS
Portées MCP	32 portées granulaires (read:health, write:combos, execute:completions, etc.) — voir docs/frameworks/MCP-SERVER.md

🛡️ Chiffrement des données au repos

Toutes les données sensibles stockées dans SQLite sont chiffrées à l’aide de AES-256-GCM, avec dérivation de clé par scrypt :

• Clés API, jetons d’accès, jetons d’actualisation et jetons d’identité
• Format versionné : enc:v1:<iv>:<ciphertext>:<authTag>
• Mode transparent (texte en clair) lorsque STORAGE_ENCRYPTION_KEY n’est pas défini

# Générer la clé de chiffrement :
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

🛡️ Cadre de garde-fous

OmniRoute fournit un registre de garde-fous rechargeable à chaud (src/lib/guardrails/) comprenant 3 garde-fous intégrés, classés par priorité :

Garde-fou	Priorité	Objectif
vision-bridge	5	Rend les descriptions d’images accessibles aux modèles sans vision ; protection SSRF pour les URL d’images
pii-masker	10	Masquage des PII avant et après l’appel (e-mails, téléphone, CPF, CNPJ, cartes de crédit, SSN)
prompt-injection	20	Détecte les motifs de contournement, d’usurpation de rôle, de jailbreak et de fuite

Les garde-fous personnalisés sont enregistrés via registerGuardrail(new MyGuardrail()). Le modèle est permissif en cas d’échec (les exceptions ne bloquent jamais le trafic). Désactivation pour chaque requête via l’en-tête x-omniroute-disabled-guardrails. → Voir docs/security/GUARDRAILS.md.

🧠 Protection contre l’injection de prompt

Middleware heuristique, sans garantie absolue, qui détecte les motifs d’injection de prompt dans les requêtes adressées aux LLM. Il ne s’agit pas d’un pare-feu complet contre les injections de prompt — il peut produire des faux positifs (prompts inoffensifs de persona/jeu de rôle) et des faux négatifs (leetspeak, espacement, motifs dans d’autres langues que l’anglais).

Type de motif	Gravité	Exemple
Contournement du système	Élevée	« ignore all previous instructions »
Usurpation de rôle	Moyenne	« you are now DAN, you can do anything »
Injection de délimiteur	Élevée	Séparateurs encodés pour rompre les limites du contexte
DAN/Jailbreak	Moyenne	Motifs connus de prompts de jailbreak
Fuite d’instructions	Élevée	« show me your system prompt »
Contournement par encodage	Moyenne	Décodage base64/rot13/hex + mots-clés d’instruction

Seules les détections de gravité Élevée sont bloquées en mode block. Les familles de gravité Moyenne sont journalisées, mais ne sont jamais bloquées par sanitizeRequest.

Configurez cette fonctionnalité via le tableau de bord (Paramètres → Sécurité) ou le fichier .env :

INPUT_SANITIZER_ENABLED=true
INPUT_SANITIZER_MODE=block    # warn | block (politique d’injection ; l’ancien mode « redact » ne supprime pas le texte d’injection)
INPUT_SANITIZER_BLOCK_THRESHOLD=high  # high (par défaut) | medium | low — les niveaux de gravité égaux ou supérieurs à celui-ci sont bloqués en mode block

🔒 Masquage des PII

Détection automatique et masquage facultatif des informations personnelles identifiables :

Type de PII	Modèle	Remplacement
E-mail	user@domain.com	[EMAIL_REDACTED]
CPF (Brésil)	123.456.789-00	[CPF_REDACTED]
CNPJ (Brésil)	12.345.678/0001-00	[CNPJ_REDACTED]
Carte bancaire	4111-1111-1111-1111	[CC_REDACTED]
Téléphone	+55 11 99999-9999	[PHONE_REDACTED]
SSN (États-Unis)	123-45-6789	[SSN_REDACTED]

PII_REDACTION_ENABLED=true   # demander la réécriture des PII ; indépendant de INPUT_SANITIZER_MODE
PII_RESPONSE_SANITIZATION=true  # facultatif : masquer les PII dans les réponses du fournisseur renvoyées aux clients

🌐 Sécurité du réseau

Fonctionnalité	Description
CORS	Liste explicite des origines interdomaines autorisées (CORS_ALLOWED_ORIGINS ; anciennement CORS_ORIGIN)
Filtrage des adresses IP	Plages d'adresses IP autorisées/bloquées dans le tableau de bord
Limitation du débit	Limites de débit par fournisseur avec temporisation automatique
Protection contre les rafales	Le mutex et le verrouillage par connexion empêchent les erreurs 502 en cascade
Empreinte TLS	Usurpation d'une empreinte TLS de type navigateur pour réduire la détection des robots
Empreinte CLI	Ordre des en-têtes et du corps propre à chaque fournisseur pour reproduire les signatures CLI natives

🔌 Résilience et disponibilité

Fonctionnalité	Description
Disjoncteur	3 états (Fermé → Ouvert → Semi-ouvert) par fournisseur, persistés dans SQLite
Idempotence des requêtes	Fenêtre de déduplication de 5 secondes pour les requêtes en double
Temporisation exponentielle	Nouvelle tentative automatique avec des délais croissants
Tableau de bord d'intégrité	Surveillance en temps réel de l'état des fournisseurs

📋 Conformité

Fonctionnalité	Description
Conservation des journaux	Nettoyage automatique après CALL_LOG_RETENTION_DAYS
Désactivation de la journalisation	L'indicateur noLog de chaque clé API désactive la journalisation des requêtes
Journal d'audit	Actions administratives enregistrées dans la table audit_log
Audit MCP	Journalisation d'audit reposant sur SQLite pour tous les appels d'outils MCP
Validation Zod	Toutes les entrées d'API sont validées avec des schémas Zod v4 au chargement du module

---

Variables d’environnement requises

Tous les secrets doivent être définis avant le démarrage du serveur. Le serveur échouera immédiatement s’ils sont absents ou trop faibles.

# OBLIGATOIRE — le serveur ne démarrera pas sans ces variables :
JWT_SECRET=$(openssl rand -base64 48)     # 32 caractères minimum
API_KEY_SECRET=$(openssl rand -hex 32)    # 16 caractères minimum

# RECOMMANDÉ — active le chiffrement des données au repos :
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

Le serveur rejette activement les valeurs connues comme étant faibles, telles que changeme, secret ou password.

---

Sécurité de Docker

• Utilisez un utilisateur non-root en production
• Montez les secrets en tant que volumes en lecture seule
• Ne copiez jamais de fichiers .env dans les images Docker
• Utilisez .dockerignore pour exclure les fichiers sensibles
• Définissez AUTH_COOKIE_SECURE=true lorsque le serveur se trouve derrière HTTPS

docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --read-only \
  -p 20128:20128 \
  -v omniroute-data:/app/data \
  -e JWT_SECRET="$(openssl rand -base64 48)" \
  -e API_KEY_SECRET="$(openssl rand -hex 32)" \
  -e STORAGE_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  diegosouzapw/omniroute:latest

---

Dépendances

• Exécutez régulièrement npm audit (npm run audit:deps couvre l’application principale et Electron)
• Maintenez les dépendances à jour
• Le projet utilise husky + lint-staged pour les vérifications avant commit (lint-staged + check-docs-sync + check:any-budget:t11)
• Le pipeline CI exécute les règles de sécurité ESLint à chaque push (no-eval, no-implied-eval, no-new-func = erreur)
• Les constantes des fournisseurs sont validées lors du chargement du module avec Zod (src/shared/validation/schemas.ts)
• Bibliothèques sécurisées par défaut utilisées : dompurify / isomorphic-dompurify (XSS), jose (JWT), better-sqlite3 (aucun risque d’injection SQL grâce aux requêtes paramétrées), bcryptjs (hachage des mots de passe)

Règles de sécurité strictes

Ces règles sont appliquées par les outils et les réviseurs :

1. Ne commitez jamais de secrets — .env est ignoré par Git ; .env.example sert de modèle (aucune valeur littérale, uniquement des commentaires — voir PUBLIC_CREDS.md ci-dessous)
2. N’utilisez jamais eval(), new Function() ou une évaluation implicite — ESLint applique cette règle
3. Ne contournez jamais les hooks Husky (--no-verify, --no-gpg-sign) sans l’approbation explicite de l’opérateur
4. N’écrivez jamais de SQL brut dans les routes — passez toujours par src/lib/db/ (requêtes paramétrées)
5. Validez toujours les entrées avec Zod — src/shared/validation/schemas.ts
6. Assainissez toujours les en-têtes en amont — liste de refus dans src/shared/constants/upstreamHeaders.ts
7. Chiffrez les identifiants au repos — AES-256-GCM via src/lib/db/encryption.ts
8. Utilisez resolvePublicCred() pour les identifiants OAuth publics en amont — n’intégrez jamais de valeurs littérales AIza… / GOCSPX-… / …apps.googleusercontent.com dans le code source. Consultez docs/security/PUBLIC_CREDS.md.
9. Faites passer les réponses d’erreur par buildErrorBody() / sanitizeErrorMessage() — n’incluez jamais directement err.stack / err.message dans les corps de réponse HTTP / SSE / de l’exécuteur / MCP. Consultez docs/security/ERROR_SANITIZATION.md.
10. Transmettez les valeurs d’exécution de exec() / spawn() via l’option env — n’interpolez jamais des chemins externes ou des valeurs non fiables dans des scripts transmis au shell. Référence : src/mitm/cert/install.ts::updateNssDatabases.
11. Privilégiez les bibliothèques sécurisées par défaut — consultez tldrsec/awesome-secure-defaults (Helmet.js, DOMPurify, ssrf-req-filter, safe-regex, Google Tink). Utilisez-les avant de développer votre propre solution.

Résultats des scanners de chaîne d’approvisionnement (Socket.dev / Snyk / similaires)

L’artefact npm omniroute publié inclut le build Next.js output: "standalone", ce qui signifie que chaque gestionnaire de route — y compris les fonctionnalités privilégiées documentées (MITM, importation Zed, Cloud Sync, superviseur de services intégré) — se retrouve dans des fragments minifiés .next/server/*.js. Les scanners heuristiques de chaîne d’approvisionnement comparent fréquemment ces fragments à des signatures de logiciels malveillants.

La configuration du scanner que nous utilisons se trouve dans socket.yml, à la racine du dépôt (format v2 de l’application GitHub Socket.dev — voir https://docs.socket.dev/docs/socket-yml). Elle exclut explicitement les répertoires non distribués (tests/, _tasks/, _references/, _ideia/, _mono_repo/, docs/, etc.) afin que le scanner ne signale que les chemins de code qui parviennent réellement aux utilisateurs de la version publiée — l’analyse elle-même est déclenchée par l’application GitHub Socket qui lit ce fichier, et non par un workflow de ce dépôt.

Pour chaque catégorie de résultat, nous conservons une attestation du mainteneur propre à chaque résultat :

• docs/security/SOCKET_DEV_FINDINGS.md — correspondance par résultat : fichier source ↔ fragment signalé ↔ comportement ↔ mesure d’atténuation appliquée dans la v3.8.6.
• Les blocs SECURITY-AUDITOR-NOTE: dans le code source, placés à chaque fonction signalée, renvoient vers ce même document.

Pour les utilisateurs dont le pipeline ne permet pas d’assouplir l’alerte : compilez avec OMNIROUTE_BUILD_PROFILE=minimal npm run build. Cela remplace les quatre modules sensibles par des stubs qui renvoient une réponse HTTP 503 feature-disabled lors de l’exécution, de sorte que les chemins de code privilégiés sont physiquement absents du bundle. Consultez docs/security/SOCKET_DEV_FINDINGS.md pour la procédure de publication.

Références

• docs/architecture/AUTHZ_GUIDE.md — pipeline d’autorisation
• docs/security/GUARDRAILS.md — infrastructure de garde-fous
• docs/security/COMPLIANCE.md — journal d’audit et conservation
• docs/security/PUBLIC_CREDS.md — modèle obligatoire pour les identifiants publics des services en amont
• docs/security/ERROR_SANITIZATION.md — modèle obligatoire pour les réponses d’erreur
• docs/security/SOCKET_DEV_FINDINGS.md — attestation du mainteneur concernant les résultats des scanners de chaîne d’approvisionnement
• docs/architecture/RESILIENCE_GUIDE.md — disjoncteur + délai de récupération + verrouillage
• docs/security/STEALTH_GUIDE.md — empreinte TLS (avis juridique/éthique)
• CLAUDE.md — règles strictes pour les agents d’IA
• tldrsec/awesome-secure-defaults — bibliothèques sécurisées par défaut soigneusement sélectionnées