apex-security-hardening

Harden Apex controllers with USER_MODE CRUD/FLS enforcement and least-privilege permission sets.

33|12|Updated Sep 24, 2024
One-click install
npx skills add https://github.com/bgaldino/rlm-base-dev --skill apex-security-hardening-bgaldino
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: apex-security-hardening
Source: https://github.com/bgaldino/rlm-base-dev/tree/main/.cursor/skills/apex-security-hardening
Command: npx skills add https://github.com/bgaldino/rlm-base-dev --skill apex-security-hardening-bgaldino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Salesforce Apex controllers often run SOQL and DML in system mode, bypassing the caller's CRUD and field-level security, while permission sets are over-granted or silently misconfigured. This Skill provides a canonical workflow to enforce USER_MODE access and build self-sufficient, least-privilege permission sets that survive deployment and audit review. ## Core Features & Use Cases - USER_MODE Conversion: Detects every system-mode static SOQL query reachable from @AuraEnabled, @InvocableMethod, VF, or webservice entry points and converts them to WITH USER_MODE with correct clause placement, plus DML converted to as user. - Permission-Set Derivation: Enumerates the user-mode object and field surface from the code, cross-checks field permissionability via sf sobject describe, and builds exact objectPermissions and fieldPermissions with no over-grants. - Deploy Verification: Reads the permission set back from the org with ObjectPermissions/FieldPermissions queries to catch silent drops (master-detail children, compound address fields) and validates sufficiency with persona walks or System.runAs tests. - Use Case: Before a Salesforce security audit, run the hardening pass on a quoting feature: convert all controller queries to USER_MODE, derive the permission set from the code, deploy it, and prove org state matches the file. ## Quick Start Audit my Apex controller for system-mode SOQL, convert every entry-reachable query to WITH USER_MODE, and generate a least-privilege permission set covering exactly the objects and fields the code touches.

Frequently Asked Questions about apex-security-hardening

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce CRUD and FLS in Apex controllers?

Add WITH USER_MODE to every static and dynamic SOQL query reachable from @AuraEnabled, @InvocableMethod, VF, or webservice entry points, and change DML to `insert/update/delete as user`. Place WITH USER_MODE after the WHERE clause and before GROUP BY, ORDER BY, or LIMIT.

How do I build a least-privilege Salesforce permission set from Apex code?

Enumerate every object and field touched by user-mode queries and DML, then check which fields are permissionable using `sf sobject describe`. Grant objectPermissions for each object and fieldPermissions only for permissionable fields, with editable=true only where the code writes.

Why does my permission set deploy succeed but object permissions are missing?

Master-detail child objects have their CRUD controlled by the master, and the platform silently drops child object permissions on deploy. Grant the master object instead, for example Quote read/edit covers QuoteLineItem and QuoteLineGroup.

Why do I get 'Invalid field permission field name' for address fields?

Standard compound-address components like BillingStreet and ShippingCountry report permissionable=true but reject permission-set fieldPermissions. Drop the FLS row because object-level read access already covers these fields.

Do passing Apex tests prove my permission set is sufficient?

No. Tests run as admin and bypass FLS, so a green suite does not prove the permission set works. Verify with a System.runAs test or by assigning only the permission set to a non-admin user and walking the flows.

When should I not use this hardening workflow?

Do not use it for deciding where to place new Apex code (force-app vs unpackaged) or for force-app profile rules, which follow separate repository guidelines. It is specifically for CRUD/FLS hardening and permission-set self-sufficiency.