La sécurité du contenu est primordiale dans la publication d’un site web. Il n’en est pas moins pour PrestaShop. La politique sécuritaire est alors de n’afficher par défaut aucun message d’erreur, ou de retour d’un quelconque débogage de code, ou même de configuration de serveurs / services liés à l’hébergement web. Afficher des erreurs éventuelles, ou plutôt laisser la possibilité de les afficher expose votre site web à la divulgation d’informations qui pourraient servir mal-intentionnellement à votre égard.
En mode production, contrairement au mode développement, et / ou en pré-production, il est impératif de laisser cet option par défaut, afin de ne rien afficher, même si votre page est en erreur. De cette manière, toute tentative mal-seine de provocation volontaire d’erreur ne mènera son auteur qu’à un résultat nul qui pourrait l’informer d’une faille éventuelle dans votre boutique PrestaShop.
2 options sont donc envisageables pour PrestaShop

Si vous êtes un développeur / intégrateur, si vous avez besoin d’une assistance ponctuelle pour résoudre un problème de comportement anormal sur votre boutique ou si vous avez une page blanche et que vous ne comprenez pas pourquoi, etc., alors éditez votre fichier ./config/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :
1
2
3
4
5
6
7
8

/* Debug only */
@ini_set(‘display_errors’, ‘on’);
define(‘_PS_DEBUG_SQL_’, true);

$start_time = microtime(true);

/* Compatibility warning */
define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, true);

Si vous ne constatez rien d’anormal, si votre boutique est en production, ou si vous n’êtes pas en phase de développement ou de débug, alors éditez votre fichier ./config/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :
1
2
3
4
5
6
7
8

/* Debug only */
@ini_set(‘display_errors’, ‘off’);
define(‘_PS_DEBUG_SQL_’, false);

$start_time = microtime(true);

/* Compatibility warning */
define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, false);
Le debug de smarty peut vous aider

Il existe aussi la possibilité d’activer la résultante complète du template Smarty en cours d’exécution. Ce mode débug n’est pas un résultat d’erreurs, mais un contenu permettant de visualiser si les démarches du développeur sont bien prises en compte pour l’intégration des traitements et des valeurs dans le template de la boutique PrestaShop. Vous pouvez alors l’activer ponctuellement en éditant votre fichier ./config/smarty.config.inc.php, et en autorisant la valeur ci-dessous :
1

$smarty->debugging = true;

Pensez à remettre cette valeur à false par défaut, une fois vos démarches terminées.
Vous souhaitez sécuriser un peu plus votre hébergement web

Ce qui suit ne s’arrête pas simplement à l’usage de PrestaShop dans votre hébergement web, mais ceci est une partie des optimisations web qui font la différence au quotidien et sur Internet en terme de sécurité et de garantie d’avoir un site web qui dure dans le temps.

Si votre hébergement web fait partie d’un service web que vous gérez, et si les publications web mises à disposition sont vouées à l’utilisateur final et non à un mode de développement ou de pré-production, alors je vous conseille vivement de modifier un élément important dans votre fichier php.ini, et de le désactiver comme ceci :
1

display_errors = Off

Cette option est associée à la variable error_reporting de ce même php.ini. Elle permet de donner le niveau d’alertes à afficher si des erreurs et/ou warnings failliraient le traitement. En mode de développement pure, il convient de passer cette valeur comme ceci :
1

error_reporting = E_ALL | E_STRICT

Ce niveau permet au développeur d’afficher l’ensemble des erreurs et warnings, même de bas niveaux, ce qui assure pendant toute la phase de développement la création d’un code propre et fonctionnel. Mais le rapport d’erreur ne s’affichera que si sa dépendance display_errors est activée. C’est pour cela qu’il convient de passer l’option display_errors à false par défaut sur votre serveur web en production, ce qui n’est pas le cas par défaut habituellement.

Dans le cas où vous n’avez pas l’accès à ce fichier de configuration php.ini, vous pouvez essayer de contrôler cette option par le biais du .htaccess (de préférence celui à la racine du votre dossier web), ou par code php (de préférence avant tous les traitements).
Désactiver l’affichage des erreurs depuis le fichier .htaccess

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante fera l’affaire en haut de votre fichier .htaccess :
1

php_flag display_errors off
Désactiver l’affichage des erreurs depuis le code

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante en début des traitements php pourra annuler l’affichage des messages d’erreurs php :
1

error_reporting(0);

De même pour les templates Smarty, propre à PrestaShop, et à spécifier après le chargement du framework Smarty Template :
1

$smarty->error_reporting = 0;

Pour php, vous avez aussi la possibilité de contrôler les niveaux d’alertes :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Rapporte les erreurs d’exécution de script
error_reporting(E_ERROR | E_WARNING | E_PARSE);

// Rapporter les E_NOTICE peut vous aider à améliorer vos scripts
// (variables non initialisées, variables mal orthographiées..)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

// Rapporte toutes les erreurs à part les E_NOTICE
// C’est la configuration par défaut de php.ini
error_reporting(E_ALL ^ E_NOTICE);

// Reporte toutes les erreurs PHP (Voir l’historique des modifications)
error_reporting(E_ALL);

// Reporte toutes les erreurs PHP
error_reporting(-1);

// Même chose que error_reporting(E_ALL);
ini_set(‘error_reporting’, E_ALL);
Parano, non, mais prévoyant

Je pense que cet article peut inviter les développeurs web, les agences web, ou même monsieur tout le monde qui s’initie au développement, a considérer que les publications dynamiques sur le web sont des proies permanentes sur Internet. Si vous autorisez l’affichage d’erreurs, et que vous-même pensez que 99% de votre site est bien conçu, les 1% restant générant des erreurs sur des pages introuvables, de code, ou pire, des erreurs SQL, peuvent être indexés par les moteurs de recherches. Si vous utilisez un framework connu, un CMS en vogue, votre site web peut sortir dans les résultats de recherches liés à des erreurs engendrant des tentatives d’intrusions, ou des injections SQL ou de codes.

En conclusion, soyez prévoyant sur cet aspect parfois délesté.