Le backend /Sécurité et RLS
Sécurisé par la base de données.
Pas par le middleware.
L'autorisation dans Rebase, c'est la sécurité au niveau des lignes de Postgres, appliquée par la base elle-même — et elle échoue en position fermée : une table sans RLS est refusée, jamais divulguée. C'est vrai aujourd'hui en auto-hébergeant la pile open source, et c'est vrai sur Rebase Cloud, qui fait tourner le même serveur.
Vérifiez la base de données que vous avez déjà
Vous n'avez à croire rien de tout cela. rls-check lit le catalogue de votre propre base et rapporte ce qui est réellement exposé : des tables servies avec la sécurité au niveau des lignes désactivée, des politiques vraies pour tout le monde, des vues qui contournent la RLS de leurs tables de base. Il fonctionne sur n'importe quel Postgres — Supabase, Neon, RDS ou votre propre serveur.
En lecture seule par construction : il ouvre une transaction en lecture seule et exécute des requêtes sur le catalogue. Il n'écrit rien, et aucune donnée ne quitte votre machine.
La sécurité au niveau des lignes, écrite là où est la collection
Définissez qui peut lire, créer, mettre à jour et supprimer chaque ligne — appliqué directement par PostgreSQL. Les politiques s'écrivent comme du code dans votre schéma, sont versionnées et appliquées par migrations. Pas de middleware, pas de bricolage d'ORM. Et cela échoue en position fermée : une table sans RLS n'a pas de modèle d'autorisation, donc Rebase refuse de la servir — et affiche au démarrage le SQL exact pour la protéger. Il n'y a aucune vérification d'auth à oublier.
Le comportement par défaut
Une table sans politique ne sert aucune ligne
La plupart des systèmes de cette catégorie sont permissifs jusqu'à ce que vous pensiez à les verrouiller. Rebase fait l'inverse : les requêtes s'exécutent sous un rôle Postgres restreint qui ne possède rien, donc une table pour laquelle vous avez oublié d'écrire une politique est refusée plutôt que divulguée.
Cela vaut pour toutes les entrées à la fois — l'API REST, le SDK typé, le panneau d'administration, la clé à portée limitée d'un agent et une session psql rencontrent les mêmes politiques, parce que les politiques ne sont pas dans le serveur.
Aucun rôle qui contourne tout
Le trafic utilisateur ne s'exécute jamais en tant que propriétaire de la table. Il n'existe pas de clé « service » qui désactive discrètement les politiques par confort.
Colonnes privilégiées protégées par défaut
Les collections d'auth reçoivent des politiques injectées pour qu'un utilisateur ne puisse pas se promouvoir en écrivant sa propre colonne de rôles. S'en dispenser est explicite et nommé.
Les tables de jonction héritent de leurs extrémités
Les jointures plusieurs-à-plusieurs sont le trou classique. Leurs politiques sont dérivées des deux côtés de la relation plutôt que laissées à votre mémoire.
Une base de données, pas de seconde copie
Rebase parle directement à votre Postgres et n'ingère jamais vos lignes dans un magasin à lui. Il n'y a qu'un endroit où les politiques doivent tenir, et c'est là où vivent les données.
Vous pouvez tout lire
Le serveur est sous licence MIT de bout en bout. Auditez le code, inspectez le SQL qu'il émet, et relisez les politiques depuis votre propre base avec
rls-check.La dérive est détectable
L'éditeur de politiques compare ce qui est dans votre code avec ce qui est dans la base et signale tout ce qui a bougé — y compris les règles permissives qui ont l'air sûres et ne le sont pas.
Des rôles que vos politiques peuvent lire
Définissez des rôles dans votre schéma — admin, éditeur, lecteur, ou tout rôle personnalisé dont vous avez besoin. Chaque rôle reçoit des permissions granulaires par collection.
Permissions par collection — SELECT, INSERT, UPDATE, DELETE par rôle et par collection.
Intégration RLS — Les politiques peuvent référencer le rôle de l'utilisateur courant pour filtrer au niveau des lignes.
Authentification JWT — Auth sans état à base de jetons, avec expiration et rafraîchissement configurables.
Vos données, votre infrastructure
Cette section décrit le modèle auto-hébergé. Contrairement aux plateformes SaaS qui ingèrent et contrôlent vos données, le serveur Rebase open source se connecte directement à votre propre base PostgreSQL, sur une infrastructure que vous exploitez. Si vous préférez que nous l'exploitions, passez à la section Rebase Cloud ci-dessous.
Aucune migration de données requise
Rebase introspecte et s'adapte à votre schéma existant.
Zéro enfermement fournisseur
Arrêtez d'utiliser Rebase quand vous voulez — vos données restent exactement là où elles sont.
Accès direct à l'infrastructure
Contrôle total sur votre base PostgreSQL, vos sauvegardes et votre infrastructure.
Déployez selon vos règles
Faites tourner Rebase où vous voulez. Aucun cloud propriétaire requis.
Votre base de données
Faites tourner PostgreSQL n'importe où — AWS RDS, Supabase, Neon, un VPS, ou votre propre matériel. Rebase s'y connecte ; il vous appartient.
Votre serveur
Déployez le backend Rebase comme processus Node.js ou conteneur Docker. Railway, Render, Fly.io ou bare metal — à vous de voir.
Vos règles
L'auth, les politiques RLS et les permissions d'API vivent dans votre code. Relisez-les en PR, versionnez-les dans Git, imposez-les en CI.
Deux modèles de déploiement, deux histoires de sécurité
Lisez ceci d'abord — presque chaque affirmation de cette page dépend de celui que vous exploitez. En auto-hébergé, nous ne voyons jamais vos données. Sur Rebase Cloud, nous les hébergeons pour vous, ce qui fait de nous un sous-traitant. Rebase Cloud est en bêta privée : il fait tourner de vrais clients aujourd'hui et s'ouvre par vagues, et tout ce qui suit décrit ce qui tourne maintenant.
Vous exploitez tout
Vous installez le serveur Rebase open source et le pointez vers une base PostgreSQL qui vous appartient. Vos données ne touchent jamais nos serveurs, il n'y a aucun sous-traitant tiers dans le circuit, et vous êtes le seul responsable de traitement.
Les sections Souveraineté des données et Déployez selon vos règles ci-dessous décrivent ce modèle.
Nous l'exploitons pour vous
Rebase Cloud est notre hébergement managé. Nous hébergeons votre base et votre application sur notre infrastructure, ce qui signifie que Rebase agit comme sous-traitant pour votre compte, avec Google Cloud comme sous-traitant ultérieur. Rien sur cette page ne prétend le contraire.
La section Rebase Cloud ci-dessous décrit exactement où ces données vivent et comment elles sont isolées.
Quand nous l'hébergeons, voici ce que cela signifie
Voici l'architecture qui tourne aujourd'hui : votre base et votre application sur une infrastructure que nous exploitons, avec Rebase comme sous-traitant des données que vous y mettez et vous comme responsable de traitement. Rebase Cloud est en bêta privée — il fait tourner de vrais clients aujourd'hui et s'ouvre par vagues. Demandez un accès.
Hébergé dans l'UE
Rebase Cloud tourne sur un cluster Google Kubernetes Engine Autopilot dans Google Cloud europe-west1 (Belgique). Votre base et les conteneurs de votre application y tournent. Rebase Cloud ne propose pas encore de choix de région.
Sous-traitant et sous-traitant ultérieur
Vous êtes le responsable de traitement des données que vos utilisateurs mettent dans votre projet. Rebase est le sous-traitant, et Google Cloud est sous-traitant ultérieur car il fournit le calcul, le stockage et le réseau sur lesquels Rebase Cloud tourne.
Une base de données par client
Ce n'est pas du multi-tenant à schéma partagé. Chaque projet a sa propre base PostgreSQL — il n'y a pas de colonne tenant_id qui vous sépare d'un autre client, et une connexion est liée à une seule base, donc une lecture inter-tenants est inatteignable plutôt que simplement filtrée par policy. Cette base est un cluster CloudNativePG bien à elle, dans son propre namespace Kubernetes et avec ses propres sauvegardes — pas une base sur un cluster partagé avec d’autres clients.
Isolation réseau entre clients
Chaque namespace client est créé avec une NetworkPolicy Kubernetes couvrant l'entrée et la sortie : les pods d'un projet ne peuvent pas ouvrir de connexions vers les pods ou la base d'un autre. Les applications clientes sont servies depuis *.rebase.website — un domaine enregistrable distinct, délibérément jamais partagé avec la console, pour que les frontières de cookies et de same-site du navigateur tombent entre elles.
Chiffrement en transit et des secrets
Le trafic vers la console et vers chaque domaine client est servi en TLS, avec des certificats émis automatiquement (Let's Encrypt via cert-manager pour les domaines clients). Les secrets que le plan de contrôle conserve pour vous — variables d'environnement du projet, chaînes de connexion, identifiants de cluster, identifiants de sauvegarde — sont chiffrés au repos en AES-256-GCM. Le plan de contrôle refuse de démarrer sans clé de chiffrement valide ; il n'y a pas de repli en clair.
Sauvegardes nocturnes, rétention de 30 jours
Les bases managées sont provisionnées avec une sauvegarde de base nocturne plus un archivage continu du write-ahead log vers du stockage objet, sous une politique de rétention de 30 jours — c'est aussi ce qui rend possible la restauration à un instant donné. L'état des sauvegardes est rapporté par projet dans la console, pour que vous voyiez si l'archivage tourne réellement plutôt que de le supposer.
Rebase Cloud pourra aussi se connecter à une base PostgreSQL que vous possédez déjà au lieu d'en provisionner une. Dans ce cas la base reste entièrement sous votre contrôle et les remarques ci-dessus sur la base managée — isolation, sauvegardes, rétention — ne s'y appliquent pas.
Où vous en êtes sur le RGPD
La réponse diffère selon le modèle de déploiement, alors voici les deux.
Vous êtes le responsable, et le seul sous-traitant
- Aucun sous-traitant tiers impliqué. Le logiciel tourne sur votre infrastructure ; nous ne recevons aucune donnée client.
- Accès direct aux données. Traitez les demandes d'accès et de suppression depuis votre propre base — sans ticket de support, sans fournisseur dans la boucle.
- La résidence est votre choix. Déployez PostgreSQL dans la région qu'exigent vos obligations.
Vous êtes le responsable, nous sommes votre sous-traitant
- Rebase traite selon vos instructions. Vous restez responsable de traitement pour les données de vos utilisateurs finaux.
- Google Cloud est sous-traitant ultérieur, fournissant le calcul, le stockage et le réseau dans europe-west1 (Belgique).
- Les données restent dans l'UE par défaut, car c'est la seule région dans laquelle Rebase Cloud provisionne.
Besoin d'un contrat de sous-traitance signé ou d'une liste formelle de sous-traitants avant d'acheter ? Écrivez à sales@rebase.pro et nous vous dirons honnêtement où en est cette paperasse.
Vous avez trouvé une vulnérabilité ?
Signalez-le en privé à security@rebase.pro. Merci de ne pas ouvrir de ticket GitHub public pour un problème de sécurité, et de nous laisser une chance de livrer un correctif avant toute divulgation. Nous visons un accusé de réception sous quelques jours ouvrés.
Lisez les politiques qu'il écrit.
Échafaudez un projet et inspectez la sécurité au niveau des lignes de Postgres générée depuis vos définitions de collection — avant de lui confier quoi que ce soit.