Confiance

Les détails techniques derrière notre page sécurité, pour les équipes informatiques, les développeurs et toute personne qui fait ses vérifications préalables. Chaque élément ici est en place aujourd’hui, sauf mention contraire.

Dernière mise à jour : 12 octobre 2026

Hébergement et localisation des données

• Serveurs : à Londres, au Royaume-Uni. Ils font fonctionner l’API, le connecteur IA, le tableau de bord et la diffusion des sites publiés, et hébergent la base de données des comptes.
• Fichiers de site : conservés dans un stockage d’objets durable dans l’UE. Ce stockage fait foi ; les serveurs de Londres n’en gardent qu’un cache.
• Sauvegardes de la base de données : dans le même stockage de l’UE, dans un bucket séparé avec des clés séparées.
• Edge : un réseau mondial diffuse et met en cache les pages publiques près des visiteurs.
• Hors du Royaume-Uni/UE : nos services de connexion, de paiement et d’e-mail traitent certaines données aux États-Unis. Les entreprises sont nommées sur notre page des sous-traitants.

Réseau et transport

• Chaque nom d’hôte sur pagelemon.com et pagelemon.dev est servi par un réseau edge mondial qui assure l’atténuation des attaques DDoS et le TLS en périphérie. Le HTTP simple est redirigé vers HTTPS.
• Verrouillage de l’origine : nos serveurs rejettent les requêtes web qui ne proviennent pas des plages d’IP publiées du réseau edge, de sorte que l’origine ne peut pas être jointe directement pour le contourner.
• Le trajet entre le réseau edge et nos serveurs est lui aussi chiffré, avec un certificat d’origine.
• HSTS (6 mois, sous-domaines compris) sur pagelemon.com et sur les hôtes de l’appli, de l’API et du connecteur. .dev est un domaine de premier niveau en préchargement HSTS, donc les navigateurs n’accèdent aux sites des utilisateurs qu’en HTTPS.

Isolation des sites et en-têtes

• Domaines enregistrables séparés. Les sites des utilisateurs sont servis depuis *.pagelemon.dev ; les comptes, le tableau de bord et l’API sont sur pagelemon.com. Les cookies et le stockage d’un site utilisateur ne peuvent jamais atteindre la session du compte.
• Content Security Policy stricte sur le site vitrine (scripts uniquement depuis notre propre origine, pas d’intégration en cadre), et X-Frame-Options: DENY sur le tableau de bord.
• Les sites des utilisateurs sont servis avec X-Content-Type-Options: nosniff, une politique de referrer stricte et Cross-Origin-Opener-Policy: same-origin-allow-popups. Nous n’y injectons aucun script, traceur ni cookie ; le badge du forfait gratuit est en HTML et CSS simples.
• Les sites protégés par mot de passe et réservés aux membres ne sont jamais stockés dans des caches partagés (Cache-Control: private, no-store) et ne sont jamais indexés.
• Quand un site est retiré pour abus, il est servi avec Clear-Site-Data, pour que le navigateur du visiteur efface son cache, son stockage et ses service workers.
• Les mots de passe des sites sont hachés avec scrypt (sel aléatoire par site). Le cookie de déverrouillage du visiteur est signé en HMAC, HttpOnly et Secure, et changer le mot de passe invalide tous les anciens cookies. Les tentatives de déverrouillage échouées sont limitées en débit.

Durcissement des serveurs

• SSH uniquement par clés personnelles nominatives : les connexions par mot de passe et la connexion root sont désactivées. Un pare-feu sur l’hôte n’autorise que le trafic SSH et web.
• Chaque service tourne dans son propre conteneur avec un utilisateur non root, un système de fichiers en lecture seule, toutes les capacités Linux retirées, l’élévation de privilèges bloquée, et ses propres limites de mémoire et de processus, pour qu’une panne ne puisse pas priver les autres de ressources.
• Les secrets sont séparés par service : l’application ne voit pas les clés de sauvegarde, et la tâche de sauvegarde ne voit pas les clés de connexion, de paiement ou d’e-mail.
• Les clés de stockage sont limitées à un seul bucket et verrouillées sur l’adresse IP de notre serveur. Les clés d’e-mail peuvent seulement envoyer.
• Chaque version logicielle passe la suite de tests automatisés avant d’être livrée. Les images de version sont construites hors du serveur, et la précédente est conservée pour un retour arrière en une commande.
• Les actions de l’équipe dans les outils d’administration sont consignées dans un journal d’audit, et les actions sensibles nécessitent une connexion datant de moins de 10 minutes.

