Aucune certification SOC 2, ISO 27001 ou autre n’est détenue.
Choisir un produit
Hébergement webSites web et WordPress avec un forfait à prix fixeCloudDéployez applications, API et bases de données depuis Git ou DockerAI BuilderCréez et modifiez des sites et des applications avec l’IAÀ ajouter à tout projet
Domaines et e-mailBases de donnéesWordPress géréExécution d’agentsMigrationsDéveloppeurs
Tout sur l’IADéveloppeursMCP pour assistants IADocumentationSécuritéStatutHostingsurge
TarifsSe connecterSécurité
Isolation et travail vérifié, dès la conception.
Cette page décrit comment la plateforme de Hostingsurge est réellement conçue : la frontière de la base de données, la frontière des sessions, le bac à sable de build et le circuit de paiement. Elle ne mentionne aucune certification ni aucun audit, car il n’en existe aucun.
Isolation des locataires dans la base de données
L’isolation est appliquée là où résident les données, pas seulement dans le code applicatif.
- Chaque table sensible au locataire porte une organisation propriétaire (organization_id ou une frontière de location équivalente) avec une propriété composite jusqu’aux projets.
- La sécurité au niveau des lignes (row-level security) est forcée pour les tables des locataires, et les rôles d’exécution sont restreints : le rôle d’identité ne peut pas lire les données de projet ou de portefeuille, et la frontière des requêtes rejette les rôles PostgreSQL d’administration, de superutilisateur et ceux qui ont des droits au niveau des fichiers ou du serveur.
- Le contexte du locataire est défini à chaque transaction. Un identifiant qui arrive d’un navigateur est une demande, jamais une autorisation.
- Les écritures protégées passent par des fonctions qui vérifient indépendamment la session et l’autorité en vigueur, et les écritures directes des rôles applicatifs sont révoquées pour ces tables.
Sessions et autorité en vigueur
L’authentification est vérifiée à l’entrée, et l’autorité est revérifiée au moment où elle est utilisée.
- Les cookies de session sont HttpOnly et SameSite=Lax, préfixés __Host- en production, et chaque requête associe la session à un utilisateur et à un locataire avant toute autre opération.
- Les requêtes de modification émises par le navigateur doivent provenir de l’origine configurée, et les corps de requête sont bornés (application/json, 16 KiB, délai de cinq secondes).
- Les modifications sensibles — changements de MFA, émission d’identifiants, achats, changements d’offre — exigent une authentification récente plutôt qu’une session de longue durée.
- La MFA repose sur TOTP avec des codes de récupération à usage unique. Les jetons et les codes sont consommés de manière atomique, de sorte que deux utilisations simultanées ne peuvent pas réussir toutes les deux.
Identifiants et approbations d’opérations
Un identifiant est une autorisation limitée et révocable — pas une clé permanente de la plateforme.
- Les identifiants API et MCP sont hachés au repos, liés à une organisation, une marque et un projet, portent des portées explicites et une durée de vie limitée, et ne sont affichés qu’une seule fois.
- Retirer quelqu’un d’une équipe révoque définitivement ses identifiants, et une réinitialisation du mot de passe invalide les identifiants émis auparavant.
- Les actions sensibles et facturables exigent une approbation de courte durée liée à l’utilisateur, à l’organisation, au projet, à l’action exacte, à la cible et à l’empreinte canonique des données d’entrée.
- La consommation de l’approbation, l’admission de la tâche, la réservation de crédits, l’audit et l’enregistrement dans l’outbox sont validés dans une seule transaction ; si le callback de confiance échoue, toute l’admission est annulée. Les changements de rôle ou d’appartenance révoquent définitivement les approbations en attente.
Des builds isolés
Le code des clients et le code généré par l’IA sont traités comme non fiables, parce qu’ils le sont.
- Les builds s’exécutent dans un conteneur temporaire, sur une image de base minimale, avec le réseau désactivé, une mémoire et un CPU plafonnés, une limite de processus, un système de fichiers racine en lecture seule, un montage temporaire noexec borné, sans socket Docker ni identifiants de production, et avec un délai maximal en temps réel.
- Un artefact doit réussir la vérification d’empreinte et de taille et être écrit via un stockage atomique — écriture, flush, relecture, renommage atomique, nouvelle relecture — avant qu’un reçu de build soit enregistré. Un plantage ne peut donc jamais laisser un état « prêt » sans octets durablement écrits.
- Les reçus de build et d’artefact sont en ajout seul (append-only) ; toute mise à jour ou suppression déclenche une erreur d’immuabilité.
- Un worker détient un bail protégé par fencing, le renouvelle pendant qu’il travaille et s’arrête s’il en perd la propriété. Les limites de source et d’archive (1000 entrées, 256 Ko par fichier, 16 Mo au total) sont appliquées à l’entrée comme à la sortie.
- Le contenu des fichiers est transmis au navigateur sous forme de texte échappé : le balisage contenu dans un fichier enregistré reste inerte et n’est jamais exécuté.
Des paiements vérifiés à partir d’événements signés
L’argent ne bouge que lorsque le prestataire le dit — et la plateforme peut le prouver.
- Les webhooks de paiement sont vérifiés par un véritable contrôle de signature sur le corps brut et borné de la requête, avec des contrôles anti-rejeu et temporels et une portée exacte de compte et de mode test/live. Le point de terminaison n’accuse réception qu’une fois l’événement durablement enregistré.
- Les crédits ne deviennent un solde qu’une fois le paiement vérifié auprès du prestataire — facture, payment intent et charge — et un octroi est appliqué exactement une fois.
- Les prix ne sont jamais repris d’un navigateur : les montants et les unités de crédit proviennent d’un catalogue côté serveur, et un prix qui ne correspond pas au produit, au montant, à la devise et au cycle attendus est rejeté.
Hébergement dans l’UE et durcissement documenté
Ce qui est vrai aujourd’hui, y compris ce qui n’est pas terminé.
- Les serveurs sont situés dans l’UE et gérés par la plateforme. Les clients ne reçoivent jamais de panneau de contrôle d’un prestataire ; tout passe par Hostingsurge.
- Sur le serveur de production, les mises à jour du système d’exploitation en attente ont été installées (y compris les mises à jour de sécurité), le pare-feu a été activé en conservant SSH, HTTP, HTTPS et HTTP/3, et l’écoute de l’interface d’administration du reverse proxy a été restreinte à localhost, puis vérifiée après redémarrage.
- La terminaison du trafic passe par TLS et un proxy durci ; les interfaces d’administration ne sont pas exposées à Internet.
- La base de données de contrôle est sauvegardée toutes les 24 heures sur un stockage du même serveur et conservée 14 jours. La copie chiffrée hors site est construite, mais son bucket de stockage n’est pas encore connecté ; les sauvegardes restent donc sur le serveur pour l’instant, et c’est indiqué ici plutôt que sous-entendu.
Ce que cette page n’affirme pas
Dit clairement, car une page de sécurité qui s’exagère est pire que pas de page du tout.
Aucun audit de sécurité indépendant n’a été réalisé.
Il n’existe aucun rapport de test d’intrusion réalisé par un tiers.
Aucun SLA de disponibilité ni aucun programme de bug bounty n’est proposé.
Aucune adresse de signalement des failles de sécurité n’est encore publiée. D’ici là, une découverte ne dispose d’aucun canal confirmé — et cette page en indiquera un dès qu’il existera.
Lisez les limites, puis décidez.
La page développeurs documente les vrais points de terminaison et leur authentification. La documentation indique, module par module, ce qui est implémenté.
Tout ce qui précède décrit la version actuelle. Aucune certification, aucun audit ni aucun SLA n’est revendiqué nulle part sur ce site.