Cette page décrit le modèle de sécurité de WebBlocks CMS et les étapes qu'un opérateur doit suivre. ou l'agence devrait prendre pour l'exécuter en toute sécurité pour les sites clients. Pour savoir comment signaler un vulnérabilité, voir SECURITY.md — veuillez ne pas l'ouvrir en public problèmes liés aux rapports de sécurité.

Voici les contrôles les plus importants pour une installation de production :

• Servez uniquement public/ comme racine Web. La racine de l'application contient .env, .git, .github, storage/, vendor/ et le code source qui doit ne jamais être accessible sur le Web. Pointez la racine de votre document Nginx/Apache vers public/ et confirmez que https://your-site/.git/config et https://your-site/.env renvoient tous deux 404. Un répertoire .git exposé fuit votre source complète et tous les secrets commis.
• Préférez un artefact de version à un clone Git brut en production. Release les packages excluent .git, .github, project/ et d'autres fichiers non-exécutables (voir les règles .gitattributes export-ignore). Si vous déployez un clone, désactivez appuyez sur l'installation (git remote set-url --push origin DISABLED).
• Set APP_DEBUG=false et un APP_KEY fort en production. Mode débogage fuites de traces de pile, de valeurs d'environnement et de chemins internes.
• Utilisez HTTPS et définissez SESSION_SECURE_COOKIE=true lors de la diffusion via TLS.
• Autorisations de fichier : l'utilisateur Web/PHP a besoin de lecture/écriture sur storage/ et le Racine du disque backups (storage/app/backups par défaut). not utilise-t-il 777 ? accordez plutôt la propriété ou l'accès au groupe.
• Conserver les secrets dans .env. .env, .env.* (sauf .env.example) et Les auth.json sont ignorés par Git. Les jetons d'API CMS et les mots de passe de messagerie ne sont jamais écrit dans le référentiel.

