SQL Academy · Leçon

Politiques de sécurité au niveau des lignes

Filtrez automatiquement les lignes selon l’utilisateur.

Politiques de sécurité au niveau des lignes est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.

Qu'est-ce que la sécurité au niveau des lignes ?

La sécurité au niveau des lignes (RLS) est une fonctionnalité de PostgreSQL qui vous permet de contrôler quelles lignes d'une table un utilisateur ou un rôle de base de données donné peut consulter ou modifier. Au lieu de filtrer les lignes dans chaque requête, vous définissez une politique une seule fois et PostgreSQL l'applique automatiquement à chaque SELECT, INSERT, UPDATE et DELETE.

Considérez-la comme une clause WHERE invisible, attachée à la table elle-même plutôt qu'à une requête précise.

Activer RLS sur une table

RLS est désactivée par défaut. Vous devez l'activer explicitement pour chaque table à l'aide de ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Une fois activée, tout rôle qui n'est pas propriétaire de la table verra zéro ligne jusqu'à la création d'au moins une politique.

-- Create a sample table
CREATE TABLE orders (
  id        SERIAL PRIMARY KEY,
  owner     TEXT NOT NULL,
  amount    NUMERIC(10,2)
);

-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

Créer votre première politique

Une politique est créée avec CREATE POLICY. Vous lui donnez un nom, indiquez la table et fournissez une expression USING. La clause USING est une expression booléenne évaluée pour chaque ligne : seules les lignes pour lesquelles l'expression renvoie TRUE sont visibles par l'utilisateur.

-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
  ON orders
  FOR SELECT
  USING (owner = current_user);

Les clauses USING et WITH CHECK

Les politiques comportent deux clauses de filtrage qui ont des fonctions différentes :

USING — filtre les lignes lors des opérations de lecture (SELECT, UPDATE, DELETE). Une ligne n'est visible que si USING renvoie TRUE.
WITH CHECK — valide les lignes lors des opérations d'écriture (INSERT, UPDATE). Une écriture n'est autorisée que si WITH CHECK renvoie TRUE. Si elle est omise, USING est réutilisée pour les vérifications d'écriture.

-- Allow users to select and insert only their own rows
CREATE POLICY orders_isolation
  ON orders
  FOR ALL
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Portée des politiques : FOR SELECT, INSERT, UPDATE, DELETE

Une seule politique peut couvrir toutes les commandes (FOR ALL) ou une commande précise. Séparer les politiques par commande vous offre un contrôle précis — par exemple, permettre à chaque utilisateur de lire toutes les lignes, mais de ne modifier que les siennes.

-- Everyone can read all orders
CREATE POLICY read_all_orders
  ON orders
  FOR SELECT
  USING (true);

-- But each user can only update their own orders
CREATE POLICY update_own_orders
  ON orders
  FOR UPDATE
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Utiliser session_user et current_user

PostgreSQL fournit des fonctions intégrées permettant d'identifier l'utilisateur actif dans une expression de politique :

current_user — le rôle dont les privilèges sont actuellement actifs (il peut changer après SET ROLE).
session_user — le rôle qui a ouvert la connexion (il ne change jamais pendant la session).

La plupart des politiques RLS utilisent current_user, car il reflète le rôle effectif après un changement de rôle.

-- Inspect the current identity inside a query
SELECT current_user, session_user;

Appliquer RLS à des rôles spécifiques

Par défaut, une politique s'applique à PUBLIC (tous les rôles). Vous pouvez la restreindre à un rôle spécifique à l'aide de la clause TO. Cette possibilité est utile lorsque vous souhaitez une politique pour les utilisateurs ordinaires et une autre pour un rôle administrateur.

-- Policy only for the 'app_user' role
CREATE POLICY app_user_policy
  ON orders
  FOR SELECT
  TO app_user
  USING (owner = current_user);

-- Separate permissive policy for 'admin' role
CREATE POLICY admin_full_access
  ON orders
  FOR ALL
  TO admin
  USING (true)
  WITH CHECK (true);

Politiques permissives ou restrictives

Plusieurs politiques appliquées à la même table peuvent interagir de deux façons :

PERMISSIVE (par défaut) — toutes les politiques permissives sont combinées avec OR. Une ligne est accessible si au moins une politique permissive l'autorise.
RESTRICTIVE — les politiques restrictives sont combinées avec AND au résultat des politiques permissives. Une ligne est accessible uniquement si elle respecte la politique restrictive et au moins une politique permissive.

