grzmol Salesforce Org Security Audit
When to use
| Situation | Use this skill |
|---|---|
| Auditing the standing security posture of an org | Yes |
| Preparing for a customer or internal security review | Yes |
| Onboarding an org you did not configure | Yes |
| Reviewing the security of the diff you just wrote | Agent sf-security-reviewer |
| Writing Apex that enforces CRUD, FLS and sharing | Skill sf-security-model |
| Maintainability rather than exposure | Skill sf-technical-debt-audit |
| Callout authentication design | Skill sf-integration-patterns |
| Analyzer security rules on source | Skill sf-code-analyzer-quality |
This audit is read-only: queries, retrieves and greps. It never changes a permission, a setting or a record, and it is legitimate against production.
Scope and safety
| Rule | Why |
|---|---|
Read-only commands only: sf data query, sf project retrieve preview, sf org list ..., vf-check static |
An audit that mutates is an incident |
Never VF_ALLOW_PROD=1 |
That flag exists to let a mutating check through; nothing here needs it |
| Retrieve into a scratch directory, never over the working tree | A retrieved profile overwriting source is a silent change |
| Evidence or it did not happen | Every finding carries a query result, a file:line, or a named Setup page |
| Handle findings like the vulnerability they describe | The report names exposures; treat it as confidential and never paste org ids, usernames or tokens into a public channel |
Production posture: vf-check prints a production banner for read-only checks rather than refusing
them (scripts/checks/lib/org.mjs). Queries against a production alias are fine here. Running
vf-check apex against production is not part of this audit.
Audit layers
| Layer | The question | How to measure |
|---|---|---|
| Identity | Who can log in, from where, with what factor | Setup: session, password, login IP, MFA; sf org list users |
| Grants | Who holds administrative permissions | PermissionSetAssignment SOQL, pattern 3 |
| Access matrix | What each permission set opens up | ObjectPermissions and FieldPermissions SOQL, pattern 4 |
| Record access | Org-wide defaults, sharing rules, without sharing code |
Source <sharingModel> plus grep, pattern 7 |
| Code exposure | @AuraEnabled, @RestResource, webService, Apex class access |
Source inventory plus SetupEntityAccess, pattern 6 |
| Public surface | Guest users, Sites, Experience Cloud | networks/ metadata plus guest profile, pattern 8 |
| Integration | Named and External Credentials, Remote Site Settings, connected apps | Source inventory, pattern 9 |
| Secrets | Literal credentials in source or history | Grep plus git history, pattern 9 |
| Change control | Who changed security settings, and when | Setup Audit Trail, pattern 10 |
Core patterns
1. Fix the scope and the evidence trail
sf org display --target-org vf-prod
sf org list users --target-org vf-prod
mkdir -p .vibeforce/reports/audit && export AUDIT=.vibeforce/reports/audit
Record the org id, the edition, the alias, whether the source tree is the whole org, and the date.
Every command below writes into $AUDIT, so the report can cite raw output rather than memory.
2. Retrieve the security-relevant metadata
<!-- manifest/security-audit.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types><members>Security</members><name>Settings</name></types>
<types><members>*</members><name>PermissionSet</name></types>
<types><members>*</members><name>PermissionSetGroup</name></types>
<types><members>*</members><name>Profile</name></types>
<types><members>*</members><name>SharingRules</name></types>
<types><members>*</members><name>NamedCredential</name></types>
<types><members>*</members><name>ExternalCredential</name></types>
<types><members>*</members><name>RemoteSiteSetting</name></types>
<version>67.0</version>
</Package>
sf project retrieve start --manifest manifest/security-audit.xml \
--target-org vf-prod --output-dir "$AUDIT/metadata"
Retrieving into --output-dir keeps the working tree untouched. The directory layout under it
depends on the retrieve, so locate the retrieved types rather than assuming a path:
find "$AUDIT/metadata" -type d \( -name profiles -o -name permissionsets -o -name permissionsetgroups \
-o -name namedCredentials -o -name externalCredentials -o -name remoteSiteSettings -o -name sharingRules \)
An ls against a guessed path that does not exist prints an error and counts as zero - on a
security audit that reads as a clean result. Always count from find output.
Profiles retrieve as a sparse representation - a permission missing from a retrieved profile is not proof it is not granted, so confirm grants with the queries in patterns 3 and 4 rather than by reading profile XML.
3. Who holds the dangerous permissions
sf data query --target-org vf-prod --json \
--query "SELECT Assignee.Username, Assignee.IsActive, PermissionSet.Name FROM PermissionSetAssignment WHERE PermissionSet.PermissionsModifyAllData = true" > "$AUDIT/modifyalldata.json"
sf data query --target-org vf-prod --json \
--query "SELECT Assignee.Username, PermissionSet.Name FROM PermissionSetAssignment WHERE PermissionSet.PermissionsViewAllData = true" > "$AUDIT/viewalldata.json"
Repeat for PermissionsAuthorApex, PermissionsViewEncryptedData, PermissionsManageUsers and
PermissionsCustomizeApplication [unverified: only PermissionsModifyAllData, PermissionsViewAllData, PermissionsViewAllRecords and PermissionsModifyAllRecords are confirmed field names in this repository - run sf sobject describe --sobject PermissionSet --target-org <alias> before relying on the rest]. Findings, in descending severity:
| Finding | Severity |
|---|---|
An integration or service account holds ModifyAllData |
high |
A named person holds ModifyAllData outside the admin group |
high |
| An inactive user still holds an administrative permission | medium |
ViewAllData granted for a reporting need a report type would satisfy |
medium |
AuthorApex outside the release process |
medium |
A grant that appears through a profile's own permission set still counts as a grant, which is why
profile sprawl (pattern 5) is a security topic and not only a tidiness one. [unverified: the IsOwnedByProfilefield used below to separate profile-owned permission sets from standalone ones was not confirmed in this session - describe the object first, or drop the filter and group byParent.Name.]
4. The access matrix per permission set
sf data query --target-org vf-prod --json \
--query "SELECT Parent.Name, SobjectType, PermissionsRead, PermissionsCreate, PermissionsEdit, PermissionsDelete, PermissionsViewAllRecords, PermissionsModifyAllRecords FROM ObjectPermissions WHERE Parent.IsOwnedByProfile = false" > "$AUDIT/objectperms.json"
sf data query --target-org vf-prod --json \
--query "SELECT Parent.Name, Field, PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE SobjectType = 'Account'" > "$AUDIT/fieldperms-account.json"
Audit the sensitive objects first: anything holding personal data, financial data, or credentials.
PermissionsViewAllRecords and PermissionsModifyAllRecords bypass sharing for that object - each
one needs a named reason, and an object-level bypass granted to a broad permission set is a high
finding.
5. Profile sprawl
find "$AUDIT/metadata" -path "*/profiles/*.profile-meta.xml" | wc -l
find "$AUDIT/metadata" -path "*/permissionsets/*.permissionset-meta.xml" | wc -l
Posture, in order of preference: permission set groups for personas, permission sets for features, profiles reduced to login and default settings. A large profile count with few permission sets means access cannot be reviewed - the finding is "grants are not reviewable", and its severity depends on what those profiles open up (pattern 4), not on the count.
6. Code exposure surface
grep -rn "@AuraEnabled" force-app --include="*.cls" | wc -l
grep -rn "@RestResource\|global class\|webService" force-app --include="*.cls"
grep -rln "without sharing" force-app --include="*.cls"
sf data query --target-org vf-prod --json \
--query "SELECT Parent.Name, SetupEntityId FROM SetupEntityAccess WHERE SetupEntityType = 'ApexClass'" > "$AUDIT/apexclassaccess.json"
Every @AuraEnabled and @RestResource method is an API an authenticated user can call directly:
the client never enforces anything. Check each one for user-mode data access and a sharing keyword
(skill sf-security-model). A generic endpoint - "run this SOQL", "update this record with this
map" - is a high finding regardless of who holds the class access.
7. Record access: org-wide defaults and elevation
grep -rh "<sharingModel>" force-app/main/default/objects/*/*.object-meta.xml | sort | uniq -c
grep -rn "without sharing" force-app --include="*.cls"
grep -rn "__Share\b" force-app --include="*.cls"
An object whose sharing model is ReadWrite needs a reason; Private plus sharing rules is the
defensible default for anything sensitive. Every without sharing class and every Apex managed
sharing insert is an elevation path: it must be narrow, documented, and covered by a negative test
(skill sf-security-model, references sharing-and-record-access.md).
8. Public surface
ls force-app/main/default/networks/ 2>/dev/null
ls force-app/main/default/sites/ 2>/dev/null
grep -rn "Site\.\|Network\.\|UserInfo.getUserType" force-app --include="*.cls"
If the org has Sites or Experience Cloud, the guest user is an unauthenticated identity with real
permissions. Audit it as its own user: what objects it reads, which Apex classes it can run, which
Flows it can start, and whether any without sharing code runs on its behalf. Guest access to
person data is a high finding on sight, and personal-information visibility settings on the User
object are not enforced by user mode or stripInaccessible (skill sf-security-model, reference
crud-fls-enforcement.md).
9. Integrations and secrets
find "$AUDIT/metadata" -path "*/namedCredentials/*" -type f
find "$AUDIT/metadata" -path "*/externalCredentials/*" -type f
find "$AUDIT/metadata" -path "*/remoteSiteSettings/*" -type f
grep -rniE "password|secret|token|api[_-]?key|authorization" force-app --include="*.cls" --include="*.js" --include="*.xml"
git log -p --all -S"password" -- force-app | head -100
A Remote Site Setting with no matching Named Credential usually means a callout is authenticating by hand, with the credential somewhere in source. A secret found in git history is still a secret: the finding is "rotate the credential", not "remove the line".
10. The Setup-only layer
No CLI command covers these; a person opens Setup and records the answer. They belong in the report with the same severity scale as everything else.
| Check | Setup location | Looking for |
|---|---|---|
| Health Check score and risks | Security → Health Check | Score, and every High-Risk setting against the baseline |
| Session settings | Security → Session Settings | Timeout, lock to IP, clickjack protection, HttpOnly |
| Password policy | Security → Password Policies | Expiry, history, complexity, lockout |
| MFA | Identity → and the MFA assistant | Every interactive user covered |
| Login IP ranges and login hours | Profiles | Admin profiles restricted |
| Connected apps and OAuth scopes | Apps → Connected Apps | full and refresh_token scopes, who approved them |
| API access | Profiles and permission sets | API Enabled on people who do not integrate |
| Certificate and key management | Security → Certificate and Key Management | Expiry dates |
| Setup Audit Trail | Security → View Setup Audit Trail | Security changes in the last 6 months, and by whom |
| Shield Platform Encryption, Event Monitoring | Depends on licensing | Whether they are available and used |
[unverified: whether the Health Check score, session settings and Setup Audit Trail are readable through the API in this org's edition was not confirmed in this session. Treat this layer as manual until you verify it with sf sobject describe against the relevant object.]
11. The report
## Security audit - <org alias> - <ISO date>
Scope: <what was audited> Not audited: <what was out of reach>
| severity | layer | finding | evidence | fix | owner |
| --- | --- | --- | --- | --- | --- |
severities: high (data exposure or privilege escalation available today)
medium (grant wider than needed, or a control with a gap)
low (hardening opportunity, no current exposure)
## Setup-only layer
| check | result | finding |
## Accepted risks
<item> - <accepted by whom> - <review date>
Write it to .vibeforce/reports/security-audit-<ISO>.md. A re-run diffed against the previous
report is what turns an audit into a control.
Anti-patterns
| Anti-pattern | Consequence | Fix |
|---|---|---|
| Reading retrieved profile XML and concluding a permission is absent | Profiles retrieve sparsely; the grant may still exist | Confirm with ObjectPermissions and PermissionSetAssignment queries |
| Auditing source only | Org-only grants and Setup settings stay invisible | Retrieve, query, and record the Setup-only layer |
| Reporting "too many profiles" as the finding | Count is not exposure | Name what the profiles grant, with evidence |
| Fixing a finding during the audit | The audit becomes an unreviewed change | Report; remediate through the normal gated path |
| Running the audit as an integration user | You see only what that user sees | Run as an admin, and say which user produced the evidence |
| Pasting query output with usernames or org ids into a ticket | The report becomes the exposure | Redact identities; reference row counts and ids held separately |
| Treating a clean Code Analyzer run as a security audit | Static rules cover code, not grants | Both; they measure different layers |
Leaving [unverified] items out of the report |
Unknowns read as passes | List them under "Not audited" |
Verification
# static security rules over the whole tree, not the diff
node "${CLAUDE_PLUGIN_ROOT}/scripts/checks/vf-check.mjs" analyzer --json
node "${CLAUDE_PLUGIN_ROOT}/scripts/checks/vf-check.mjs" static --json
# grants, read-only, production-safe
sf data query --target-org vf-prod --query "SELECT COUNT(Id) FROM PermissionSetAssignment WHERE PermissionSet.PermissionsModifyAllData = true"
# what a retrieve would bring back, without touching the working tree
sf project retrieve preview --target-org vf-prod
Exit codes: 0 pass, 1 gate failed, 2 misconfiguration or missing tool, 3 org or network
error. A finding in this audit is not a vf-check failure - the gates run on the diff; the audit
runs on the org. Both belong in the report.
References
references/org-security-checklist.md- the full checklist: per-layer checks, the query or Setup path, the expected answer, and the severity when it differs.- Related skills:
sf-security-model(enforcement in code, permission architecture, sharing),sf-technical-debt-audit(the maintainability half of the same sweep),sf-integration-patterns(Named and External Credentials),sf-code-analyzer-quality(security rules and custom regex rules),sf-data-management(data exports and PII handling),sf-debugging-logs(Event Monitoring). - Agent
sf-security-reviewerfor the per-diff review that this audit does not replace. - Official: Apex Security and Sharing, Enforce User Mode, stripInaccessible, Named Credentials.