Protéger vos données utilisateurs avec PostgreSQL RLS sur Aurabase

Le problème de la sécurité côté application

Beaucoup d'équipes de développement gèrent l'autorisation d'accès directement dans le code de leurs routes API. Cette approche fonctionne jusqu'au premier oubli de filtre dans une clause de requête. Une seule omission d'identifiant d'utilisateur expose l'ensemble des données d'un client à un autre. La méthode la plus fiable consiste à déléguer cette responsabilité au moteur de base de données.

Aurabase fournit une base PostgreSQL dédiée pour chaque projet, hébergée en Allemagne ou en Finlande. Contrairement aux architectures mutualisées où plusieurs clients partagent la même instance de base de données, chaque projet dispose d'un conteneur totalement isolé. La sécurité s'appuie sur les fonctionnalités natives de PostgreSQL, notamment le Row-Level Security (RLS), couplées à une gestion d'identité intégrée.

Étape 1 : Activer le RLS sur vos tables

Dans PostgreSQL, une table créée sans règle explicite est accessible sans restriction par défaut selon vos rôles SQL. Pour garantir l'isolation des données, l'activation du RLS est une étape obligatoire sur chaque table contenant des informations d'utilisateurs.

Prenons l'exemple d'une table stockant des relevés d'équipements. La structure nécessite au minimum un identifiant d'utilisateur associé au jeton d'authentification fourni par le service d'identité.

Activez d'abord la sécurité par ligne sur la table concernée :

ALTER TABLE devices ENABLE ROW LEVEL SECURITY;

Créez ensuite la politique restreignant la lecture aux seuls propriétaires de chaque ligne :

CREATE POLICY device_owner_policy ON devices FOR SELECT USING (auth.uid() = user_id);

Cette règle s'exécute au niveau du moteur SQL. Si le jeton d'authentification transmis ne correspond pas à la valeur de la colonne de l'enregistrement, PostgreSQL filtre le résultat. L'API renvoie un ensemble vide sans lever d'erreur et sans révéler les données des autres comptes.

Étape 2 : Interroger la base avec le SDK TypeScript

Une fois la politique SQL appliquée, la récupération des données côté client ou serveur s'effectue au moyen du SDK officiel. Le package gère automatiquement la transmission du contexte d'authentification et le typage des réponses.

Installez le module dans votre application :

npm i @aurabase/aurabase-js

Le SDK synchronise automatiquement les types TypeScript avec le schéma de votre base de données. Vous n'avez pas besoin de faire tourner un générateur de code séparé dans votre pipeline de déploiement à chaque modification de table.

Voici comment récupérer des données filtrées par RLS dans une route API :

import { aura } from '@/lib/aurabase'

export async function GET() {

  const { data, error } = await aura.from('devices').select('id, temperature, last_seen').order('last_seen', { ascending: false }).limit(50)

  if (error) return Response.json({ error: error.message }, { status: 400 })

  return Response.json({ data })

}

Remarquez l'absence de clause de filtrage manuel dans le code TypeScript. La passerelle vérifie le jeton JWT de la requête, extrait l'identifiant utilisateur et l'injecte dans la session PostgreSQL. La base applique la règle RLS automatiquement.

Étape 3 : Traiter la logique métier sur le réseau Edge

Pour les opérations nécessitant des traitements lourds ou du nettoyage de données avant écriture, l'exécution de code sur un serveur central rajoute de la latence. Aurabase intègre un moteur d'exécution serverless Edge s'appuyant sur WebAssembly (WASM).

Vous pouvez écrire vos fonctions en TypeScript, Rust, Go ou Python. Ces fonctions sont compilées au format WASM, ce qui garantit un démarrage instantané sans latence de démarrage à froid. Placée devant votre base de données, une fonction Edge permet de valider des payloads complexes ou de transformer des métadonnées avant qu'elles ne touchent la couche de stockage.

Étape 4 : Isoler le stockage de fichiers S3

La gestion des droits ne doit pas s'arrêter aux tables SQL. Si votre application permet d'uploader des images ou des documents, ces fichiers requièrent le même niveau d'isolation.

Le stockage d'objets compatible S3 fourni par la plateforme utilise le même système d'authentification que la base de données. Les règles d'accès aux buckets réutilisent les identifiants gérés par l'Identity Management, évitant la désynchronisation des droits entre vos contenus fichiers et vos données relationnelles. Un CDN mondial distribue ensuite les fichiers autorisés aux utilisateurs finaux.

Ce qu'il faut retenir avant le passage en production

La plateforme est actuellement proposée en bêta ouverte. L'offre gratuite inclut 3 projets, 500 Mo d'espace PostgreSQL dédié, 1 Go de stockage d'objets, 100 000 invocations Edge par mois et 50 000 utilisateurs actifs mensuels. C'est une enveloppe suffisante pour construire un prototype complet ou migrer une petite application.

L'avantage principal de ce modèle réside dans la séparation des responsabilités. En confiant le filtrage des accès à la couche PostgreSQL via le RLS et en isolant chaque projet sur sa propre instance en Europe, vous supprimez une grande classe de vulnérabilités logicielles liées aux erreurs de code dans les API.