Sécurité

Cette page décrit les mesures de sécurité qui sont effectivement en place chez Astrina.io aujourd'hui. Elle est délibérément spécifique et délibérément incomplète : là où nous n'avons pas quelque chose, nous le disons au lieu de laisser entendre le contraire. Si un contrôle de sécurité n'est pas listé sur cette page, supposez que nous ne l'avons pas.

Où vos données sont stockées

Astrina fonctionne sur un seul serveur hébergé par OVH dans l'UE. Le serveur est géré avec le panneau de contrôle Hestia, et la base de données (MariaDB/MySQL) fonctionne sur ce même serveur. Cloudflare se trouve devant pour le DNS, le CDN, la terminaison TLS et le WAF.

La liste complète des tiers qui traitent des données en notre nom se trouve sur la page Subprocessors. Ce que nous collectons et combien de temps nous le conservons est précisé dans la Politique de confidentialité et la Politique de conservation des données.

Cryptage en transit

Tout le trafic vers et depuis Astrina.io est servi via TLS. Cloudflare est configuré en mode Full (strict), ce qui signifie que la connexion entre Cloudflare et notre serveur d'origine est également cryptée et que le certificat d'origine est validé. Le certificat d'origine est délivré par Let's Encrypt.

Mots de passe

• Les mots de passe sont stockés uniquement sous forme de hachage, produit par PHP password_hash() utilisant bcrypt (PASSWORD_DEFAULT), et vérifiés avec password_verify().
• Nous ne stockons jamais votre mot de passe en texte clair, et nous ne l'écrivons jamais dans un journal. Personne chez Astrina ne peut lire votre mot de passe ou vous dire ce que c'est.
• Les jetons de vérification par e-mail et de réinitialisation de mot de passe sont stockés sous forme de hachage SHA-256 du jeton, sont à usage unique et expirent.
• Lorsqu'un mot de passe est vérifié par rapport à des listes de violations connues, nous utilisons la méthode de k-anonymat des mots de passe compromis : seuls les cinq premiers caractères du hachage SHA-1 du mot de passe sont envoyés. Le mot de passe lui-même ne quitte jamais le navigateur ou notre serveur.

Il n'y a pas d'authentification à deux facteurs sur les comptes Astrina. Voir "Ce que nous n'avons pas encore" ci-dessous.

Sessions et formulaires

• Le cookie de session s'appelle astrsess. Il est défini en HttpOnly (JavaScript ne peut pas le lire), Secure (il est uniquement envoyé via HTTPS) et SameSite=Lax.
• Les soumissions de formulaires modifiant l'état portent un jeton CSRF, de sorte qu'un autre site ne peut pas faire effectuer une action dans votre compte par votre navigateur.

Clés API

• Votre clé API est acceptée uniquement dans un en-tête de requête — X-Api-Key, ou Authorization: Bearer. Nous ne acceptons délibérément pas les clés dans la chaîne de requête URL.
• Ce choix est important : une clé placée dans une URL a tendance à se retrouver dans les journaux d'accès du serveur, les journaux de proxy, l'historique du navigateur et les en-têtes Referer envoyés à d'autres sites. Une clé dans un en-tête ne le fait pas.
• Vous pouvez régénérer votre clé à tout moment depuis /my/api.php. La régénération révoque instantanément l'ancienne clé.
• Chaque plan a un quota d'appels quotidien. Une fois épuisé, l'API renvoie HTTP 429 plutôt que de continuer à servir des requêtes.

Accès inter-origines (CORS)

Nos méthodes d'API publiques sont intentionnellement ouvertes à toute origine (Access-Control-Allow-Origin: *), car elles servent des données de catalogue publiques. La méthode d'analyse privée, /api/v1/stats, n'envoie aucun en-tête Allow-Origin — donc une page web sur un autre site ne peut pas utiliser le navigateur d'un visiteur pour lire vos statistiques, même si elle avait d'une manière ou d'une autre votre clé.

Renforcement du robot d'exploration SEO

Notre robot d'exploration SEO récupère les URL fournies par les clients, ce qui est exactement le genre de fonctionnalité qui est abusée pour atteindre des systèmes internes (SSRF). Il est renforcé contre cela :

• Seules les URL http et https sont acceptées.
• Les plages d'adresses IP privées, de bouclage et locales sont refusées.
• L'adresse IP résolue est fixée, de sorte que le nom d'hôte ne peut pas se résoudre en quelque chose de différent entre la vérification et la requête.
• Chaque saut de redirection est revalidé selon les mêmes règles, pas seulement la première URL.
• La taille du corps de la réponse est limitée.

L'enregistrement de session est masqué par défaut

Si vous activez l'enregistreur de session optionnel, le masquage est activé par défaut et est appliqué dans le navigateur du visiteur — avant que quoi que ce soit ne nous soit envoyé :

• Les champs de saisie de mot de passe, d'email et de téléphone ne transmettent jamais de valeur. Ni le texte, ni une version masquée, ni même sa longueur.
• Les champs de carte de paiement sont traités de la même manière.
• Le texte saisi dans tout autre champ est masqué par des points.
• Toute partie de votre page que vous marquez avec l'attribut [data-astr-mask] est masquée avant de quitter le navigateur.