-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
  ON orders
  AS RESTRICTIVE
  FOR SELECT
  USING (amount > 0);

Contourner RLS : BYPASSRLS et propriétaires des tables

Le propriétaire de la table et les superutilisateurs contournent RLS par défaut et voient toujours toutes les lignes. Vous pouvez accorder l'attribut BYPASSRLS à un rôle s'il a besoin d'un accès sans restriction sans être superutilisateur. À l'inverse, vous pouvez obliger le propriétaire à respecter RLS en utilisant FORCE ROW LEVEL SECURITY.

-- Force the table owner to also obey RLS policies
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

-- Grant BYPASSRLS to a trusted service account
ALTER ROLE service_account BYPASSRLS;

Modifier et supprimer des politiques

Vous pouvez mettre à jour une politique existante avec ALTER POLICY ou la supprimer complètement avec DROP POLICY. Supprimer toutes les politiques alors que RLS est toujours activé signifie qu'aucune ligne n'est accessible aux rôles qui ne sont pas propriétaires. Pour supprimer complètement RLS, désactivez-le avec ALTER TABLE.

-- Rename a policy
ALTER POLICY orders_owner_policy ON orders
  RENAME TO user_isolation_policy;

-- Update the USING expression
ALTER POLICY user_isolation_policy ON orders
  USING (owner = current_user AND amount >= 0);

-- Remove a policy
DROP POLICY admin_full_access ON orders;

-- Disable RLS entirely on the table
ALTER TABLE orders DISABLE ROW LEVEL SECURITY;

Modèle concret : isolation des données entre locataires

Un modèle RLS courant dans les applications SaaS multi-locataires consiste à stocker une colonne tenant_id dans chaque table et à utiliser une variable au niveau de la session (set_config) pour transmettre l'identifiant du locataire au moment de la connexion. La politique compare ensuite le tenant_id de chaque ligne à cette valeur.

-- Table with tenant isolation column
CREATE TABLE documents (
  id         SERIAL PRIMARY KEY,
  tenant_id  TEXT NOT NULL,
  title      TEXT
);

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy reads the tenant from a session variable
CREATE POLICY tenant_isolation
  ON documents
  FOR ALL
  USING       (tenant_id = current_setting('app.tenant_id'))
  WITH CHECK  (tenant_id = current_setting('app.tenant_id'));

-- Application sets the variable before running queries
SELECT set_config('app.tenant_id', 'tenant_42', true);

-- Now only tenant_42 documents are visible
SELECT * FROM documents;

Vérification des connaissances

Évaluez votre compréhension des politiques de sécurité au niveau des lignes dans PostgreSQL.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris comment RLS permet de filtrer automatiquement les lignes, selon des politiques, directement au niveau de la base de données :

Activer RLS sur une table avec ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
Utiliser CREATE POLICY avec une clause USING pour filtrer les lignes pouvant être lues et une clause WITH CHECK pour valider les lignes écrites.
Limiter la portée des politiques à des commandes précises (SELECT, INSERT, UPDATE, DELETE, ALL) et à des rôles précis à l'aide de la clause TO.
Combiner les politiques PERMISSIVE (logique OR) et RESTRICTIVE (logique AND) pour créer un contrôle d'accès par couches.
Les propriétaires de tables et les superutilisateurs contournent RLS par défaut ; utilisez FORCE ROW LEVEL SECURITY pour passer outre ce comportement.
Le modèle multi-locataires utilisant current_setting() est une application concrète puissante de RLS.

RLS est la méthode standard pour imposer une isolation des données de manière claire et cohérente, sans disperser des clauses WHERE dans chaque requête de l'application.

Questions Fréquemment Posées

La leçon « Politiques de sécurité au niveau des lignes » est-elle gratuite ?

Oui — le texte complet de « Politiques de sécurité au niveau des lignes » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Politiques de sécurité au niveau des lignes » ?

Filtrez automatiquement les lignes selon l’utilisateur. Tu pratiques SQL Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer SQL Academy ?

Aucune expérience préalable n'est requise. SQL Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Politiques de sécurité au niveau des lignes » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon SQL Academy ?

Oui. Chaque leçon SQL Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Rôles et privilèges
Politiques de sécurité au niveau des lignes
Autorisations au niveau des colonnes
Auditer les accès

← Retour à SQL Academy