Skip to main content

Sharing-rule field and record-type leakage

Sharing rules open up records that the org-wide defaults keep private. That is their job. The risk is when a rule opens a record to a broader audience than intended, exposing a sensitive field or a sensitive record type to a group that should not see it. Vulkro reads every *.sharingRules-meta.xml file and flags the two leakage shapes below.

sf-sharing-leak-field​

A sharing rule that exposes a record containing a sensitive field to a broad recipient.

What triggers it. A criteria-based or owner-based sharing rule whose target object holds a field Vulkro classifies as sensitive (tier-1 or tier-2 PII, a credential or token field, a financial or government-identifier field) and whose <sharedTo> is a broad recipient: a Role, RoleAndSubordinates, a public Group, or AllInternalUsers. The rule grants access at the record level, and Salesforce record access carries the record's fields with it, so a broad share of the record is a broad share of every sensitive field on it.

Why it matters. Field-level security can restrict a field on a profile, but a sharing rule operates at the record grain. If the broad recipient's profile has read on the sensitive field, the sharing rule is what actually delivers the record carrying that field to them. The finding names the rule, the object, the sensitive field that motivated the flag, the access level, and the recipient so a reviewer can decide whether the share is intended.

How to fix. Narrow the <sharedTo> to the specific group that needs the record, lower the <accessLevel> from Edit to Read where edit is not required, or remove the sensitive field's exposure by restricting it through field-level security on the recipient's profile and permission sets. If the broad share is genuinely intended, confirm the recipient population is appropriate for the sensitive field and record the decision.

sf-sharing-leak-recordtype​

A sharing rule that exposes a sensitive record type to a broad recipient.

What triggers it. A sharing rule whose criteria select records of a record type Vulkro treats as sensitive (for example a record type used to segregate restricted, regulated, or internal-only records) and whose <sharedTo> is a broad recipient as defined above. Record types are frequently used as the partition between data that different populations may see; a broad share that crosses a record-type boundary collapses that partition.

Why it matters. Teams often rely on record type as the de facto access boundary ("the Restricted record type is only for Legal"). A sharing rule that shares that record type to a broad role hierarchy quietly defeats the boundary without changing a single profile, so the exposure is easy to miss in a profile-by-profile review.

How to fix. Restrict the rule's recipient to the population the record type is meant for, or split the rule so the broad share applies only to the non-sensitive record types. Where the record-type partition is load-bearing for compliance, treat any cross-partition sharing rule as requiring explicit sign-off.

Example: a triggering pattern​

<!-- Case.sharingRules-meta.xml -->
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
    <sharingCriteriaRules>
        <fullName>Share_Escalations_Broadly</fullName>
        <accessLevel>Edit</accessLevel>
        <criteriaItems>
            <field>RecordTypeId</field>
            <operation>equals</operation>
            <value>Restricted_Medical</value>
        </criteriaItems>
        <sharedTo>
            <allInternalUsers></allInternalUsers>
        </sharedTo>
    </sharingCriteriaRules>
</SharingRules>

sf-sharing-leak-recordtype fires: a sensitive record type (Restricted_Medical) is shared with edit access to every internal user. If the records also carry a sensitive field, sf-sharing-leak-field fires alongside it.

Example: a pattern that does not trigger​

<!-- Case.sharingRules-meta.xml -->
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
    <sharingCriteriaRules>
        <fullName>Share_With_Support_Queue</fullName>
        <accessLevel>Read</accessLevel>
        <criteriaItems>
            <field>Priority</field>
            <operation>equals</operation>
            <value>High</value>
        </criteriaItems>
        <sharedTo>
            <group>Tier2_Support</group>
        </sharedTo>
    </sharingCriteriaRules>
</SharingRules>

The criteria do not select a sensitive record type, the recipient is a single scoped group rather than a broad role or all internal users, and the access level is read-only. No leakage finding emits.

Where to go next​