En-tête négligent
Kali
pour AMD64
Mac
pour ARM64
Mac
Prochainement
Fenêtres
Prochainement

Filtre JavaScript pour les ingénieurs en sécurité : Pipelines déterministes, moins de faux positifs et zéro mythe du "filtre en tant qu'assainisseur".

filter() pour les ingénieurs en sécurité : Pipelines déterministes, moins de faux positifs et zéro mythe sur le filtre en tant qu'assainisseur

Si vous avez recherché "filtre javascript"il y a de fortes chances que vous souhaitiez obtenir l'un de ces résultats :

  • Transformez une sortie de balayage bruyante en une sortie propre, actionnable liste restreinte.
  • Filtrer des tableaux d'objets (actifs, résultats, IOC, règles) sans écrire de boucles spaghetti.
  • Rendre le filtrage suffisamment rapide pour qu'il puisse être exécuté au sein de l'IC, d'un bac à sable de navigateur ou d'un pipeline de sécurité.
  • Évitez le piège classique : "filtrer les chaînes de caractères" ≠ "sécuriser les entrées non fiables".

C'est sur ce dernier point que beaucoup d'outils de sécurité échouent discrètement.

Ce n'est pas pour rien que la requête à longue traîne "javascript filter array of objects" est toujours d'actualité : un fil de discussion canonique de Stack Overflow intitulé exactement cela se trouve à l'adresse "Visionné 228k foisqui est un signal fort de ce que les praticiens cliquent, copient et déploient réellement. (Stack Overflow (en anglais))

Ce qu'il faut faire Array.prototype.filter() garantit (et ce qu'il ne garantit absolument pas)

Au niveau linguistique, filtre():

  • Retourne un nouveau tableau contenant des éléments dont le prédicat retourne vrai.
  • Produit un copie superficielle (les références des objets sont partagées, pas clonées). (MDN Web Docs)
  • Bennes emplacements vides dans les tableaux clairsemés (votre prédicat n'est pas appelé pour les "trous"). (TC39)

MDN est explicite à la fois sur "shallow copy" et "not invoked for empty slots in sparse arrays". (MDN Web Docs)

La spécification ECMAScript indique aussi explicitement que les rappels ne sont pas appelés pour les éléments manquants. (TC39)

Pourquoi les tableaux épars sont-ils importants dans les pipelines de sécurité ?

Les tableaux épars apparaissent plus souvent qu'on ne le pense : Transformations JSON, bogues de "suppression d'index", résultats partiels de la fusion de plusieurs sources, ou dédoublonnage naïf.

const results = [ {id: 1}, , {id: 3} ];     // note the hole
const kept = results.filter(() => true);

console.log(kept); // [{id: 1}, {id: 3}]  (hole disappears)

Si votre pipeline part du principe que "même longueur à l'entrée, même longueur à la sortie", les tableaux clairsemés ne fonctionneront pas. Dans un pipeline de triage, cela peut se traduire par silencieux la perte de données.

Le modèle à fort taux de clics : filtrer des tableaux d'objets

La plupart des utilisations réelles de "filtres javascript" consistent à filtrer des tableaux d'objets (assets/findings/IOCs).

Exemple : ne conserver que les découvertes exploitables sur le web, accompagnées de preuves.

const findings = [
  { id: "XSS-001", type: "xss", severity: "high", verified: true, evidence: ["req.txt", "resp.html"] },
  { id: "INFO-009", type: "banner", severity: "info", verified: false, evidence: [] },
  { id: "SSRF-004", type: "ssrf", severity: "critical", verified: true, evidence: ["dnslog.png"] },
];

const actionable = findings.filter(f =>
  f.verified &&
  (f.severity === "high" || f.severity === "critical") &&
  f.evidence?.length > 0
);

console.log(actionable.map(f => f.id)); // ["XSS-001", "SSRF-004"]

Exemple : contrôle du champ d'application (l'endroit le plus facile pour ruiner votre programme)

const inScopeHosts = new Set(["api.example.com", "admin.example.com"]);

const assets = [
  { host: "api.example.com", ip: "203.0.113.10", alive: true },
  { host: "cdn.example.com", ip: "203.0.113.11", alive: true },
  { host: "admin.example.com", ip: "203.0.113.12", alive: false },
];

const targets = assets
  .filter(a => a.alive)
  .filter(a => inScopeHosts.has(a.host));

console.log(targets);
// [{host:"api.example.com", ...}]

