Skip to content

SECURITY.md

Latest commit

 

History

History
293 lines (226 loc) · 23.4 KB

SECURITY.md

File metadata and controls

293 lines (226 loc) · 23.4 KB
Raw

Security Policy (Français)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 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élai 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.9.x 🗓️ Prévue — branche LTS (stable/v3), voir ci-dessous
3.8.x ✅ Active
3.7.x ✅ Sécurité
< 3.7.0 ❌ Non prise en charge

Fenêtre de support LTS (v3.9.x)

Après la version 3.8.59, la prochaine version est 3.9.0. Elle inaugure la branche de support à long terme sur stable/v3 (voir ROADMAP.md → « Phase 3 — v3.9.0 LTS »).

  • Ce que reçoit stable/v3 : des corrections de bogues, des correctifs de sécurité et des mises à jour de fournisseurs. Les nouvelles fonctionnalités sont destinées au canal v4 ; la stabilité est la priorité de la branche LTS. npm install omniroute (le dist-tag latest) reste sur la v3 pendant tout le cycle de la v4.
  • Durée de la fenêtre : stable/v3 reçoit des correctifs de sécurité et des corrections de régressions critiques pendant 12 mois après la publication de la version 3.9.0, ou jusqu’à 90 jours après la publication de v4.0.0 avec le dist-tag latest — selon l’échéance la plus tardive. La date de fin qui en résulte est consignée dans les notes de publication de la version 3.9.0 et dans ROADMAP.md au moment de sa publication.
  • Signaler une vulnérabilité dans la branche LTS : utilisez le même canal que pour toute autre version — un avis de sécurité GitHub privé, jamais un ticket public. Indiquez la version que vous avez testée (par exemple 3.9.2) ; les correctifs sont intégrés à stable/v3, puis reportés en aval vers la v4.
  • Référence de sécurité lors de la publication LTS : l’état mesuré par l’analyseur, les preuves relatives à la protection des routes et aux identifiants publics sont consignés dans docs/security/LTS_SECURITY_BASELINE.md.

Architecture de sécurité

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

