La sécurité chez Clicbase, de bout en bout
Isolation des bases, chiffrement (TLS + AES-256), RLS, mots de passe hashés, serveur durci (SSH par clé, UFW, fail2ban), emails authentifiés (SPF/DKIM/DMARC), sauvegardes quotidiennes et identifiants de paiement chiffrés. La sécurité de Clicbase, documentée.
Clicbase héberge des données réelles : comptes, contenus, et même des identifiants de paiement. Voici, couche par couche, comment elles sont protégées, de la base de données jusqu'au serveur.
La sécurité n'est pas une fonctionnalité parmi d'autres : c'est une exigence de base quand on héberge des données de clients. Cet article documente, sans survol, les mesures en place à chaque étage de la plateforme.
Les garanties en bref
- Une base isolée par projet, pas de données partagées entre clients.
- Chiffrement en transit (HTTPS/TLS partout) et des secrets (AES-256).
- RLS : chaque utilisateur ne voit que ses lignes, appliqué dans la base.
- Mots de passe hashés (jamais en clair), serveur durci (SSH par clé, UFW, fail2ban).
- Emails authentifiés (SPF/DKIM/DMARC) et sauvegardes quotidiennes.
1. Isolation des données
Chaque projet possède sa propre base PostgreSQL, dans son espace dédié. Aucune donnée n'est mélangée entre clients : c'est une isolation réelle, au niveau de la base, pas un simple filtre applicatif. C'est essentiel pour la confidentialité et pour le RGPD.
Pourquoi une base par projet, Un filtre oublié dans du code applicatif peut exposer les données d'un autre client. Des bases physiquement séparées rendent ce type de fuite impossible par construction.
2. Chiffrement en transit
Tout le trafic passe en HTTPS/TLS. Les certificats sont gérés automatiquement (Let's Encrypt via le reverse proxy), et le CDN en frontal applique une liaison chiffrée de bout en bout jusqu'à l'origine. Aucune donnée ne circule en clair sur le réseau.
3. Chiffrement des secrets
Les clés d'API et identifiants sensibles (Stripe, PayPal, SMTP…) sont chiffrés en AES-256 et stockés par projet dans un coffre. Ils ne sont jamais affichés en clair, jamais loggés, jamais commités. Seules les edge functions autorisées peuvent les déchiffrer à l'exécution.
Les identifiants de paiement, Les clés Stripe/PayPal d'un site sont chiffrées et isolées par projet. Un identifiant de paiement n'apparaît jamais en clair, nulle part, ni en base, ni dans les logs, ni dans le code.
4. Authentification & accès aux données
L'authentification (email/mot de passe, Google) délivre un token par utilisateur. Ce token est ensuite confronté à la sécurité par ligne (RLS) de Postgres : la règle « chacun ne voit que ses données » est appliquée au cœur de la base, donc impossible à contourner depuis le front.
🔑 Mots de passe : toujours hashés (Disponible)
Un mot de passe n'est jamais stocké en clair, seul son hash l'est. À la migration depuis Supabase, les hash sont repris tels quels et ré-hashés de façon transparente au login. Personne, pas même nous, ne peut lire un mot de passe.
5. Durcissement du serveur
La machine hôte est durcie : connexion SSH par clé uniquement (mot de passe et login root désactivés), pare-feu UFW (seuls les ports 22, 80 et 443 ouverts), et fail2ban qui bannit les tentatives d'intrusion répétées.
| Mesure | Détail | Statut |
|---|---|---|
| SSH | Par clé uniquement, root et mot de passe désactivés | Disponible |
| Pare-feu | UFW, ports 22/80/443 ouverts, reste bloqué | Disponible |
| Anti-intrusion | fail2ban (bannissement automatique) | Disponible |
| Isolation projet | Conteneur Docker dédié (option) | Disponible |
6. Emails authentifiés
Les emails envoyés depuis ton domaine sont signés et authentifiés : SPF déclare les serveurs autorisés, DKIM signe chaque message, DMARC encadre les échecs. Résultat : tes emails arrivent en boîte principale et ne peuvent pas être usurpés.
7. Sauvegardes & résilience
Chaque base est sauvegardée automatiquement tous les jours (pg_dump), conteneurs dockerisés inclus. En cas de problème, on peut restaurer une base à son état de la veille.
En résumé
De l'isolation des bases au durcissement du serveur, en passant par le chiffrement et la RLS, la sécurité de Clicbase est pensée en profondeur, chaque couche protège la suivante.
La meilleure sécurité est celle qu'on n'a pas à configurer soi-même : elle est là, par défaut.
Des questions sur un point précis ? Crée un compte et regarde ton tableau de bord, la plupart de ces protections sont déjà actives, sans rien à régler.
Lance ton backend en quelques minutes
Base Postgres, API, auth, storage, realtime, plus tes mails et ton domaine. Gratuit pour commencer.