Sécurité au niveau du champ (FLS)
La sécurité au niveau du champ (FLS) est l’autorisation Salesforce qui détermine, pour chaque champ d’un objet, si un utilisateur peut le lire, le lire et le modifier, ou ne pas le voir. Elle s’octroie via les profils, les ensembles et les groupes d’ensembles d’autorisations, et s’applique à l’interface, aux rapports, aux vues de liste et aux API.
Niveaux d’accès et périmètre de la FLS
Dans un ensemble d’autorisations, un champ peut être en Lecture et modification, en Lecture, ou sans accès ; l’interface des profils emploie les anciens libellés Visible, Visible et Lecture seule, et Aucun. La restriction s’applique aux pages d’enregistrement, aux listes associées, aux vues de liste, aux rapports, aux données importées, aux sites Experience Cloud et aux API Salesforce : masquer un champ sur une page n’équivaut pas à en restreindre l’accès.
FLS et présentations de page
Quand la présentation de page et la sécurité au niveau du champ divergent, le réglage le plus restrictif l’emporte. Un champ obligatoire dans la présentation mais en lecture seule dans la FLS reste en lecture seule. Salesforce signale deux exceptions à connaître : les champs de formule et les champs de synthèse de cumul peuvent afficher des valeurs dérivées de champs que l’utilisateur ne voit pas, et les champs universellement obligatoires apparaissent sur les pages de modification quelle que soit la FLS.
La FLS dans Apex
Le comportement par défaut des opérations sur la base dépend de la version d’API avec laquelle le code Apex est compilé : Salesforce documente un mode utilisateur par défaut à partir de la version 67.0, et un mode système par défaut jusqu’à la version 66.0. Les déclencheurs s’exécutent en mode système ; examinez l’opération, la version et le contexte d’exécution réels au lieu de supposer que tout chemin Apex applique la FLS.
L’application est explicite : WITH USER_MODE en SOQL, insert as user et les autres formes de DML, AccessLevel.USER_MODE sur les méthodes Database, ou Security.stripInaccessible pour retirer les champs auxquels l’utilisateur n’a pas accès. En version 67.0, WITH SECURITY_ENFORCED ne compile plus ; reportez-vous aux consignes propres à chaque version pour maintenir du code plus ancien.
Ce qu’apporte aprity
aprity documente les accès à partir des métadonnées (profils, ensembles d’autorisations et sécurité au niveau du champ), sans rien écrire dans l’org. Les autorisations d’un champ se lisent ainsi à côté des automatisations et des règles métier qui l’utilisent, et le graphe de dépendances montre les composants qui en dépendent.
Termes liés
- Groupe d’ensembles d’autorisations — Un regroupement d’ensembles d’autorisations attribué d’un bloc, souvent par métier, avec un ensemble d’autorisations de désactivation facultatif pour retirer des autorisations.
- Déclencheur Apex — Du code Apex exécuté automatiquement avant ou après l’insertion, la mise à jour, la suppression ou la restauration d’enregistrements d’un objet.
- API de dépendance Salesforce (Dependency API) — L’objet MetadataComponentDependency de l’API Tooling, qui indique quels composants de métadonnées d’une org en référencent d’autres.
Sources
La documentation officielle de Salesforce sur laquelle cette définition a été vérifiée (pages en anglais). Le comportement de la plateforme évolue d’une version à l’autre : la page citée fait foi.