• limité l'anxiété du relecteur en utilisant $wgRequest au lieu de $_COOKIE ?
  • récupéré les cookies en utilisant $wgRequest->getCookie(...) ?
  • défini les cookies en utilisant $wgRequest->response()->setCookie(...) ?

# Tentative pour accéder à la valeur du cookie UserID.
# la valeur renvoyée n'est pas fiable; forçée à int.
$sId = intval( $wgRequest->getCookie( 'UserID' ) );

évité d'utiliser les fonctions telles que eval() et create_function(), tout comme le modificateur de modèle /e pour preg_replace(). Bien qu'elles soient puissantes et pratiques, ces fonctionnalités sont par définition non sécurisées :^[1][2]

• il est plus facile de placer des chaînes arbitraires dans le texte traité par les expressions régulières, qui – lorsqu'il est combiné avec le changeur de motif /e – peut conduire à des attaques d'injection de code.
• il est plus difficile de lire et de maintenir du code qui est à l'intérieur d'une chaîne de caractères.
• les outils statiques d'analyse ne vont pas prendre en compte les avertissements et les erreurs dans le code.
• les caches d'opcode (tels que APC) ne peuvent pas capturer le code qui se trouve à l'intérieur de chaînes de caractères.
• create_function() présente quelques fois des problèmes de ramasse miettes.
• une boucle contenant create_function() crée une nouvelle fonction à chaque itération.

Quelques fois ces fonctionnalités sont réellement nécessaires (visiblement eval.php doit exécuter eval();) mais dans la plupart des cas la fonction va échouer étant considérée comme une fonction de callback.

Les fonctions lambda en ligne rendront plus facile l'implémentation des fonctions callback en ligne tout en gardant les bénéfices du code qui a été écrit dans la syntaxe native au lieu d'utiliser les chaînes de caractères.

• tout ce qui est externe et qui est utilisé comme partie d'une expression régulière, doit être évité avec preg_quote ($externalStr, $delimiter). Il insère une barre oblique inverse '\' devant chaque caractère faisant partie de la syntaxe de l'expression régulière et échappe également le séparateur passé en second paramètre.

$str = preg_replace( "!" . preg_quote( $externalStr, '!' ) . "!", $replacement, $str );

• exécuté le programme via Shell::command() à partir de l'espace de noms MediaWiki\Shell ?
• cité tous les arguments de programmes externes en utilisant les équipements de passage de paramètre sécurisé ci-dessus (ce qui veut dire basiquement tout sauf unsafeParams())?

// échapper automatiquement les caractères dangereux
$result = Shell::command( $cmd, '--version' )
    ->params( 'some', 'extra', 'parameters' )
    ->execute();

Notez que les anciens wfShellExec() / wfEscapeShellArg() ne sont plus recommandés car ils conduisent les développeurs à oublier d'échapper les paramètres.

• utilisé User ::getEditToken() pour implémenter les mesures anti-CSRF?
• utilisé User::matchEditToken() pour contrôler le jeton et éviter les attaques temporelles ?
• réduit l'anxiété du relecteur en utilisant ou en étendant la fonctionnalité existante des formulaires de MediaWiki ?

• réduit l'anxiété du relecteur en utilisant $wgRequest au lieu de $_GET ?

# vérifier que le paramètre d'action vaut 'purge'
if ( $wgRequest->getVal( 'action' ) == 'purge' ) {
    ...

• utilisé le Html et les classes d'aide Xml ?

# rawElement() échappe chaque valeur d'attribut
# (qui dans ce cas est fournie par $myClass)
echo Html::rawElement( 'p', [ 'class' => $myClass  ] );

• réduit l'anxiété du relecteur en utilisant le ResourceLoader pour fournir le CSS et les ressources JavaScript ?

• utilisé la méthode Sanitizer::checkCss pour tout CSS reçu de l'utilisateur, éventuellement avec une classe Html.

# déclarer $CSSFromUser comme CSS de l'utilisateur.
echo Html::rawElement( 'p', [ 'style' => Sanitizer::checkCss( $CSSFromUser ) ] );

• Pour le CSS fourni par les extensions, (et non par l'utilisateur), cela n'est pas nécessaire (et peut même supprimer des éléments valides tels que background-image:). Néanmoins le CSS fourni par les extensions doit se trouver dans les feuilles de style chargées par ResourceLoader et non pas dans les attributs style.

• réduit l'anxiété du relecteur en utilisant $wgRequest au lieu de $_POST
• Toujours valider que les données POST que vous recevez sont bien celles que vous attendiez

# Vérifier que le paramètre d'action vaut 'render'
if ( $wgRequest->getVal( 'action' ) == 'render' ) {
    ...

• Voir la section GET ci-dessus

• Ajouté distinctement des commentaires pour expliquer les parties non souhaitées du code ou celles qui ne semblent pas claires ?

# $wgRequest n'est pas encore disponible. Remplacé par $_GET.
if ( $_GET['setupTestSuite'] !== null ) {
 	$setupTestSuiteName = $_GET['setupTestSuite'];
 	...

• utilisé les conteneurs de la base de données de MediaWiki ?