• L'authentification CMS est native Laravel (aucune exigence Breeze/Jetstream/Fortify). Administrateurs connectez-vous à /webadmin/login ; les mots de passe sont hachés par bcrypt.
• Accès à trois rôles d'installation : super_admin (à l'échelle de l'installation), site_admin (sites attribués) et editor (contenu brouillon dans les sites attribués). Intersite les actions (déplacement/duplication, Shared Slots) imposent l'accès à la fois à la source et à la cible sites. Voir Utilisateurs et autorisations.
• L'arborescence d'administration /webadmin est protégée par le CMS web + auth + admin-access pile de middleware. Les routes publiques ne restituent jamais de contenu brouillon ; brouillon/aperçu l'accès nécessite un administrateur authentifié ou un jeton de confiance avec content.read.
• Les demandes de connexion et de réinitialisation du mot de passe sont limitées. Les échecs de connexion sont limité par e-mail + IP (par défaut 5 tentatives, puis un court verrouillage qu'un la connexion réussie est effacée ; régler avec WEBBLOCKS_CMS_MAX_LOGIN_ATTEMPTS et WEBBLOCKS_CMS_LOGIN_DECAY_SECONDS). Un backstop par IP plafonne en outre le points de terminaison de connexion, de mot de passe oublié et de réinitialisation de mot de passe contre les inondations et tentatives de rotation d'e-mails.

Le Internal Content API (/webadmin/api) est destiné aux outils d'opérateur/IA de confiance.

• Les jetons personnels sont créés par tout utilisateur CMS actif à partir de Profile → Personnel Jetons API ; Les jetons système au niveau de l'installation sont créés par un super_admin à partir de Système → Jetons API. Les deux sont stockés sous forme de hachages et affichés en clair envoyer un message une seule fois.
• Chaque jeton comporte des capacités explicites (lecture, publication, média, plug-in cycle de vie, commerce, …) Les capacités avancées/destructrices sont des opt-ins distincts ; les capacités normales de création de pages sont la valeur par défaut.
• Les jetons peuvent être revoked (en conservant la ligne d'audit) ou supprimés. Un par jeton Le journal d'activité enregistre l'heure, la méthode/le chemin, l'itinéraire, le résultat de la capacité, l'adresse IP et un résumé de l'agent utilisateur - mais ne demandez jamais de corps, de chaînes de requête, de réponses ou valeurs des jetons.
• Traitez les jetons API comme des secrets. Étendez-les aux capacités minimales d'un outil besoins et faites-les pivoter s’ils sont exposés.
• Les jetons d'API personnels croisent en permanence des fonctionnalités et des sites sélectionnés avec le rôle réel de leur propriétaire, l'état actif, les affectations de site et la page autorité de flux de travail. Les opérations au niveau de l’installation restent uniquement au niveau du jeton système.
• Les jetons API personnels peuvent être limités aux adresses IPv4/IPv6 exactes ou CIDR réseaux et comportent un plafond de demande par minute spécifique au jeton. Ces contrôles sont appliquées en plus de l'accès en direct aux utilisateurs, aux sites, aux flux de travail et aux fonctionnalités.
• Les itinéraires canoniques /webadmin/api et l'ancien /admin-api les routes de compatibilité partagent le limiteur de débit Internal Content API.

Lorsqu'un proxy inverse ou un CDN est présent, configurez Laravel pour faire confiance uniquement au adresses proxy réelles et vérifiez l'adresse IP du client résolue avant d'activer un liste verte. N’acceptez jamais d’en-têtes transmis directement depuis Internet.

Voir Jetons d'API personnels et Internal Content API.

Les mises à jour du système dans l'application remplacent le code du package CMS dans vendor/fklavyenet/webblocks-cms sur le site en direct. Parce qu'une mise à jour exécute de nouveaux code, l'intégrité du package téléchargé est une exécution de code à distance limite. WebBlocks CMS atténue ce problème comme suit :

• Somme de contrôle SHA-256 obligatoire. Le programme de mise à jour télécharge le ZIP de la version, puis vérifie hash_file('sha256', …) par rapport au checksum_sha256 fourni par le publier les métadonnées à l’aide d’un hash_equals sécurisé. Si la somme de contrôle est manquante ou ne correspond pas, la mise à jour est refused — elle ne revient pas à application d'un package non vérifié.
• Service de mise à jour canonique. Les métadonnées de mise à jour et les téléchargements proviennent de publisher.webblocksui.com. Parce que la somme de contrôle est livrée avec le téléchargé par le même service, la somme de contrôle protège contre les fichiers corrompus ou artifacts falsifié, mais pas contre un service de mise à jour entièrement compromis.
• Les installations sont des consommateurs et non des éditeurs. Les sites installés récupèrent les mises à jour, mais ne doit pas être poussé vers le référentiel en amont. La publication se fait uniquement à partir du contrôle de maintenance avec un WEBBLOCKS_PUBLISHER_TOKEN.

Pour une défense en profondeur contre un service de mise à jour compromis — où la somme de contrôle voyage aux côtés de l'artefact - les versions peuvent être signées cryptographiquement . L'éditeur signe la somme de contrôle de la version avec une clé secrète Ed25519 et installe vérifier la signature par rapport à une clé publique épinglée (sodium_crypto_sign), donc un l'installation rejette toute version non signée par la vraie clé.

Pour l'activer :

1. Générer une seule fois une bi-clé, sur la machine de maintenance/éditeur : php artisan webblocks:updates:keygen.
2. Gardez le WEBBLOCKS_PUBLISHER_SIGNING_KEY imprimé (secret) privé — définissez-le uniquement là où vous publiez des versions. Ne le validez jamais et ne le configurez jamais sur une installation.
3. Épinglez la clé publique imprimée pour que les installations vérifient les versions signées : définissez WEBBLOCKS_UPDATE_PUBLIC_KEY, ou définissez ReleaseDefaults::UPDATE_PUBLIC_KEY de manière à la clé est livrée dans le code CMS (recommandé : une clé épinglée par un code ne peut pas être échangé via un .env compromis).
4. Publiez comme d'habitude ; l'éditeur signe automatiquement chaque version.

Rollout est sécurisé : même si aucune clé publique n'est épinglée, la vérification de la signature ne l'est pas appliquée (la vérification de la somme de contrôle s'applique toujours). Une fois qu'une clé publique est épinglée et les installations reçoivent ce code, chaque version future doit comporter un Ed25519 valide signature sur sa somme de contrôle, ou la mise à jour est refusée.

• Formulaires publicspartager un pipeline de protection local : preuve signée sous forme, pots de miel générés, timing, score de contenu/répétition, expéditeur et source saisis compteurs,/24ou/64la pression du réseau et les empreintes digitales apprises localement sur le site. Il ne fait aucune demande externe. Les compteurs de protection utilisent des hachages à clé ; mesures quotidiennes contiennent uniquement des décisions globales. VoirSoumission publique Protection.
• Formulaires de contactstocker les soumissions notées pour examen. Quarantaine et suppression du spam notification tout en restant séparé de l’historique de livraison des notifications. VoirFormulaires de contact et messages.
• Commentairespar défautpending; une décision de spam est conservée comme spam et jamais apparaît publiquement sans modération.
• HTML de confianceest limité au balisage de mise en page adjacent au wrapper et ne doit pas être utilisé pour injecter des scripts ; préférer les contrats de bloc natifs, que l'Interne L'API de contenu valide le brouillon en premier.
• Les téléchargements de médias sont limités à une liste blanche d'images, de vidéos et de documents. genres(contenu détecté, non approuvé par l'extension).Les téléchargements SVG sont désactivés par défaut, car un SVG peut contenir un script en ligne et le média est servi à partir de la même origine que l'administrateur. Activez-le uniquement sur les installations où chaque compte qui peut télécharger des médias est fiable, viaWEBBLOCKS_CMS_ALLOW_SVG_UPLOADS=true. La même liste verte régit les récupérations de médias distants côté serveur.
• La récupération multimédia à distance valide chaque cible de redirection et épingle le HTTP connexion à l’adresse IP publique qui a réussi la validation.Cela ferme le Course de recherche/connexion DNS utilisée par les attaques de rereliure DNS. Récupération à distance échoue la fermeture lorsque l’épinglage d’adresse cURL PHP n’est pas disponible.
• Les iframes d’applications intégrées gérées sont des bacs à sable d’origine opaque.Leur les réponses d’entrée appliquent des en-têtes CSP et référents restrictifs. CSP nomme le l'origine du site actuellement enregistré explicitement afin que les documents d'origine opaque puissent se charger leurs scripts, styles, médias et<base>URL sans accorder le accès iframe de même origine aux cookies du CMS, au stockage, à la page parent ou demandes de panel authentifiées.
• Les packages d’applications intégrées complètes restent isolés.Immuable, les fichiers de package versionnés sont servis via une route publique réservée aux applications avec CORS anonyme et en-têtes de ressources d'origine croisée, permettant une origine opaque jeux pour charger des images, de l'audio, des polices, des fichiers JSON et des fichiers régionaux sans accorderallow-same-origin. L'installation ZIP rejette les traversées, les chemins en double, fichiers de serveur exécutables et violations de nombre limité ou de taille étendue.

• Les vérifications de mise à jour peuvent envoyer à l'éditeur des données de télémétrie d'adoption préservant la confidentialité : uniquement product_key, installed_version, channel, un caractère aléatoire persistant localement installation_id et telemetry_schema_version. Aucun domaine, URL, administrateur e-mails, chemins, détails de la base de données, nombre d'utilisateurs, jetons ou environnement/configuration arbitraire les valeurs sont envoyées. Définissez WEBBLOCKS_TELEMETRY=false pour vous désinscrire ; vérifications des métadonnées continuer sans ID d'installation.
• Les rapports de visiteurs conservent les enregistrements de pages vues avec le chemin, l'heure et le référent normalisé. hôte, valeurs UTM, catégorie d’appareil et classification des robots. Complet basé sur le consentement le suivi peut également conserver une clé de session et une adresse IP HMAC ; ce sont des pseudonymes identifiants, pas une garantie d’anonymat. Nouveaux graphiques et modaux de détails de page n’introduisez aucun identifiant supplémentaire ni script de suivi public. Programmé la rétention remplace les détails expirés par des décomptes quotidiens de sites/locales et plus tard expire ces comptes. Voir OOpérations.

Rapport privé via les avis de sécurité GitHub ou le contact du responsable dans SÉCURITÉ.md. Nous visons à accuser réception des rapports dans les 5 entreprises jours et coordonnera avec vous un calendrier de divulgation.

CMS valident le candidat dans un processus PHP distinct avant l'activation en mode d'exécution normal. Une source invalide, des échecs de fournisseur/route, des sorties anticipées et des délais d'attente le rejettent ; une mise à jour rejetée conserve le package de travail. Les échecs de configuration de la base de données maintiennent le plugin désactivé et préservent ses données. Les échecs de source d'exécution ou de route mettent en quarantaine le plugin concerné et suppriment les routes partiellement enregistrées.

L'écran /webadmin/plugin-recovery et le chargement de la connexion sans source de plugin installée. CMS 1.94.2 applique l'accès administrateur du compte actif et l'autorisation Super admin, y compris les sessions existantes. La récupération peut désactiver le plugin défaillant ou restaurer le package précédent conservé uniquement lorsqu'aucune migration de base de données n'a été exécutée ; la restauration répète la validation de démarrage et republie les ressources précédentes. Les contrôles de connexion normaux et la protection CSRF restent en vigueur. Cela protège le chemin de récupération du plug-in géré, et non les fournisseurs d'hébergement arbitraires ou l'isolation PHP de l'exécutable. Voir Plugin System.

Les mises à jour d'installation nécessitent un jeton système à l'échelle de l'installation appartenant à un utilisateur actif ayant accès au système. system-updates.read et system-updates.run sont des opt-ins distincts ; ni les jetons personnels ni les jetons à l'échelle du site ne peuvent les utiliser. L'exécution nécessite l'approbation explicite de la version installée, de la version cible et de la somme de contrôle, avec un reçu d'idempotence durable pour les réponses incertaines. Voir les mises à jour .