La protection DDoS d'un portail public commence par une distinction : les informations accessibles à tous d'un côté, les actions et dossiers propres à une personne de l'autre. Utilisez un réseau de diffusion de contenu, ou CDN, pour servir à moindre coût les réponses dont le caractère public est établi. Excluez du stockage partagé les réponses privées ou contenant des éléments d'authentification, puis vérifiez que les candidats et les chercheurs en sécurité peuvent toujours envoyer leurs informations lorsque le filtrage est actif. Une page carrière qui s'affiche ne suffit pas à faire fonctionner le recrutement. Le candidat doit encore ouvrir un lien privé, joindre un fichier et recevoir un accusé de réception fidèle au résultat. Le chercheur en sécurité doit trouver les consignes de signalement, puis transmettre un rapport confidentiel. Si la protection de la première page bloque ces étapes, les personnes que vous vouliez accueillir restent à la porte. Nous proposons ici une revue technique pour une petite équipe. Elle associe les enseignements d'un incident récent à un exercice pratique, à adapter à votre application. Elle ne constitue ni une certification de résistance aux attaques ni une promesse de disponibilité pour une configuration d'hébergement donnée. ## Qu'a appris Read the Docs des requêtes non mises en cache ? **Des requêtes apparemment anodines peuvent consommer de précieuses ressources applicatives.** Commencez par les chemins qui atteignent le serveur d'origine, là où s'exécute l'application. Ne supposez pas que les pages populaires concentrent tout le travail. Read the Docs a publié son [compte rendu d'incident](https://about.readthedocs.com/blog/2026/09/2026-ddos-attack/) le 8 septembre 2026. L'attaque s'est déroulée entre la mi-juin et la fin juin et a duré près de dix jours. Le prestataire rapporte un pic supérieur à 5,5 millions de requêtes par minute, des signatures de requêtes changeantes et un trafic visant les réponses non mises en cache. Les redirections temporaires atteignaient initialement son serveur applicatif Python ; l'équipe les a déplacées vers la périphérie du réseau. Des requêtes vers des chemins inexistants et toujours différents provoquaient aussi des accès coûteux à l'origine. L'équipe a utilisé des vérifications ciblées, car les imposer à tous les lecteurs aurait perturbé les intégrations. Ces observations concernent Read the Docs, pas Kit ni votre entreprise. Pour votre équipe, la question utile est plus précise : quelles requêtes apparemment peu coûteuses sollicitent encore l'application ? ### Partez d'un portail fictif Pour cet exercice, imaginez un petit éditeur de logiciels doté d'un site carrière public et d'un programme de divulgation des vulnérabilités. Une personne en recherche d'emploi peut consulter une fiche de poste sans s'identifier. Un candidat peut accéder à sa candidature par un lien privé. Un chercheur peut lire la politique de sécurité, puis transmettre des informations qui doivent rester confidentielles. Donnez une feuille vierge au recruteur, au responsable sécurité et à l'ingénieur. Demandez à chacun de dessiner son parcours, du point d'entrée à l'accusé de réception. Incluez les anciennes adresses enregistrées dans les favoris et les liens des e-mails déjà envoyés. Il s'agit d'un atelier proposé, pas du récit d'un incident client. Repérez ensuite les étapes qui nécessitent le serveur applicatif. Une redirection peut déclencher une recherche en base de données. Une page introuvable peut afficher une présentation personnalisée. Un formulaire peut contenir un jeton. L'objectif est de découvrir ces dépendances avant que l'urgence ne pousse quelqu'un à modifier les règles de cache à grande échelle. Pour les questions de responsabilité qui dépassent cet exercice, notre article sur [l'auto-hébergement et les responsabilités de l'équipe](/blog/self-hosting-startup-staffing-ownership) aide à déterminer qui maintient le service. Ici, concentrez la revue sur le trafic entrant et le contenu de chaque réponse. ## Comment déterminer quelles réponses du portail sont réellement publiques ? **Classez la réponse entière, avec ses en-têtes et ses variantes.** Une adresse qui semble publique ne prouve pas que chaque visiteur reçoit le même contenu ni qu'un cache partagé peut le réutiliser sans risque. La [norme de mise en cache HTTP, RFC 9111](https://www.rfc-editor.org/rfc/rfc9111.html), distingue trois directives souvent confondues. `no-store` demande aux caches de ne pas stocker la réponse. `private` interdit son stockage dans un cache partagé. `no-cache` autorise le stockage, mais exige une validation avant réutilisation. L'en-tête de requête `Authorization` ne constitue pas non plus une protection absolue : des directives de réponse explicites peuvent autoriser une réutilisation partagée. Copier le nom d'un en-tête connu ne suffit donc pas. ### Dressez l'inventaire des réponses Utilisez le tableau suivant comme support de revue. Il facilite l'analyse technique, sans constituer une norme de conformité. Pour chaque ligne, désignez une personne chargée de réunir les éléments et une autre chargée de vérifier la conclusion. | Élément | Question à résoudre | Éléments à recueillir | | --- | --- | --- | | Informations publiques sur un poste | La réponse entière peut-elle être présentée à tous les lecteurs concernés ? | Réponses anonymes et authentifiées, variantes par compte client et par langue, paramètres de requête significatifs | | Redirection ou page introuvable | La destination ou le corps de la réponse peuvent-ils dépendre de l'identité ? | En-têtes, destination, corps, clé de cache et comportement lié aux droits d'accès | | Page privée d'un candidat | Le lien ou la réponse donnent-ils un accès ou révèlent-ils des données personnelles ? | Gestion des jetons, politique de stockage, comportement des sessions et isolation entre utilisateurs de test | | Envoi d'une candidature ou d'un rapport | Qu'est-ce qui prouve que l'action a été acceptée ? | Résultat de la requête, enregistrement persistant, état d'échec et accusé de réception | | API ou envoi de fichier | Le client sait-il traiter la réponse du dispositif de protection ? | Format attendu, type de contenu reçu, état d'authentification et gestion des échecs | Examinez des exemples réels avec des comptes de test et des données fictives. Comparez deux comptes clients, deux langues, un visiteur connecté et un visiteur anonyme, lorsque ces états existent. Ajoutez les états effectivement pris en charge par le produit : cette liste n'est pas exhaustive. Observez les détails de la page. Une fiche de poste générique peut côtoyer le nom d'un candidat ou un jeton de formulaire. Le caractère public du texte principal ne rend pas la réponse complète partageable. Étudiez la séparation entre données publiques et interface privée, plutôt que de chercher à déclarer toute la page inoffensive. ### Conservez les distinctions qui changent le sens Une clé de cache détermine quelles requêtes sont considérées comme demandant la même réponse. La [documentation Cloudflare sur les clés de cache](https://developers.cloudflare.com/cache/how-to/cache-keys/) explique qu'ignorer les paramètres d'URL peut regrouper des requêtes qui diffèrent par ces paramètres. C'est une option à évaluer, pas un raccourci à activer sur tout le portail. Pour l'exercice, notez ce que représente chaque composant de la clé. L'hôte peut identifier le client. La langue peut modifier les consignes. Un filtre peut sélectionner un autre poste. Un élément d'authentification peut changer les personnes autorisées à voir la réponse. Si vous ne pouvez pas expliquer pourquoi supprimer une distinction est sans risque, conservez-la pendant l'analyse. Gardez une trace de la comparaison en retirant les données sensibles. Consignez les routes examinées, les états testés et les inconnues restantes. Une capture d'écran seule ne démontre pas une politique de cache. Ne copiez pas de vrais liens candidats ni le contenu de rapports confidentiels dans le document de revue. ## Comment protéger les redirections et les pages introuvables ? **Examinez les redirections et les réponses d'erreur comme des ressources distinctes, avec leurs propres règles de confidentialité et de fraîcheur.** Le code de statut indique ce qui s'est passé, pas si la réponse peut être partagée sans risque. Pour l'entreprise fictive, commencez par une ancienne URL du site carrière. Si sa destination est fixe et publique, demandez-vous si la redirection peut être traitée avant le serveur applicatif. Essayez ensuite un ancien lien candidat. Sa destination peut dépendre de l'authentification ou de l'état de la candidature : il exige donc une décision distincte, même si les deux réponses utilisent le même code de redirection. Appliquez la même prudence aux pages introuvables. Mettre brièvement en cache une réponse 404 publique peut éviter de refaire le travail pour une même ressource absente. Cela ne résout pas un flux illimité de nouveaux chemins inexistants : chacun peut provoquer un nouvel accès à l'origine. Une réponse qui dissimule une ressource privée à un visiteur non autorisé nécessite aussi une politique différente de celle d'une véritable page publique introuvable. ### Désignez un responsable de la fraîcheur des informations Le cache pose une question produit : combien de temps la réponse d'hier peut-elle rester visible ? Fixez cette tolérance pour chaque ressource publique, plutôt que de retenir une durée commode pour tout le site. Pour une offre d'emploi, demandez au recruteur quelles seraient les conséquences d'afficher comme ouvert un poste clôturé. Pour une politique de sécurité, demandez au responsable sécurité quelles modifications doivent être publiées sans attendre. Un changement d'adresse de contact et une simple retouche rédactionnelle peuvent justifier des traitements différents. Ce sont des décisions à prendre pendant la revue, pas des recommandations universelles de durée d'expiration. La [documentation Cloudflare sur le contrôle du cache](https://developers.cloudflare.com/cache/concepts/cache-control/) décrit les interactions entre les en-têtes de l'origine, les règles qui les remplacent, les cookies et la diffusion de contenu périmé. Testez la réponse réellement servie par le CDN déployé. Une déclaration d'en-tête dans le code applicatif ne suffit pas à établir ce que reçoivent les visiteurs. Utilisez un poste fictif pour simuler un changement d'état. Consultez-le par la route publique, clôturez-le, puis vérifiez à quel moment sa présentation publique change. Tentez ensuite l'action concernée depuis l'ancienne page. L'application doit décider d'accepter ou non l'action à partir de l'état actuel, sans considérer une description en cache comme une autorisation de poursuivre. ### Maintenez les consignes de signalement à jour La politique de signalement nécessite sa propre vérification de fraîcheur. [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html) définit `security.txt`, notamment son champ `Expires` et les contacts de signalement. Les informations expirées ne doivent pas être utilisées. Les contacts peuvent proposer un site web, un e-mail ou un téléphone, mais ce fichier concerne le signalement des vulnérabilités, pas une permanence générale de gestion des incidents. Pendant l'exercice, empruntez chaque voie de signalement publiée avec un contenu de test inoffensif, dans le cadre d'une procédure de test approuvée. Confirmez qui le reçoit et comment l'expéditeur connaît le résultat. Une politique qui s'affiche rapidement n'est utile que si ses consignes mènent à un canal de contact maintenu. Si vous mettez encore ce processus en place, commencez par le [guide du programme de divulgation des vulnérabilités](/blog/how-to-set-up-vulnerability-disclosure-program). Séparez les consignes publiques du rapport privé qu'elles permettent de transmettre. ## Comment éviter que les vérifications de trafic bloquent les envois ? **Adaptez les règles de protection aux clients et aux actions concernés.** Un navigateur qui affiche une page et une intégration qui envoie une requête structurée peuvent réagir très différemment à la même vérification. La [documentation Cloudflare sur les pages de vérification](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/) précise qu'elles renvoient du HTML. Un client qui attend du JSON peut donc recevoir une réponse inexploitable. Une validation préalable dans le navigateur peut convenir à certains parcours web, mais elle ne résout pas tous les cas des API ou des webhooks. Pour le test proposé, listez les requêtes effectuées après l'ouverture de la page. Incluez l'envoi du formulaire, les fichiers, l'authentification et tout appel de retour utilisé par l'intégration. Notez le format de réponse attendu pour chaque requête. Exécutez ensuite le parcours avec la véritable règle de protection activée dans un environnement de test adapté. Ne vous arrêtez pas à la réussite de la première vérification dans le navigateur. Envoyez le formulaire, suivez le lien suivant et vérifiez le résultat enregistré. Si un envoi de fichier échoue, examinez le format de réponse avant d'incriminer le fichier. Si un appel de retour échoue, examinez-le comme un client distinct : la réussite du parcours navigateur ne le couvre pas. ### Examinez les faux positifs avec les personnes concernées Demandez au recruteur et au responsable sécurité ce que verrait un utilisateur légitime bloqué. Pourrait-il savoir si quelque chose a été reçu ? Saurait-il quoi faire ensuite ? Une nouvelle tentative risquerait-elle de créer un doute sur l'existence d'un envoi précédent ? Utilisez des envois fictifs pour examiner ces états sans surprendre les équipes avec de nouveaux éléments dans les files de production. Convenez d'un autre moyen de contact adapté à l'organisation et n'exposez pas de détails confidentiels sur les pages publiques d'état du service. N'affichez pas un envoi réussi sur une page de secours si l'action sous-jacente n'a pas été acceptée. Les limites de fréquence méritent la même attention. Cloudflare documente des [options de limitation tenant compte du NAT](https://developers.cloudflare.com/waf/rate-limiting-rules/parameters/), avec des réserves liées aux cookies ; les fonctionnalités dépendent aussi de l'abonnement. Sa [documentation sur la fréquence des requêtes](https://developers.cloudflare.com/waf/rate-limiting-rules/request-rate/) précise que les compteurs ne sont pas partagés globalement entre tous les centres de données. Une règle en périphérie du réseau ne constitue donc pas un quota transactionnel global strict. Pour cette revue, ne choisissez pas une limite chiffrée au seul motif qu'une autre entreprise l'utilise. Observez le parcours légitime et déterminez ce que signifie la répétition d'une action. Une rafale de consultations, l'envoi d'un fichier volumineux et des soumissions répétées de formulaire n'ont pas les mêmes conséquences. Notez le but de la règle et les observations qui vous conduiraient à la modifier. ## Comment tester le parcours complet des candidats et des chercheurs ? **Testez la réussite, le refus et la reprise en passant par les protections déployées.** La disponibilité suppose qu'une personne autorisée puisse accomplir sa tâche et comprendre le résultat. Une réponse positive de la page d'accueil à une sonde ne suffit pas. Utilisez cet exercice de validation avant une modification étendue des règles de cache ou de filtrage. Employez des données fictives, désignez les responsables et définissez clairement quand revenir en arrière. Cette revue fonctionnelle ne remplace pas un test de charge planifié séparément. 1. **Lisez les informations publiques.** Ouvrez le poste ou la politique par son véritable point d'entrée. Vérifiez le compte client, la langue, l'état actuel et les coordonnées. Recommencez avec un ancien lien public lorsqu'il existe. 2. **Entrez dans le parcours privé.** Utilisez des identités de test distinctes. Vérifiez que chacun ne voit que ses informations et qu'une requête anonyme ne récupère pas la réponse d'un visiteur précédent. 3. **Effectuez l'action.** Envoyez la candidature ou le rapport fictif, avec un fichier inoffensif si cette possibilité existe. Vérifiez l'enregistrement accepté dans l'interface interne appropriée. 4. **Provoquez un échec ordinaire.** Saisissez une valeur invalide dans un champ ou utilisez un lien de test expiré. Vérifiez que l'explication est utile et ne révèle aucune information sur une autre personne. 5. **Modifiez l'état public.** Clôturez le poste fictif ou révisez la politique de test. Vérifiez la fraîcheur des données et répétez l'action concernée depuis une ancienne page. 6. **Examinez chaque client.** Vérifiez séparément les requêtes du navigateur et les intégrations. Notez les types de contenu, le comportement des vérifications et la possibilité de reprendre après un échec. Gardez l'exercice accessible aux personnes qui naviguent sans souris. Notre [liste de contrôle du portail candidat accessible au clavier](/blog/keyboard-accessible-candidate-portal-checklist) couvre cette partie du parcours. Un écran de vérification ou de reprise ajouté pendant un incident mérite autant d'attention que le formulaire d'origine. ### Définissez les conditions de mise en service Avant les tests, convenez des éléments nécessaires pour autoriser le changement. Pour l'équipe fictive, les critères proposés sont simples : les informations publiques restent exactes, les réponses privées restent isolées, les envois prévus aboutissent et les actions refusées donnent lieu à un message fidèle au résultat. Attribuez chaque échec à un responsable au lieu de tout ramener à un pourcentage de disponibilité. Conservez une trace concise de la règle modifiée, des états testés, des résultats observés et des étapes de retour en arrière. Comparez le comportement du CDN à celui de l'application lorsque vous disposez de cette visibilité. Si une lacune subsiste, décrivez-la précisément : un appel de retour non testé n'est pas la même chose qu'un échec d'envoi de candidature. Répétez les vérifications concernées lorsque vous modifiez la règle ou le parcours. Tester sans cesse une page d'accueil inchangée apporte peu si une nouvelle route d'envoi de fichier reste sans contrôle. Le périmètre du changement doit déterminer celui de la revue. ## Où Kit distingue-t-il les informations publiques des échanges privés ? **Un même produit peut réunir des informations publiques et des processus confidentiels qui exigent des traitements différents.** Examinez la réponse réelle avant toute décision de cache, même si le contrôleur ou la route porte le mot « public » dans son nom. Dans le code de Kit examiné le 10 septembre, la réponse JSON d'un poste qui accepte les candidatures déclare une durée de cache public de cinq minutes. La réponse `security.txt` d'un programme de sécurité actif déclare une durée publique d'une heure. Ce sont des déclarations applicatives précises, pas des mesures du comportement du CDN déployé ni de la disponibilité des envois. Le parcours candidat est différent. Un jeton de lien magique permet de retrouver le candidat, ses candidatures, ses entretiens, ses offres et les états associés. Le traitement HTML d'une offre d'emploi publique peut aussi retrouver une autorisation candidat dans la session. Ces éléments interdisent de traiter toutes les pages accessibles anonymement comme des contenus publics interchangeables. Kit comporte aussi des limites de fréquence des envois dans le middleware de l’application. Ce n'est qu'une couche du traitement des requêtes, pas une preuve que le trafic en amont ne peut pas épuiser les ressources. Cet article ne présente ni audit des réponses de production, ni test de charge, ni garantie contre les DDoS. Les protections liées au référent et à l'indexation ne prouvent pas davantage qu'une réponse transmet `Cache-Control: no-store`. Appliquez le même inventaire des réponses à votre portail. Réduisez le coût de diffusion des informations dont le caractère public est établi, définissez une politique distincte pour les parcours privés et vérifiez que l’accusé de réception renseigne correctement la personne qui attend une réponse. > [!CTA] > **Examinez les parcours dont votre équipe dépend.** Découvrez comment Kit réunit le recrutement et le signalement de vulnérabilités dans un même produit. > > [Démarrez votre essai gratuit](/users/sign_up)