Sauvegardes, versions et récupération

• Sauvegarde continue de la base de données : les modifications sont envoyées en continu vers le stockage de l’UE en quelques secondes, avec restauration à un instant donné.
• Restaurations testées : un exercice de restauration reconstruit la base de données à partir de la sauvegarde et lance une vérification d’intégrité. Dernière exécution le 12 octobre 2026 : réussie.
• Verrou de suppression : les fichiers récents des sites et les sauvegardes de la base de données sont sous verrou de bucket, ils ne peuvent donc pas être supprimés, même avec les propres clés de notre serveur.
• Versions immuables : chaque publication est une nouvelle version qui ne change plus ; la mise en ligne consiste à déplacer un pointeur, et le retour en arrière se fait en un seul appel. Chaque version est conservée 30 jours, puis la dernière de chaque semaine, de 7 jours (Gratuit) à 2 ans (Company), selon le forfait.
• Aucune modification perdue : chaque publication indique la version dont elle part ; si quelqu’un d’autre a publié entre-temps, elle est refusée avec un conflit clair au lieu d’écraser son travail.
• Diffusion de copies périmées : les fichiers publics publiés peuvent être servis depuis le cache edge pendant 7 jours maximum si notre origine est hors service ou en erreur. Les sites privés ne sont jamais mis en cache.
• Surveillance : un contrôle externe sur un serveur distinct teste l’API, le tableau de bord et le connecteur toutes les 5 minutes et envoie une alerte par e-mail en cas d’échec. L’application alerte en cas de fichiers stockés manquants.

Connexion et sécurité des comptes

La connexion au compte est gérée par un service de connexion spécialisé. Aujourd’hui :

• Méthodes de connexion : code à usage unique par e-mail, Google ou mot de passe. Les adresses e-mail sont vérifiées par un code.
• Mots de passe : au moins 15 caractères, comparés aux mots de passe connus pour avoir fuité à l’inscription et à nouveau à la connexion.
• Blocage du compte après plusieurs tentatives échouées.
• Nous ne recevons qu’un jeton de session signé, vérifié à chaque requête par rapport à nos propres domaines. Nous ne voyons ni ne stockons jamais les mots de passe des comptes.

Les sites réservés aux membres connectent les visiteurs avec leur adresse e-mail sur app.pagelemon.com, puis transmettent au site un code à usage unique pour son propre cookie. Aucun script de connexion ne s’exécute sur le site lui-même. Les paiements par carte sont gérés par notre prestataire de paiement ; les numéros de carte ne passent jamais par nos serveurs.

Connexions d’IA et jetons API

• Les applis d’IA se connectent via OAuth avec PKCE (S256) et des indicateurs de ressource. Les jetons d’accès durent 1 heure ; les jetons d’actualisation changent à chaque utilisation, les connexions prennent fin après 30 jours d’inactivité, et réutiliser un ancien code ou jeton d’actualisation révoque toute la connexion.
• Les jetons API et les jetons de site ne sont stockés que sous forme de hachages SHA-256. Chaque jeton a des portées (deploy ou deploy + manage), peut être limité à un site, peut expirer et peut être révoqué à tout moment.
• Validation humaine : inviter des personnes, retirer le mot de passe d’un site, renommer et transférer un site renvoient un lien de validation que le titulaire du compte doit ouvrir et confirmer en étant connecté. Un jeton seul ne peut pas le faire. Les actions destructrices se font en deux étapes.
• Chaque nouveau jeton ou nouvelle connexion d’IA apparaît comme un avis dans les notifications du propriétaire du compte, dans l’app, et lui est généralement aussi envoyé par e-mail.

Vérification des envois

• Protection contre les fuites : chaque fichier texte est analysé pour détecter les types connus de clés secrètes et de clés privées. Une correspondance bloque tout l’envoi et signale le fichier et la ligne.
• Les dossiers de gestion de versions, les fichiers d’environnement, les dossiers de dépendances, les source maps et les fichiers de clés sont ignorés et jamais servis.
• Les archives sont décompressées avec des plafonds de taille et de nombre de fichiers pendant la décompression ; les liens, les périphériques, les chemins absolus et les chemins .. sont rejetés.
• Les sites anonymes et gratuits n’acceptent que des fichiers web, vérifiés selon leur contenu : pas de programmes, d’installateurs ni de scripts, et les fichiers binaires doivent vraiment être des images, des polices, de l’audio, de la vidéo, des PDF ou du WebAssembly.
• Les envois sans compte sont limités par réseau.

