D'après l'étude la plus complète à ce jour de Google, 95 % des déploiements réels de politique de sécurité du contenu (CSP) sont contournés et 99,34 % des hôtes dotés de politiques CSP utilisent des politiques qui n'offrent aucun avantage contre XSS.

C'est pourquoi Google suggère que le modèle de désignation de la confiance en spécifiant des listes blanches d'URL à partir desquelles les scripts peuvent s'exécuter soit remplacé par une approche basée sur des nonces et des hachages, déjà définis par la spécification CSP et disponibles dans les principales implémentations de navigateurs. D'où le nom CSP strict.

Dans le cadre d'une Single Page App (SPA) comme le framework Next.js React, nous devons utiliser un CSP basé sur Hashed afin d'intégrer correctement un CSP strict qui offrira une réelle protection contre les attaques CSS.

Selon la complexité de votre application, l'intégration d'une politique de sécurité du contenu basée sur le hachage peut être triviale et nécessiter de nombreuses manipulations de code. C'est pourquoi je suis venu créer un package sur NPM spécialement conçu pour Next.js afin de permettre aux développeurs d'intégrer un CSP strict en un clin d'œil avec seulement quelques lignes de code.

 est un générateur de politique de sécurité stricte du contenu basé sur le hachage pour Next.js qui s'intègre facilement dans le fichier 

 de votre application Next.js. Une fois en production, il injectera automatiquement les hachages dans la balise méta de la politique de sécurité du contenu et se protégera contre XSS une fois déployé et mis en cache sur le CDN.



Voici un exemple de _document.tsx avec une intégration basique de next-strict-csp :


Une fois mis en production, vous obtiendrez une balise méta de politique de sécurité du contenu qui ressemble à ceci:


Avec un CSP strict, vous devez également hacher vos scripts en ligne. Cela pourrait être facilement réalisé avec next-strict-csp en intégrant vos scripts en ligne dans un tableau comme celui-ci dans _document.tsx:


Une fois en ligne, vos hachages de scripts en ligne seront injectés dans la balise méta de la politique de sécurité du contenu comme ceci :

J'espère que vous avez apprécié next-strict-csp et n'hésitez pas à laisser un commentaire pour me dire ce que vous en pensez.

Comment déployer une politique de sécurité de contenu (CSP) stricte avec Next.js

Next.js utilise 4 stratégies de rendu pour construire, livrer et afficher une Application Monopage React (Single Page App) :

Régénération Statique Incrémentale (ISR)

Il s'agit de l'aide-mémoire le plus simple et le plus complet pour comprendre rapidement le fonctionnement des stratégies de rendu de pages de Next.js. De plus, cette aide-mémoire unique révèle clairement comment chaque stratégie influence les signaux Core Web Vitals : TTFB, FP, FCP, LCP, TBT et TTI.

Des explications détaillées sont également incluses pour vous aider à choisir la bonne stratégie de rendu de page pour tous les cas d'utilisation et ainsi créer des applications Web rapides que Google et les visiteurs adorent.

P.S. : Merci d'avance d'inclure cette aide-mémoire dans vos articles de blog et de mentionner l'auteur avec un lien vers cette aide-mémoire comme ceci : 

L'utltime aide-mémoire du rendu de page Next.js

Les 4 stratégies de rendu de page sont identifiées par leur acronyme respectif (SSG, SSR, ISR et CSR) et disposées en colonnes les unes à côté des autres au milieu de l'infographie.

Complètement à gauche de ces 4 colonnes, vous trouverez les 6 étapes impliquées dans le flux de traitement, depuis l'étape de construction du côté serveur jusqu'au rendu du côté client.

Complètement à droite de ces 4 colonnes, vous trouverez l'endroit où chaque étape se déroule dans le flux de traitement, soit du côté serveur, soit du côté client.

Pour chaque colonne de stratégie, vous verrez où et quand une action de construction (génération de page) est exécutée dans l'étape. Vous verrez également le flux de contenu généré (HTML - React/CSS/JS/Données) au cours de chaque étape.

Les Signaux Web Essentiels (CWV), qui font parties du 

nouveau facteur de classement de l'expérience de la page de Google

, sont identifiés à l'aide de 3 couleurs de fond distinctives, chacune liée à l'impact de la performance sur les CWV.

Une couleur rouge indique des résultats de performance MÉDIOCRES, une couleur orange indique une BONNE performance et une couleur verte indique la MEILLEURE performance.

Vous trouverez une démo en ligne avec un exemple de code source sur Github pour tester les performances de chaque stratégie de rendu de page discutée dans l'aide-mémoire :

La génération de sites statiques (SSG) est la stratégie par défaut proposée par Next.js pour générer des pages web. Next.js recommande cette stratégie pour obtenir les meilleurs résultats en termes de performance, car le contenu statique est distribué plus rapidement en utilisant des CDN qui sont plus proches de vos visiteurs, ce qui conduit à un résultat plus rapide du 

: Next.js génère une application monopage dans un fichier .html avec les fichiers .css et .js sur le serveur. Cette étape, appelée pré-rendu, n'est effectuée qu'une seule fois au moment de la construction, lorsque vous exécutez la commande next.js BUILD. Cela se fait généralement lorsque vous déployez votre application. C'est au cours de cette étape que tout le codage de la page (HTML) est généré, y compris le code React, le CSS, le JavaScript et, éventuellement, les données si la page utilise une méthode de récupération de données telle que 

: Le client demande l'application monopage au CDN.

: Le client télécharge l'application monopage depuis le CDN..