Les enregistrements sont conservés pendant 30 jours par défaut. La période de conservation est configurable.

Fichiers de preuve sur les avis

Les images et vidéos jointes comme preuve à certains types d'avis sont stockées en dehors de la racine web, de sorte qu'elles ne peuvent pas être récupérées en devinant une URL. Elles ne sont servies que par un point de terminaison sécurisé, qui renvoie 403 à moins que l'avis n'ait été approuvé, que vous soyez l'auteur de l'avis ou que vous soyez un administrateur.

Contrôles d'abus et de bots

• Les soumissions d'avis sont limitées par adresse IP, et les avis sont modérés. Les avis des invités ne sont publiés qu'après modération ; les avis des membres connectés sont publiés immédiatement.
• Le trafic analytique est filtré pour les bots en utilisant des règles d'agent utilisateur ainsi que la classification des IP de centre de données et d'hébergement via DNS inversé.

Accès administrateur

La zone d'administration est protégée par un contrôle de rôle sur le compte. Les comptes administratifs utilisent le même mécanisme de connexion que tout le monde, ce qui signifie qu'ils ne sont également pas protégés par l'authentification à deux facteurs.

Email que nous envoyons

Les emails sortants (de noreply@astrina.io) sont envoyés par notre propre serveur de messagerie Exim avec DKIM configuré, de sorte que les destinataires peuvent vérifier qu'un message provient réellement de nous. Nous ne transmettons pas votre adresse à un fournisseur de messagerie tiers.

Sauvegardes et restauration du service

Hestia effectue une sauvegarde quotidienne des fichiers et de la base de données, à environ 05:12 UTC.

Les sauvegardes sont stockées sur le même serveur qui exécute le service. Il n'y a pas de copie hors site et pas de réplication géo-redondante. C'est une véritable limitation et vous devriez en tenir compte dans votre propre planification : un événement qui détruit le serveur détruirait également les sauvegardes qui y sont stockées. En pratique, environ une copie quotidienne existe à tout moment.

Si le service doit être restauré, nous restaurons à partir de la sauvegarde quotidienne la plus récente. Nous ne garantissons pas un objectif de temps de récupération (RTO) ou un objectif de point de récupération (RPO), et nous n'offrons pas d'accord de niveau de service public. Un SLA n'existe que là où il a été convenu séparément dans un contrat individuel.

Ce que nous n'avons pas encore

Nous préférerions vous le dire clairement plutôt que de laisser une page de sécurité impliquer plus que ce qu'elle devrait. Astrina n'a actuellement pas :

• Pas d'authentification à deux facteurs (2FA), et pas de SSO pour le panneau Astrina lui-même.
• Pas d'audit de sécurité tiers et pas de test de pénétration. Aucun n'a été effectué, donc il n'y a pas de résultats à publier.
• Pas de certification ISO 27001, SOC 2 ou toute autre certification. Nous ne sommes certifiés ni audités selon aucune norme.
• Pas de sauvegarde hors site. Voir la section des sauvegardes ci-dessus.
• Pas de programme de récompense pour les bugs. Nous acceptons les rapports, mais nous ne pouvons pas les payer.
• Pas d'accord de niveau de service formel et pas de garantie de disponibilité publiée.

Si l'un de ces éléments est une exigence pour vous, ils sont absents aujourd'hui, et vous devez décider en conséquence.

Signalement d'un problème de sécurité

Si vous trouvez une vulnérabilité, veuillez la signaler à support@astrina.io. C'est la seule adresse de contact pour les rapports de sécurité.

Il est utile d'inclure l'URL ou le point de terminaison affecté, les étapes pour reproduire et ce qu'un attaquant pourrait réaliser. Veuillez nous donner une occasion raisonnable de corriger un problème avant de le divulguer publiquement, et veuillez ne pas accéder, modifier ou supprimer des données appartenant à d'autres personnes pendant les tests.

Nous ne gérons pas de programme de récompense pour les bugs et ne pouvons pas offrir de paiement ou de récompense pour les rapports. Nous ne promettons également pas de délai de réponse, car nous n'offrons pas de SLA public — mais les rapports envoyés à cette adresse nous parviennent et nous agissons sur eux.

Vos données et votre contrôle sur celles-ci

• Vous pouvez supprimer un site suivi individuel de votre panneau à tout moment, ce qui supprime ses données.
• Vous pouvez régénérer ou révoquer votre clé API à tout moment depuis /my/api.php.
• Il n'y a pas de bouton de suppression de compte en libre-service dans le panneau aujourd'hui. Pour faire supprimer votre compte et vos données, envoyez un e-mail à support@astrina.io et nous le ferons sur demande.

Pages connexes

• Politique de confidentialité — ce que nous collectons et pourquoi
• Conservation des données — combien de temps chaque type de données est conservé
• Sous-traitants — les tiers impliqués
• Cookies — ce qui est défini, et sur quel domaine
• Accord de traitement des données
• Conditions de service · Politique d'utilisation acceptable
• Contact