Comment empêcher un paquet de publication d’embarquer du contenu non approuvé ?

Un build peut réussir et embarquer une page en brouillon, un fichier oublié ou une version différente de celle qui a été relue. Si le job de publication reconstruit le site, l’artifact inspecté et celui envoyé peuvent aussi diverger. Pour réduire ces risques, fermez la sélection du contenu puis vérifiez l’inventaire exact transmis à la publication.

Définir ce qui a le droit de sortir

Dans ce portfolio, le mode approved produit un manifeste de routes statiques et de contenus retenus. La liste est versionnée dans src/data/approved-static-routes.json; les contenus publiés sont sélectionnés par leur statut dans le catalogue. Une sélection vide ou un mode preview ne peut pas produire le paquet.

Cette allowlist est une frontière explicite. Le packageur ne copie pas tout dist. Il parcourt les routes attendues et leurs liens locaux puis refuse un lien vers une route non approuvée, une route manquante, un chemin qui sort de la racine ou un lien symbolique.

Fermer aussi les fichiers et leurs références

Le packageur suit les références locales depuis le HTML et les feuilles CSS. L’allowlist accepte uniquement les feuilles CSS, les images, les documents explicitement approuvés et les métadonnées nécessaires. Les documents doivent figurer dans le manifeste avec leur empreinte attendue. Une image ne peut pas dépasser la taille limite; les SVG sont contrôlés contre les éléments exécutables et les références externes.

Le contrôle du HTML refuse notamment les scripts, formulaires, iframes, handlers d’événements et chargements de ressources non pris en charge. Les références externes de contenu doivent utiliser HTTPS. Les pages de préproduction restent noindex et le sitemap est exclu tant que la visibilité ne permet pas l’indexation.

Vérifier l’artifact que le job de publication reçoit

Le build écrit publish-site/ et un manifeste qui répertorie chaque fichier attendu avec son chemin, son type, sa taille et une empreinte SHA-256. Le job de publication utilise l’artifact du build approuvé; sa dépendance GitLab est explicite et il ne reconstruit pas le site.

Avant l’envoi, verify_site_artifact.sh compare les chemins du manifeste aux fichiers présents. Il recalcule tailles et empreintes, vérifie les métadonnées de visibilité et refuse un fichier ajouté, absent ou modifié. Une empreinte identique montre la concordance avec le manifeste fourni, sans prouver l’authenticité si paquet et manifeste sont remplacés ensemble. Protégez leur provenance et leur transmission.

Placez-vous à la racine du dépôt avec Node.js, les scripts de cette version, un paquet existant publish-site/ et son publish-manifest.json version 4. Le vérificateur JavaScript contrôle aussi routes, ancres et visibilité prelaunch sans indexation :

node scripts/deploy/verify_publish_artifact.mjs publish-site publish-manifest.json

Le résultat attendu est un code de sortie zéro après les contrôles. Une erreur de fichier, manifeste, route ou visibilité arrête la livraison : examinez le diagnostic avant de régénérer le paquet. Si CI_COMMIT_SHA est présent, il doit correspondre au commit du manifeste. La commande vérifie le paquet existant sans reconstruction.

Pour sa transmission, consultez Un job CI manque-t-il d’un fichier requis ou seulement d’un cache ?.

Dans le pipeline du portfolio, la publication est manuelle et réservée à main protégée. Le job synchronise uniquement l’artifact issu du build approuvé.

Tester les refus

Les tests locaux du packageur couvrent aussi les chemins de rejet : route non sélectionnée, chemin dangereux, document absent de la liste, mauvaise empreinte, asset distant, SVG exécutable, manifeste incohérent et paquet modifié après génération.

Pour adapter cette approche, définissez d’abord l’unité à approuver — routes, fichiers ou les deux — puis faites échouer le build si la sélection est vide. Produisez l’artifact une fois. Donnez ensuite au job de publication une dépendance explicite vers cet artifact et vérifiez son inventaire avant tout transfert. Une liste exhaustive donne une réponse concrète à la question : qu’est-ce qui va réellement sortir ?

Pour l’identité et les permissions de livraison, consultez Déployer depuis GitLab sans clé AWS permanente : l’IaC OIDC du portfolio.