Pouvons-nous contrôler la sécurité au niveau du champ depuis Apex? / Blogs / perficient

Imaginez que vous créez une application Salesforce et que vous devez vous assurer que les utilisateurs ne peuvent accéder qu’à des champs spécifiques en fonction de leurs profils ou ensembles d’autorisation. Vous vous demandez peut-être: pouvons-nous contrôler la sécurité au niveau du champ (FLS) depuis Apex? Explorez ce sujet et comprenez les possibilités, les défis et les meilleures pratiques.

Comprendre la sécurité au niveau du terrain dans Salesforce

Avant d’explorer Apex, comprenons d’abord comment Salesforce gère la sécurité au niveau du terrain (FLS). FLS contrôle l’accès à des champs spécifiques dans un objet et détermine si un utilisateur peut voir, modifier ou modifier un champ.

Il existe plusieurs façons de configurer les FL dans Salesforce:

• Profils et ensembles d’autorisation: Vous définissez FLS au niveau du profil ou de l’autorisation.
• Disposages de pages: Vous pouvez restreindre la visibilité sur le terrain au niveau de l’interface utilisateur.
• Règles et déclencheurs de validation: Ceux-ci peuvent appliquer indirectement l’accès sur le terrain.

Maintenant, la grande question: pouvons-nous appliquer les FL dynamiquement dans Apex?

Apex peut-il appliquer la sécurité au niveau du champ?

Apex fonctionne en mode système par défaut, ignorant Sécurité au niveau du champ et autorisation d’objet à moins que ce soit explicitement géré. Cela signifie que même si un utilisateur ne peut pas accéder à un champ, Apex peut toujours récupérer et modifier sa valeur.

Cependant, Salesforce fournit des mécanismes pour appliquer les FL dans Apex:

1 et 1 En utilisant sChema.DescripfielDresult Pour vérifier FLS

Salesforce propose le Schema La classe nous permet de vérifier l’accès d’un utilisateur à un champ avant d’effectuer des opérations.

Exemple:

Schema.DescribeFieldResult fieldResult = Account.Industry.getDescribe();
if (fieldResult.isAccessible()) {
    System.debug('User has access to the Industry field');
} else {
    System.debug('User does NOT have access to the Industry field');
}

Cette méthode garantit que nous vérifions si l’utilisateur a la permission avant d’accéder à un champ.

2 Utilisation de sécurité.stripinaccessible ()

Introduit dans la version Spring ’20 de Salesforce, Security.stripInaccessible() vous permet de supprimer les champs auxquels l’utilisateur n’a pas la permission d’accès.

Exemple:

Account acc = [SELECT Id, Name, Industry FROM Account WHERE Id = :someId];
SObject sanitizedAcc = Security.stripInaccessible(AccessType.READABLE, acc);
System.debug(sanitizedAcc);

Cela empêche Apex d’exposer des champs restreints lors de l’interrogation des enregistrements.

De même, vous pouvez utiliser AccessType.UPDATABLE Pour éviter les mises à jour non autorisées:

update Security.stripInaccessible(AccessType.UPDATABLE, acc);

C’est un meilleure pratique pour la manipulation de FL dynamiquement.

3 et 3 En utilisant WITH SECURITY_ENFORCED in SOQL

Salesforce allows you to enforce FLS directly in SOQL queries using WITH SECURITY_ENFORCED.

Exemple:

Account acc = [SELECT Id, Name, Industry FROM Account WHERE Id = :someId WITH SECURITY_ENFORCED];

Si l’utilisateur ne peut pas accéder au Industry Champ, la requête échouera, garantissant la sécurité des données.

Défis dans le contrôle des FL avec Apex

Alors que Apex fournit des mécanismes pour appliquer les FL, il y a certains défis:

• Opérations en vrac: Lorsque vous gérez de grands volumes de données, la vérification manuelle de l’accessibilité de chaque champ peut être inefficace.
• Logique métier complexe: Si la logique dépend des champs auxquels l’utilisateur ne peut pas accéder, il peut casser la fonctionnalité Apex.
• UI vs application du backend: Les restrictions basées sur l’interface utilisateur ne s’appliquent pas au traitement du backend (déclencheurs, travaux de lots), ce qui nécessite une validation supplémentaire.

Meilleures pratiques pour gérer les FL en apex

Pour vous assurer que votre code APEX respecte les FL, suivez ces meilleures pratiques:

• Utilisez toujours Security.stripInaccessible() when working with records.
• Use WITH SECURITY_ENFORCED in SOQL to automatically enforce field security.
• Check permissions using Schema.DescribeFieldResult before accessing fields in Apex.
• Document and review FLS enforcement to avoid security loopholes.

4. Using WITH USER_MODE in SOQL

In some scenarios, you might want your Apex queries to execute with the same restrictions as the current user, ensuring that all field-level security and sharing settings are automatically honored. This is where the WITH USER_MODE clause comes into play. When appended to your SOQL query, WITH USER_MODE forces the query to run in user mode, which enforces the same field access and sharing rules that apply to the user interacting with your application.

Example:

In this example, if the logged-in user cannot access the Industry field (or even the record itself due to sharing settings), the query will either filter out that field or return no results, depending on the situation. This clause can simplify your code by reducing the need for manual checks using Schema.DescribeFieldResult ou Security.stripInaccessible(). Cependant, il est important de noter que la requête échouera au moment de l’exécution si l’utilisateur n’a pas les autorisations nécessaires. En tant que meilleure pratique, envisagez d’envelopper de telles requêtes dans les blocs d’essai pour gérer gracieusement les exceptions potentielles.

Conclusion

Alors, pouvons-nous contrôler la sécurité au niveau du champ depuis Apex? Oui, mais pas automatiquement! Apex s’exécute en mode système, ce qui signifie que vous devez appliquer explicitement FLS en utilisant des méthodes comme Schema.DescribeFieldResult, Security.stripInaccessible()et WITH SECURITY_ENFORCED.

En suivant les meilleures pratiques, vous pouvez vous assurer que votre code APEX respecte les autorisations utilisateur et maintient les données sécurisées. La prochaine fois que vous rédigerez une classe APEX qui interagit avec les champs sensibles, n’oubliez pas de vérifier la sécurité du niveau de champ avant d’exposer les données!

Vous voulez en savoir plus sur les meilleures pratiques de sécurité Salesforce? Restez à l’écoute pour des blogs plus perspicaces!