Hameçonnage et abus

• Les noms de sites choisis sont refusés s’ils sont réservés, imitent des marques à haut risque (banques, paiements, transporteurs, crypto, administration, géants de la tech), y compris par des orthographes trompeuses, ou contiennent des mots courants d’hameçonnage. Les domaines personnalisés qui imitent ces marques sont aussi refusés.
• Les sites non récupérés expirent après 72 heures et ne peuvent pas être protégés par mot de passe, ils ne peuvent donc pas échapper à un examen. Les sites non récupérés et les sites de moins de 7 jours envoient noindex.
• Tout le monde peut signaler un site sur pagelemon.com/report (chaque site y renvoie aussi depuis /_pagelemon/report et son security.txt) ; les signalements arrivent à l’équipe, qui peut suspendre un site immédiatement et bannir des comptes. Chaque action de l’équipe est consignée dans un journal d’audit.
• Les plugins de site avertissent et peuvent être désactivés si une page place un champ de mot de passe à côté d’eux.

Authentification des e-mails

• *.pagelemon.dev : MX nul, v=spf1 -all et DMARC p=reject, donc aucune adresse de site utilisateur ne peut recevoir d’e-mails ni servir à en usurper.
• Les e-mails envoyés au nom des sites partent de pagelemon.dev, signés DKIM, sous DMARC strict (p=reject, alignement strict). Nos propres e-mails partent de pagelemon.com, signés DKIM, avec DMARC p=reject, donc les e-mails qui usurpent nos adresses sont refusés.
• Les e-mails des sites et nos propres e-mails utilisent des domaines séparés, pour que le spam d’un site détourné ne nuise pas à la distribution des e-mails de connexion et de facturation.

Journaux et conservation des données

• Les journaux d’accès de l’application, de l’API et des sites publiés conservent des adresses IP tronquées et suppriment les en-têtes d’autorisation, les cookies, les chaînes de requête et les jetons de liens secrets. Sur notre site vitrine, le journal ne conserve que les parties ref, invite et utm_ de la chaîne de requête, qui nous indiquent quel lien vous a amené. Tous les journaux sont renouvelés bien avant 30 jours.
• Les adresses IP des expéditeurs de sites publiés sans compte sont supprimées après 30 jours.
• Les fichiers des sites supprimés sont effacés après 7 jours. Vous pouvez télécharger n’importe quel site au format zip et supprimer votre compte vous-même.

Certifications

Nos services d’hébergement, de réseau edge, de connexion, de paiement et d’e-mail sont exploités par des fournisseurs établis qui détiennent des certifications de sécurité indépendantes telles que SOC 2 Type II et ISO/IEC 27001, et notre prestataire de paiement est certifié PCI DSS niveau 1. Ces fournisseurs fonctionnent à une échelle bien supérieure à celle de Page Lemon, la capacité grandit donc avec nous ; notre propre plan de croissance par étapes est documenté et déclenché par la charge mesurée. Chaque entreprise qui traite vos données pour nous est nommée sur notre page des sous-traitants.

Pas encore fait

Nous préférons vous le dire plutôt que vous le laisser découvrir :

• Public Suffix List : pagelemon.dev ne figure pas encore sur la Public Suffix List. En attendant, les navigateurs traitent les sites voisins sur pagelemon.dev comme un même site pour les cookies. Nos comptes ne sont pas concernés (ils sont sur pagelemon.com) ; la demande d’inscription est en préparation.
• La connexion à deux facteurs n’est pas encore proposée pour les comptes Page Lemon.
• Page Lemon n’a pas de certification SOC 2 ni ISO 27001 qui lui soit propre.

Signaler une vulnérabilité

Écrivez à support@pagelemon.com. Merci de ne pas accéder aux données d’autrui, de ne pas perturber le service et de ne pas publier de détails avant que nous ayons corrigé le problème. Nous n’engagerons aucune action en justice contre une recherche de bonne foi respectant ces règles, et nous vous citerons si vous le souhaitez. Nos coordonnées figurent aussi dans security.txt.

Pour signaler plutôt un site dangereux, utilisez Signaler un site.