Can we prove security using Apex Tests & System.runAs()?

Question

Let's pretend I am working on a Managed Package app that is soon going to Security Review. I have used all the latest and greatest native features (I know some of them are not GA yet) like as user and WITH USER_MODE to ensure CRUD/FLS and Sharing security.

To avoid overlooking something, I use positive and negative test methods using System.runAs().

Business logic:

public void execute() {
    List<CustomObject__c> records = [SELECT int_Field__C FROM CustomObject__c 
                                    WHERE txt_Field__c = NULL WITH USER_MODE];
    for(CustomObject__c record : packages) {
        record.int_Field__C = calculate(record);
    }
    
    update as user records; 
}

Apex Test:

@IsTest
private static void failsWhenCalledByStandardUser() {

    // Setup
    Exception expectedException = null;

    // Exercise
    try {
        System.runAs(PERSONAS.standardUser) {
            new BusinessLogic().execute();
        }
    }
    catch(Exception ex) {
        expectedException = ex;
    }

    // Verify
    System.assertNotEquals(null, expectedException);
}

Real source code can be found here: https://github.com/rsoesemann/salesforce-isv-cockpit/blob/master/force-app/main/default/classes/SetupPackageNamespaces_Test.cls

Am I right that this indeed should be done to a big extend to finally prove Sharing/CRUD/FLS security of our code?

Answer 1

I must admit, we have not attempted to revisit this side of things - our core managed package is too large and too mature.

What I do know, from the few uses of System.runAs we have, is that this is incompletely and inconsistently implemented (e.g. it is the user in place at the point that Test.stopTest is invoked that dictates the user for async processing - not the user used when submitting the async processing).

UPDATE:

While the documentation says:

The runAs method doesn’t enforce user permissions or field-level permissions, only record sharing.

@Robert Soesemann has tested this and found the documentation to be inaccurate. According to his tests, CRUD/FLS permissions are also applied.

UPDATE 2:

@Daniel Ballinger (Salesforce PM for Apex) confirmed that the above statement from the documentation was being misinterpreted; CRUD/FLS is applied, but the Apex continues to run in system mode.

This suggests that use of System.runAs could be useful in many (but not all) cases to verify behaviour in different permission scenarios. I say not all because there are known and unknown limitations and gotchas (such as the example above).

Answer 2

I think the documentation is correct: runAs only enforces the sharing rules to be applied for the runAs user, not the FLS. However, if you use 'WITH SECURITY_ENFORCED' in your SOQL and/or Schema describe methods to check field accessibility, that will apply to the currently running user FLS.

In our project we faced unexpected behaviour with FLS with this approach (we expected exactly what you describe) and therefor I did some research on this. This is the result:

• Apex test always runs in system mode (see all data, see all objects / fields).
• When using runAs, the code in that block will still run in system mode, but with the exception that record sharing is enforced. The code can only see existing test data that is shared with the runAs user.
• When using Schema describe methods to check accessibility of an object of field, this will be done in user context (FLS access of current user / runAs user defined in profile and permission sets).
• The same counts for using WITH SECURITY_ENFORCED. The FLS access of current user / runAs user is checked for the query performed.

All the above 4 statements are also described in the documentation.

Answer 3

I am getting some value in using System.RunAs(u) to confirm FLS for Users and queries. This is very powerful when the users are in a collection. Then you can loop through the collection, change the System.runAs(u) variable, and test the query for each user.