Signaler une vulnérabilité
Écrivez à hello@html2wp.dev avec SECURITY dans l'objet. Ne signalez pas un problème de sécurité dans une issue GitHub publique. Une issue y est publique dès sa création : tous les utilisateurs du skill seraient exposés au problème avant qu'une mise à jour soit disponible.
Comment signaler
Joignez tout ce qu'il faut pour reproduire le problème : la version ou le commit, les étapes et le résultat que vous attendiez. Une preuve de concept (une démonstration qui fonctionne) aide et elle est la bienvenue. Elle n'est pas obligatoire pour faire un signalement.
Le point d'accès /v1/report décrit dans la documentation n'est pas le bon canal. Il reçoit les défauts du générateur, et une personne le lit en même temps que les rapports de bugs ordinaires.
À quoi vous attendre
- Un accusé de réception sous 3 jours ouvrés.
- Une évaluation du problème et un calendrier approximatif sous 10 jours ouvrés.
- Une mention dans les notes de version si vous le souhaitez, et aucune dans le cas contraire.
Si personne ne répond
Nous sommes une petite structure, pas une entreprise avec une équipe sécurité. Si un signalement reste sans réponse après ces délais, renvoyez-le : nous l'avons manqué, nous ne l'ignorons pas.
Ce qui est couvert
- Le skill et les scripts de
skills/html2wp/assets/scripts/, qui tournent sur votre propre machine. - Le service de conversion sur
api.html2wp.dev. - Le thème WordPress généré par le service, y compris le runtime PHP qu'il embarque et l'importeur de contenu.
Certains problèmes méritent un signalement même s'ils semblent mineurs. Par exemple, tout ce qui lit ou transmet des fichiers hors du dossier d'entrée et de l'espace de travail, tout ce qui permet à une conversion d'en voir une autre, ou tout élément d'un thème généré accessible sans authentification. Même chose pour une conversion terminée qui livre un thème qu'elle aurait dû refuser.
Ce qui n'est pas couvert
- Les failles d'une version de WordPress, PHP ou d'une extension que vous avez choisie, quand la correction consiste à la mettre à jour.
- Le WordPress jetable dans Docker que
test-env.shutilise pour la vérification locale. Son mot de passe admin est fixe exprès, il n'écoute que sur127.0.0.1et il est supprimé après chaque exécution. C'est un environnement de test, pas un site en production. - Les signalements indiquant qu'on peut retirer la vérification de licence du client. Oui, c'est possible : le client vous appartient et vous pouvez le modifier. Rien de ce qui touche à la sécurité ne dépend de cette vérification. Le service décide de vos droits, et les parties payantes sont précisément celles qu'il refuse de produire sans clé.
- Les attaques par déni de service volumétriques (inonder le service de requêtes) contre
api.html2wp.dev, et les résultats qui se résument à lancer un scanner contre lui.
Tester le service
Testez avec vos propres conversions et votre propre clé de licence. N'essayez pas d'accéder aux tâches, artefacts ou espaces de travail d'un autre compte. Si vous pensez avoir trouvé un moyen d'y parvenir, c'est exactement le signalement à nous envoyer, et décrire la méthode suffit. Inutile de le prouver sur les données de quelqu'un d'autre.
Ce qui quitte votre machine
La page sur les données et le README du plugin le décrivent, car une politique de sécurité n'est pas le bon endroit pour l'apprendre. En bref : le site compilé est envoyé au service, et la conversion s'exécute sur lui. Les verdicts des contrôles sont transmis à part et ne contiennent que des noms et des chiffres. L'étape 1 retire de l'envoi les fichiers qui ressemblent à des identifiants et liste chacun de ceux qu'elle a écartés. Si quelque chose passe à travers ce filtre, cela entre dans le périmètre.