: Le client analyse et affiche l'application monopage dans le navigateur. C'est à ce moment que les 3 signaux Core Web Vitals (First Paint, First Contentful Paint et Largest Contentful Paint) sont déclenchés. Le HTML de la page ayant été rendu au préalable côté serveur, le navigateur client n'a plus qu'à le charger et à le rendre tel quel. Et comme la page est codée de manière à permettre au navigateur de la rendre avec un minimum de code JavaScript, le blocage du rendu est réduit à son minimum, ce qui se traduit par de bonnes performances.

: Le code React (JavaScript) est exécuté pour (ré)hydrater la page. Même si la page a été préconstruite, cette étape supplémentaire est nécessaire pour permettre à React d'attacher ou d'activer les événements JavaScript à son DOM virtuel et de rendre la page interactive. Comme JavaScript est exécuté à ce stade, le temps de blocage total est affecté par cette étape supplémentaire. De plus, comme le navigateur doit attendre la fin du processus d'hydratation, le Time To Interactive est également affecté.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Génération de Sites Statiques (SSG) de Next.js :

Le Rendu Côté Serveur (SSR) est la deuxième stratégie proposée par Next.js pour générer des pages web. Next.js recommande d'éviter d'utiliser cette stratégie autant que possible pour obtenir de meilleurs résultats en termes de performances, car le contenu statique est construit (pré-rendu) et distribué uniquement à chaque requête. En raison du temps supplémentaire requis par le processus de construction, le signal 

 est augmenté et conduit à de mauvais résultats.

: Next.js ne génère pas de page (pré-rendu).

: Le client demande l'application monopage au serveur. Next.js génère (pré-rendu) une application monopage dans un fichier .html avec les .css et .js sur le serveur. C'est au cours de cette étape que tout le codage de la page (HTML) est généré, y compris le code React, le CSS, le JavaScript et éventuellement les données si la page utilise la méthode de récupération de données 

: Le client télécharge l'application monopage depuis le serveur.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Rendu Côté Serveur (SSR) de Next.js :

La Régénération Statique Incrémentale (ISR) est la troisième stratégie proposée par Next.js pour générer des pages Web. Elle est identique à la génération de sites statiques (SSG), sauf que le contenu peut être reconstruit lorsque la page est mise à jour.

: Le client demande l'application monopage à partir du CDN. De plus, si la page utilise la méthode de récupération de données getStaticProps() combinée à l'option revalidate, la page est régénérée si les données renvoyées par les résultats de la récupération ont été mises à jour. Next.js recommande d'utiliser cette méthode pour un site énorme comportant plus de 1 000 pages. Étant donné que le pré-rendu de chaque page prend du temps, l'utilisation de cette méthode incrémentielle permet de procéder au pré-rendu lors de la première requête seulement et lorsque le contenu de la page est mis à jour.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Régénération Statique Incrémentale (ISR) de Next.js :

Le Rendu Côté Client (CSR) est la quatrième stratégie proposée par Next.js pour générer des pages Web. Elle identique à la génération de sites statiques (SSG), sauf que des parties du contenu peuvent être construites du côté client.

: Identique à l'ÉTAPE 1 de SSG, sauf que le contenu (données) n'est pas pré-rendu ni inclus dans le bloc statique. La taille du fichier est donc plus petite, ce qui réduit le temps de téléchargement.

: Identique à l'ÉTAPE 2 de SSG mais sans le contenu (données).

: Identique à l'ÉTAPE 3 de SSG mais sans le contenu (données).

: Identique à l'ÉTAPE 5 de SSG mais sans le contenu (données).

: Le client va chercher le contenu (données) et React met à jour l'interface utilisateur. Cette méthode est utile, par exemple, lorsque vous souhaitez afficher le squelette d'une page avec un contenu statique, puis injecter progressivement les données dans une page nécessitant un long temps d'attente pour la récupération des données.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Rendu Côté Client (CSR) de Next.js :

Next.js offre 4 stratégies de rendu pour générer, livrer et afficher une application monopage React du côté client :  SSG, SSR, ISR et CSR.

Next.js : L'ultime aide-mémoire du rendu de page

 permettent à vos visiteurs de s'abonner à vos articles de blogs. Par contre, si votre site ne contient aucun article de blog comme c'est le cas dans la majorité des microsites web, il est préférable de désactiver cette fonctionnalité de WordPress qui génère du code HTML téléchargé par le client inutilement. La rapidité de livraison d'une page web est un des nombreux facteurs qui favorise un bon classement dans les moteurs de recherche, alors vaut mieux éliminer tous ce qui est inutile.

Comment désactiver les flux RSS dans WordPress ?

Voici le code PHP qui permet de désactiver toutes les fonctionnalités concernant les 

 dans WordPress. Vous n'avez qu'à copier/coller ce code PHP dans le fichier 

 de WordPress qui est exécutée avant l'action 

, étape à laquelle les flux RSS sont chargés ainsi que la plupart des autres feuilles de styles et codes javascript.

 : En utilisant une fonction anonyme plutôt qu'une fonction nommée, on évite d'engorger le dictionnaire de noms global (Global Namespace), qui est déjà très chargé par WordPress et les extensions (plugins). Lire l'article 

Comment désactiver les Emojis dans WordPress. 

 : Finalement, on utilise l'instruction PHP 

 pour éliminer de la mémoire la fonction anonyme créée dynamiquement. Lire l'article 

Comment désactiver les Emojis dans WordPress

Désactiver les flux RSS de WordPress si votre site ne contient pas d'articles de blog pour éliminer du code HTML généré inutilement du côté client et obtenir un gain de performance SEO supplémentaire.

Comment désactiver les flux RSS dans WordPress

Que sont les flux RSS WordPress ?