Test d’OpenAI Daybreak Blue : une véritable faille de sécurité sur un site web
Mon test OpenAI Daybreak Blue a détecté un problème de sécurité sur mon propre site web en production, que j’ai pu reproduire dans un navigateur vierge : la page de connexion restait en HTTP au lieu de rediriger vers HTTPS. La page chargeait également 20 ressources propriétaires via la même connexion non chiffrée.
Ce résultat était utile pour une raison simple. Le modèle n’a pas eu besoin d’un exploit exotique pour produire une constatation pertinente. Il a identifié une défaillance élémentaire du transport, l’a classée et m’a fourni une affirmation concrète à vérifier. Un test de référence indépendant a détecté le même problème central.
Il s’agissait d’une évaluation autorisée et non destructive de Mixanalytic, un service dont je suis propriétaire. Je n’ai pas envoyé d’identifiants, ne me suis pas connecté, n’ai pas exploité le site, n’ai pas modifié de données et n’ai pas tenté de maintenir une persistance.
Pourquoi tester Daybreak Blue sur un vrai site web
Les démonstrations de modèles de sécurité utilisent souvent des exemples de code préparés ou des laboratoires connus comme vulnérables. Ces tests sont contrôlés, mais ils ne montrent pas comment le modèle gère un système de production ordinaire avec un contexte incomplet.
Je voulais effectuer un test plus ciblé, avec une condition de réussite claire : le modèle pouvait-il inspecter la surface publique d’un site dont je suis propriétaire, détecter un problème reproductible et distinguer les preuves des spéculations ?
Je voulais également comparer son résultat à une référence indépendante. J’ai testé d’autres systèmes d’IA avec une approche similaire fondée sur les preuves dans mon test de sécurité d’un chatbot IA→, où le résultat utile était une modification technique vérifiée plutôt qu’une histoire d’attaque spectaculaire.
Quel modèle ai-je réellement exécuté ?
La première évaluation a été exécutée dans un worker Codex séparé, affecté à l’identifiant de modèle `gpt-daybreak-blue-latest`. La documentation d’OpenAI appelle l’offre approuvée GPT-Daybreak-Blue.
Cette distinction est importante. Modifier le modèle sélectionné pour une conversation ultérieure ne transforme pas rétroactivement une exécution précédente en test Daybreak. L’exécution qui réalise l’évaluation doit utiliser le modèle Daybreak approuvé et la surface produit correspondante.
OpenAI décrit Daybreak Blue comme le point de départ pour la plupart des travaux défensifs autorisés, notamment la découverte de vulnérabilités, la revue de code sécurisé, la modélisation des menaces, l’ingénierie de détection, la réponse aux incidents et la validation des correctifs. L’entreprise recommande également des environnements contrôlés, des permissions minimales, un périmètre défini et une revue humaine pour les actions sensibles (Models and Trusted Access).
Configuration et périmètre du test OpenAI Daybreak Blue
J’ai autorisé le modèle à inspecter Mixanalytic et les fichiers du projet local. J’ai limité les vérifications externes à des opérations non destructives :
Le modèle n’était pas autorisé à envoyer le formulaire de connexion, tester de vrais identifiants, créer des comptes, téléverser des charges utiles, exploiter une faiblesse suspectée ou modifier la production.
Cette limite a facilité l’interprétation du résultat. Chaque constatation devait provenir d’un comportement public ou de preuves en lecture seule issues du code source.
Constatation principale : une page de connexion restait en HTTP
La vérification en boîte noire a montré que la racine du site et la route de connexion renvoyaient toutes deux `200 OK` via HTTP. Aucune des deux réponses ne redirigeait le navigateur vers HTTPS.
J’ai ensuite ouvert la page de connexion dans un contexte Chromium vierge. Le navigateur est resté sur une URL `http://` tout en affichant des champs de nom d’utilisateur et de mot de passe. Pendant le chargement de cette page, 20 requêtes propriétaires JavaScript, CSS, image et document ont également utilisé HTTP.
| Vérification | Résultat observé |
|---|---|
| --- | --- |
| Redirection HTTP | Aucune redirection vers HTTPS sur la racine ou la page de connexion testée |
| Navigateur vierge | Chromium est resté sur la page de connexion HTTP |
| Ressources propriétaires | 20 requêtes ont été chargées via HTTP pendant cette exécution du navigateur |
| Cookie de session anonyme | `Secure=false`, `HttpOnly=true`, `SameSite=Lax` |
Le résultat concernant le cookie doit être contextualisé. `HttpOnly` et `SameSite=Lax` étaient des attributs positifs, mais l’absence du flag `Secure` permettait au cookie de session anonyme de circuler via une connexion non chiffrée.
Après le test dans le navigateur, j’ai classé le problème de transport comme présentant un risque élevé. Un attaquant positionné sur le chemin réseau pourrait observer ou modifier le trafic HTTP. Si un utilisateur envoyait ses identifiants sur cette page, la connexion non chiffrée pourrait les exposer. Je n’ai trouvé aucune preuve indiquant que des identifiants avaient été volés et je n’en ai envoyé aucun pendant le test.
La vérification dans le navigateur a modifié l’évaluation de la gravité
La référence indépendante initiale avait classé le comportement HTTP comme présentant une gravité moyenne. Cette évaluation a changé après que la vérification à l’exécution a montré qu’un véritable formulaire de mot de passe restait en HTTP, avec ses ressources associées également chargées via HTTP.
Cette évolution en dit davantage sur la méthode de test que sur les modèles. L’inspection des en-têtes a identifié le problème de configuration. Les preuves issues du navigateur ont établi la manière dont un visiteur y serait confronté. Ces éléments supplémentaires ont rendu l’impact suffisamment concret pour justifier une priorité plus élevée.
Daybreak Blue est arrivé à la même conclusion centrale. Les deux exécutions ont bénéficié de la même règle : une constatation doit inclure une observation reproductible, une déclaration d’impact limitée et une liste claire des actions qui n’ont pas été effectuées.
Ce que les vérifications secondaires ont révélé
L’évaluation a également produit plusieurs résultats de priorité moindre.
Les versions TLS modernes fonctionnaient
L’hôte testé rejetait TLS 1.0 et 1.1 tout en acceptant TLS 1.2 et 1.3. Il s’agit d’un résultat positif pour le point de terminaison HTTPS. Cela ne compense pas le fait que l’expérience de connexion puisse rester en HTTP.
La Content Security Policy autorisait le code inline
La Content Security Policy observée incluait `'unsafe-inline'` pour les scripts et les styles. J’ai considéré cela comme une lacune de durcissement, et non comme la preuve d’une vulnérabilité cross-site scripting. La suppression des autorisations inline nécessite généralement des modifications de l’application et des tests de non-régression ; elle doit donc intervenir après la correction du problème de transport.
Le site ne possédait pas de `security.txt`
Le chemin standard `/.well-known/security.txt` renvoyait `404`. Je l’ai classé comme informatif. Un fichier de contact de sécurité fournit aux chercheurs une voie claire pour signaler les problèmes, mais son absence ne crée pas une faille exploitable.
Le preflight CORS testé n’autorisait pas l’origine étrangère
Une requête preflight provenant d’une origine sans lien n’a pas reçu l’autorisation d’accéder à la route publique testée. Il s’agit d’un résultat négatif utile, limité au point de terminaison et au preflight que j’ai vérifiés. Ce n’est pas un audit CORS couvrant l’ensemble du site.
Daybreak Blue a-t-il surpassé la référence ?
Ce test ne permet pas d’établir un classement général des modèles. Daybreak Blue et la référence indépendante ont tous deux détecté le problème de transport. La gravité attribuée par la référence s’est améliorée lorsque j’ai ajouté les preuves issues du navigateur.
Daybreak Blue s’est montré utile parce qu’il est resté concentré sur une tâche défensive autorisée et a produit une constatation que je pouvais vérifier. Un seul site, un seul périmètre et une seule date de test ne permettent pas d’établir qu’il surpassera un autre modèle pour la revue de code source, la réponse aux incidents, l’analyse de logiciels malveillants ou les tests d’intrusion de plus grande ampleur.
Un benchmark plus solide répéterait les mêmes cas de test dissimulés sur plusieurs applications dont les testeurs sont propriétaires, fournirait à chaque modèle les mêmes outils et le même budget de temps, puis évaluerait la reproductibilité, les faux positifs, les constatations manquées, l’étalonnage de la gravité et la qualité de la remédiation.
J’utilise cette méthode d’évaluation plus large dans Comment évaluer les modèles d’IA pour le travail réel→. Cette exécution Daybreak constitue un rapport de terrain, et non un benchmark complet.
Comment obtenir OpenAI Daybreak Blue ?
L’accès à Daybreak nécessite une approbation via le programme Trusted Access for Cyber d’OpenAI. Les particuliers peuvent déposer une demande via la demande individuelle Trusted Access, tandis que les organisations peuvent utiliser le formulaire de demande pour entreprises.
L’approbation est liée à l’identité ou au service approuvé, à l’espace de travail ou à l’organisation et au projet API, au modèle et à la surface produit. Effectuer la vérification d’identité ou envoyer le formulaire ne garantit pas l’accès. Daybreak Red nécessite également une approbation distincte ; l’accès à Blue ne l’inclut pas automatiquement.
Le workflow Daybreak plus large d’OpenAI relie l’investigation, la revue du dépôt, les preuves, les correctifs proposés et la vérification humaine. Ses propres recommandations maintiennent la responsabilité de l’ingénieur pour les modifications ayant des conséquences (Scaling cyber defenders with Daybreak).
Sources et relevé du test
J’ai effectué les vérifications autorisées le 30 août 2026. Les observations relatives au navigateur, aux en-têtes, aux cookies, à TLS, à CSP, à `security.txt` et à CORS présentées dans cet article proviennent de ce relevé de test.
Les affirmations concernant le modèle et l’accès proviennent de deux sources primaires d’OpenAI :
Selon les recommandations d’OpenAI concernant l’accès, l’approbation reste spécifique à l’identité, à l’espace de travail ou au projet API, au modèle et à la surface produit. Les résultats de mon test ne s’étendent pas au-delà du périmètre Mixanalytic décrit ci-dessus.
Ce que je corrigerais et retesterais ensuite
La constatation concernant le transport suit un ordre de priorité court :
Le retest devrait échouer si une page de connexion, une action de formulaire, une ressource propriétaire ou un cookie de session repasse en HTTP. Je relancerais également les évaluations Daybreak et de référence sur la version corrigée afin de vérifier qu’elles reconnaissent la remédiation et évitent de signaler à nouveau le problème.
Le premier test a produit un résultat utile sans franchir la limite d’autorisation. Daybreak Blue a détecté une véritable faille. Des preuves indépendantes issues du navigateur ont montré pourquoi elle méritait de l’attention. La prochaine affirmation crédible n’est pas que l’outil a fonctionné une fois ; c’est que le correctif résiste au même test.
---