L'utilisation d'un Set (jeu de mots) évite l'accident O(n²) modèle (inclut() à l'intérieur filtre() à travers de grands tableaux). Cela est important lorsque vous filtrez des dizaines de milliers d'actifs.

La réalité des performances : tableaux emballés ou non, et pourquoi vous ne devriez pas vous en préoccuper outre mesure.

Le V8 fait une distinction bien connue entre emballé et trouée les tableaux ; les opérations sur les tableaux compacts sont généralement plus efficaces que celles sur les tableaux pleins. (V8)

Conséquences pour la sécurité : les pipelines qui créent des failles (supprimer arr[i]les fusions éparses) peuvent dégrader les performances et l'exactitude. La règle pratique est simple :

  • Ne créez pas de trous. Préférez épissure, filtreou reconstruire les tableaux.
  • Évitez de mélanger les types dans les tableaux chauds si vous traitez de grands ensembles de données.

La table de décision d'un ingénieur en sécurité : filtre vs certains vs trouver vs réduire

Objectif dans un pipeline de sécuritéLe meilleur outilPourquoiErreur courante
Garder toutes les correspondances (liste restreinte)filtre()Retourne un tableau de sous-ensemblesMutation de la source pendant le prédicat
Arrêt au premier match (policy gate)quelques()Sortie anticipée booléenfilter().length > 0
Obtenir la première correspondance (sélection de l'itinéraire)trouver()Sortie anticipée + élémentfilter()[0]
Construire des métriques (nombres, scores)réduire()Agrégation en un seul passageEffectuer des E/S coûteuses dans le réducteur

Il s'agit moins d'une question de style que de rendre votre pipeline déterministe et suffisamment bon marché pour être exécuté partout (CI, bac à sable du navigateur, agents d'exécution).

La surcharge dangereuse : Le "filtrage" n'est pas l'"assainissement"

Voici maintenant la partie pour laquelle les ingénieurs en sécurité doivent être impitoyables : le filtrage des chaînes n'est pas une limite de sécurité.

Les conseils de l'OWASP en matière de prévention des XSS mettent l'accent sur les points suivants codage de sortie (et en utilisant la bonne défense dans le bon contexte) plutôt que de s'appuyer sur le filtrage des entrées. (Série d'aide-mémoire de l'OWASP)

Le contenu de l'OWASP sur l'évasion des filtres XSS présente explicitement le filtrage des entrées comme une défense incomplète et répertorie les solutions de contournement. (Série d'aide-mémoire de l'OWASP)

L'aide-mémoire XSS de PortSwigger (mis à jour en octobre 2025) est également explicite sur le fait qu'il inclut des vecteurs qui permettent de contourner les WAFs et les filtres. (PortSwigger)

Un exemple réaliste : Les "filtres" d'URL qui s'effondrent sous l'effet des différences d'analyse.

Mauvais modèle :

function allowUrl(u) {
  return !u.includes("javascript :") && !u.includes("data :") ;
}

Meilleur schéma : analyse + liste d'autorisations + normalisation :

function allowUrl(u, allowedHosts) {
  const url = new URL(u, "<https://base.example>"); // safe base for relative inputs
  if (!["https:"].includes(url.protocol)) return false;
  return allowedHosts.has(url.hostname);
}

const allowedHosts = new Set(["docs.example.com", "cdn.example.com"]);

Il s'agit d'un changement de mentalité : arrêter de faire correspondre les chaînes de caractèresPour cela, il faut commencer à valider les données structurées.

Démarrer l'apprentissage du pentest via Penligent

CVEs qui prouvent que les "filtres/sanitizers" échouent en production et pourquoi vous devriez les intégrer dans vos contrôles.

Lorsque votre organisation dit "nous désinfectons le HTML", votre modèle de menace devrait immédiatement inclure : Quel assainisseur, quelle version, quelle configuration et quel historique de contournement ?

CVE-2025-66412 (XSS stocké dans le compilateur de modèles Angular)

NVD décrit un XSS stocké dans le compilateur de modèles d'Angular en raison d'un schéma de sécurité interne incomplet qui peut permettre de contourner l'assainissement intégré d'Angular ; corrigé dans les versions corrigées. (NVD)

La sécurité à portée de main : Le "framework sanitization" n'est pas une garantie permanente. Traitez-la comme n'importe quel autre contrôle de sécurité : version, avis, tests de régression.

Filtre JavaScript Penligent

CVE-2025-26791 (DOMPurify mXSS via une regex incorrecte)

NVD déclare que DOMPurify avant la version 3.2.4 avait une regex littérale de modèle incorrecte qui peut conduire à une mutation XSS dans certains cas. (NVD)

La sécurité à portée de main : les options d'assainissement sont importantes. Les combinaisons de configurations peuvent créer des conditions d'exploitation même lorsque vous "utilisez une bibliothèque respectée".

CVE-2024-45801 (Contournement du contrôle de profondeur de DOMPurify + affaiblissement de la pollution du prototype)

NVD signale que des techniques d'imbrication spéciales pourraient contourner la vérification de la profondeur ; la pollution des prototypes pourrait l'affaiblir ; corrigé dans les versions ultérieures. (NVD)

La sécurité à portée de main : les défenses qui s'appuient sur des heuristiques (limites de profondeur, contrôles d'imbrication) deviennent souvent des cibles de contournement.

CVE-2025-59364 (DoS de récursion express-xss-sanitizer)

NVD note une profondeur de récursion non bornée lors de l'assainissement des corps de requête JSON imbriqués ; l'avis de GitHub détaille l'impact et les versions corrigées. (NVD)

La sécurité à portée de main : Le code d'"assainissement" peut introduire des bogues de disponibilité. Les attaquants n'ont pas besoin de XSS s'ils peuvent planter votre service de manière fiable.

Des modèles pratiques de "filtres javascript" pour l'automatisation du pentest

1) Le "Confidence Gating" : ne garder que les candidats à forte probabilité pour une vérification coûteuse