Requête → CORS → Pipeline Authz (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 Le protocole OAuth propre au fournisseur, via navigateur/appareil, utilise PKCE lorsqu’il est pris en charge ; les identifiants Devin réservés à 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 Authz 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
MCP avec portée de gestion Accès distant à /api/mcp/* contrôlé par des clés API avec 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 au repos

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

  • Clés API, jetons d’accès, jetons d’actualisation et jetons d’identité
  • Format versionné : enc:v1:<iv>:<ciphertext>:<authTag>
  • Mode de transmission directe (texte en clair) lorsque STORAGE_ENCRYPTION_KEY n’est pas définie
# 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 modèles sans capacités visuelles compatibles avec les descriptions d’images ; protection SSRF pour les URL d’images
pii-masker 10 Masquage des PII avant et après l’appel (e-mails, téléphones, CPF, CNPJ, cartes bancaires, SSN)
prompt-injection 20 Détecte les motifs de contournement, de détournement de rôle, de jailbreak et de fuite

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

🧠 Protection contre l’injection de prompt

Middleware heuristique « best effort » 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 bénins de persona/JDR) et des faux négatifs (leet speak, espacement, motifs dans d’autres langues que l’anglais).

Type de motif Gravité Exemple
Contournement système Élevée « ignorer toutes les instructions précédentes »
Détournement de rôle Moyenne « tu es maintenant DAN, tu peux tout faire »
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 « montre-moi ton prompt système »
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 .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é supérieurs ou égaux à celui-ci sont bloqués en mode block

🔒 Caviardage des PII

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

Type de PII Motif 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   # réécriture des PII de la requête ; indépendante de INPUT_SANITIZER_MODE
PII_RESPONSE_SANITIZATION=true  # facultatif : caviarde les PII dans les réponses des fournisseurs renvoyées aux clients

🌐 Sécurité réseau

Fonctionnalité Description
CORS Liste d’autorisation explicite des origines croisées (CORS_ALLOWED_ORIGINS ; anciennement CORS_ORIGIN)
Filtrage 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
Anti-Thundering Herd Un mutex et un verrouillage par connexion empêchent les erreurs 502 en cascade
Empreinte TLS Usurpation d’une empreinte TLS similaire à celle d’un navigateur afin de réduire la détection des bots
Empreinte CLI Ordonnancement des en-têtes/du corps par fournisseur afin de reproduire les signatures des 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’état 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 des journaux L’indicateur noLog propre à chaque clé API désactive la journalisation des requêtes
Journal d’audit Actions administratives suivies dans la table audit_log
Audit MCP Journalisation d’audit basée sur SQLite pour tous les appels d’outils MCP
Validation Zod Toutes les entrées de l’API sont validées avec les 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 min.
API_KEY_SECRET=$(openssl rand -hex 32)    # 16 caractères min.

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

Le serveur rejette activement les valeurs notoirement faibles telles que changeme, secret ou password.

Sécurité de Docker

  • Utiliser un utilisateur non-root en production
  • Monter les secrets en tant que volumes en lecture seule
  • Ne jamais copier de fichiers .env dans les images Docker
  • Utiliser .dockerignore pour exclure les fichiers sensibles
  • Définir 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écuter régulièrement npm audit (npm run audit:deps couvre le projet principal et electron)
  • Maintenir 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 au chargement du module via 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 jamais commiter de secrets — .env est ignoré par Git ; .env.example est le modèle (aucune valeur littérale, uniquement des commentaires — voir PUBLIC_CREDS.md ci-dessous)
  2. Ne jamais utiliser eval(), new Function() ou une évaluation implicite — ESLint veille à l’application de cette règle
  3. Ne jamais contourner les hooks Husky (--no-verify, --no-gpg-sign) sans l’approbation explicite de l’opérateur
  4. Ne jamais écrire de SQL brut dans les routes — toujours passer par src/lib/db/ (requêtes paramétrées)
  5. Toujours valider les entrées avec Zod — src/shared/validation/schemas.ts
  6. Toujours assainir les en-têtes en amont — liste de refus dans src/shared/constants/upstreamHeaders.ts
  7. Chiffrer les identifiants au repos — AES-256-GCM via src/lib/db/encryption.ts
  8. Utiliser resolvePublicCred() pour les identifiants OAuth publics en amont — ne jamais intégrer de valeurs littérales AIza… / GOCSPX-… / …apps.googleusercontent.com dans le code source. Voir docs/security/PUBLIC_CREDS.md.
  9. Faire passer les réponses d’erreur par buildErrorBody() / sanitizeErrorMessage() — ne jamais placer directement err.stack / err.message dans les corps de réponse HTTP / SSE / de l’exécuteur / MCP. Voir docs/security/ERROR_SANITIZATION.md.
  10. Transmettre les valeurs d’exécution de exec() / spawn() via l’option env — ne jamais interpoler sous forme de chaîne 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égier les bibliothèques sécurisées par défaut — voir tldrsec/awesome-secure-defaults (Helmet.js, DOMPurify, ssrf-req-filter, safe-regex, Google Tink). Les utiliser en priorité avant de développer votre propre solution.

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

Remarque sur la portée : le fichier socket.yml à la racine du dépôt définit uniquement les projectIgnorePaths pour l’analyse post-publication, côté registre, de l’artefact npm publié par Socket.dev — il ne constitue pas un contrôle bloquant appliqué lors de la CI ou de la fusion des PR. Aucun workflow dans .github/workflows, aucun script de package.json et aucune cible de Makefile n’invoquent Socket.dev.

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 atteignent effectivement les 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 maintenons une attestation distincte des responsables de maintenance :

  • docs/security/SOCKET_DEV_FINDINGS.md — cartographie 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 au niveau de chaque fonction signalée, renvoient vers le 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. Cette commande 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 soient physiquement absents du bundle. Consultez docs/security/SOCKET_DEV_FINDINGS.md pour connaître la procédure de publication.

Références