const candidates = [
  { id: "C1", signal: 0.92, cost: 3.0 },
  { id: "C2", signal: 0.55, cost: 1.2 },
  { id: "C3", signal: 0.81, cost: 9.5 },
];

const budget = 10;
const shortlist = candidates
  .filter(c => c.signal >= 0.8)        // confidence threshold
  .filter(c => c.cost <= budget);      // cheap enough to verify

console.log(shortlist.map(c => c.id)); // ["C1"]

2) Complétude des preuves : ne pas laisser les rapports être expédiés sans preuve

const reportItems = findings.filter(f =>
  f.verified &&
  Array.isArray(f.evidence) &&
  f.evidence.length >= 1
) ;

3) Filtres "Kill-switch" : appliquer la politique avant toute étape d'exploitation

Utilisation quelques() pour "refuser en cas de correspondance" :

const forbidden = [/\\.gov$/i, /\\.mil$/i];
const isForbidden = host => forbidden.some(rx => rx.test(host));

Où se situe la négligence

Dans le cadre d'un flux de travail fondé sur des données probantes (evidence-first), filtre() est idéal pour orchestration déterministeLa partie la plus difficile est la boucle de vérification : décider de ce qu'il faut vérifier ensuite, des pistes à explorer et de ce qui doit figurer dans le rapport final. La partie la plus difficile est la boucle de vérification : reproduire, collecter les preuves et assurer la cohérence des résultats d'une exécution à l'autre.

C'est le genre d'endroit où une plateforme de pentest pilotée par l'IA peut s'intégrer naturellement : vous filtrez les candidats dans le code, puis utilisez un système automatisé pour valider, capturer des preuves et maintenir une exécution cohérente dans tous les environnements. Le positionnement de Penligent en tant que plateforme de pentest IA a du sens spécifiquement dans ce segment "vérification + preuve + rapport" du pipeline.

Penligent : https://penligent.ai/

filtre javascript Penligent

Une courte liste de contrôle pour assurer la sécurité de l'utilisation du "filtre javascript".

  • Traiter filtre() comme mise en forme des donnéeset non "l'assainissement des entrées".
  • Évitez les tableaux peu denses ; rappelez-vous que les rappels sont ignorés pour les emplacements vides. (TC39)
  • Utilisation Set (jeu de mots)/Carte pour les filtres d'appartenance à l'échelle.
  • Préférer quelques()/trouver() lorsque vous avez besoin d'une sortie anticipée.
  • Pour la défense contre les XSS, suivez les conseils de l'OWASP en matière d'encodage basé sur le contexte, et non les filtres de la liste noire. (Série d'aide-mémoire de l'OWASP)
  • Suivre les CVE des assainisseurs/cadres comme un risque de premier ordre pour la chaîne d'approvisionnement. (NVD)

Références et liens d'autorité (copier/coller)

Partager l'article :
Articles connexes
Pied de page négligent