An independent audit of who can see and change what in your Salesforce org — sharing model, profiles and permission sets, field-level security, Experience Cloud guest access and every integration credential. Run by senior engineers who build on the platform, and delivered as a severity-ranked findings register with a remediation plan your team can actually execute.
A Salesforce security review is a structured audit of how a Salesforce org controls access to data and functionality. It examines the org's sharing model (organization-wide defaults, role hierarchy, sharing rules and manual or programmatic shares), its permission architecture (profiles, permission sets and permission set groups), and field-level security, then verifies that custom code — Apex, Lightning components and API-exposed endpoints — enforces those controls rather than bypassing them. The review also covers the org's edges: Experience Cloud sites and their guest-user access, connected apps, OAuth configurations, integration users and stored credentials. The output is a findings register that ranks each weakness by severity and exploitability, plus a remediation plan. A security review differs from a penetration test in that it works primarily from configuration and source, not from outside probing, which lets it find latent exposures — data a user could reach but has not — before they become incidents.
Salesforce access control is layered, and every layer can be misconfigured independently. Record access is governed by the sharing model. Object and field access is governed by profiles and permission sets. And custom code can bypass both if it is written carelessly. A review that only looks at one layer — usually profiles, because they are visible in Setup — misses most real-world exposure.
Organization-wide defaults (OWD) set the baseline visibility for each object: Private, Public Read Only or Public Read/Write. From that baseline, access widens through the role hierarchy, sharing rules, account and opportunity teams, manual shares and Apex managed sharing; restriction rules are the narrow exception that can take access away. The critical property is that sharing is additive — once an OWD is public, no sharing rule can claw it back. That makes the OWD table the single most consequential screen in the org, and the one we check first.
Profiles historically carried object CRUD permissions, field-level security (FLS), tab visibility and system permissions. Salesforce's stated direction is permission-set-led access management, with profiles retained for defaults such as record types and login policy — check current Salesforce documentation for the timeline. In a well-run org, permission sets and permission set groups model job functions, profiles are minimal, and nobody holds View All Data or Modify All Data without a documented reason. FLS decides whether a field is readable or editable at all. It is enforced in the UI, in reports and in the standard APIs — but not automatically inside custom code.
Apex runs in system mode by default. Unless a developer opts in — with sharing declarations on classes, WITH USER_MODE in SOQL and DML, or Security.stripInaccessible on query results — code sees every record and every field regardless of what the running user is allowed to see. Aura-enabled controllers, Apex REST endpoints and flows launched from public pages are all entry points where system-mode logic meets untrusted callers. This is why a security review reads code, not just configuration; our Salesforce code review guide covers the same lens in depth.
Salesforce orgs drift. Admins change, companies merge, AppExchange packages install their own permission sets, and deadline-driven fixes grant broad access "temporarily." Meanwhile the org accumulates the most sensitive data the company holds: customer records, pricing, contracts, bank details, health information. Salesforce secures the platform; securing your configuration of it is explicitly your job, and it is where nearly all real incidents originate. For the regulated industries we work in — banking, insurance, healthcare-adjacent businesses — a periodic independent review is also an audit expectation, not a luxury. A broader Salesforce health check will flag that something is off; a security review tells you exactly what, how bad, and in what order to fix it.
Every org is different; the failure patterns are not. These eight account for most of the critical findings in the reviews we run.
OWD set to Public Read/Write on objects holding sensitive data, with the exposure hidden only by tab visibility. Every API-enabled user can read all of it.
Dozens of cloned legacy profiles, with View All Data or Modify All Data granted once to unblock a ticket and never revoked. Nobody can say who can see what.
Fields removed from layouts but still readable through reports, list views and the API. Layouts are user experience, not security — FLS is the control.
Controllers running without sharing enforcement that return records the caller should never see, and dynamic SOQL concatenated from user input — an injection risk.
Middleware logging in as System Administrator to touch two objects, and credentials shared across integrations so that nothing can be revoked safely.
API keys hardcoded in Apex or sitting in custom settings and custom metadata, readable by anyone with the right object access, instead of stored in Named Credentials.
Guest profiles with create or edit on core objects, guest sharing rules wider than the use case, and unauthenticated Apex endpoints nobody remembers shipping.
OAuth apps with full scopes, no IP policy and long-lived refresh tokens — some belonging to vendors or employees who left years ago.
Every public page on an Experience Cloud site executes as the site's guest user — an unauthenticated identity with its own profile, its own object permissions and its own sharing entitlements. Anything that identity can reach, the entire internet can reach. Salesforce has tightened the defaults considerably: secure guest-user record access means guests cannot own records after creation, guest sharing rules grant read-only access, and guests get no role-hierarchy visibility. Those defaults help, but they do not close the org-level gaps we find repeatedly.
The recurring exposures: object and field permissions granted directly on the guest profile; Aura-enabled Apex methods the guest can invoke, returning data in system mode; flows launched from public pages running in system context; self-registration handlers that create records with elevated logic; and content, documents or CMS assets shared more broadly than intended. Individually each looks small. Chained together, they have produced the pattern of public data leaks that made Salesforce change the guest defaults in the first place.
In a review, we enumerate the complete guest-reachable surface — objects, fields, Apex classes, flows and REST endpoints — and then validate it by acting as the guest against a sandbox copy of the site. The result is a definitive statement of what an anonymous visitor can read, create or trigger. For the engineering detail behind this methodology, see our guide to securing Experience Cloud sites.
Most orgs have more machine identities than they think, and machine identities do not get offboarded when people leave. On the inbound side, every integration should be its own connected app with the narrowest OAuth scopes that work, admin pre-approval, IP restrictions where the caller is fixed, and deliberate token-lifetime policies. Server-to-server traffic belongs on the JWT bearer flow or the client credentials flow with a dedicated integration user; username-password logins for integrations should be retired outright. The discipline that makes all of this auditable is one integration, one user, one permission set — so access can be measured, monitored and revoked without collateral damage.
On the outbound side, Named Credentials and External Credentials should hold every endpoint and secret, so Apex callouts never embed passwords, tokens or URLs in code or unprotected metadata. They also centralize certificate handling for mutual TLS and make rotation an admin task instead of a deployment. During a review we inventory every connected app, integration user, named credential, certificate and remote-site setting, map each to an owner and a purpose, and flag what cannot be explained. Where the review exposes deeper design problems — point-to-point sprawl, shared credentials, no event strategy — that becomes input to our Salesforce integration practice rather than a finding to patch.
Clouderia has been engineering on Salesforce since 2010, with 46 certified experts across Provo and Prague and delivery experience in the industries where security review is table stakes: financial services, insurance, telco, nonprofit, automotive and SaaS. The people running your review are senior engineers who design sharing models and write hardened Apex for a living — not checklist auditors reading a scanner report back to you. Scanners are part of the toolkit; judgment about what is actually exploitable in your org is the product.
Agree the orgs, sites, code bases and integrations in scope. We take read-only access and extract metadata, permission and sharing configuration for offline analysis.
Map the sharing model, build a who-can-see-what matrix across profiles and permission sets, review Apex, LWC and the API surface, and inventory every connected app and credential.
Confirm high-impact findings hands-on in a sandbox: act as the guest user, the integration user and a low-privilege user. We report verified exposure, not theory.
Severity-ranked findings register with evidence and concrete fixes, walked through with your admins and developers. Optional re-test after remediation.
When findings point at structural causes — a sharing model fighting the org design, or an integration landscape with no pattern — we recommend extending into a full Salesforce architecture review. Remediation itself can be done by your team with our guidance, by our engineers as a follow-on project, or continuously through managed services. The security review is one of the engineering services we deliver; it is deliberately scoped so you can buy the audit alone, with no obligation to buy the fixes from us.
Most single-org reviews run two to four weeks end to end. The first week covers access setup and metadata extraction, the middle phase is analysis and validation, and the final week is spent writing findings and walking your team through them. Very large orgs, multiple Experience Cloud sites or a big custom code base extend the analysis phase; a narrow scope such as guest-user access only can be shorter.
Cost is driven by scope: the number of orgs, the size of the permission and sharing model, how much custom Apex and LWC code needs review, and whether Experience Cloud sites and integrations are included. A focused review of one org is a fixed-fee engagement; multi-org estates or reviews combined with remediation are scoped individually. We quote after a short scoping call, and the quote is the price.
No. Analysis runs read-only against metadata and configuration exports, and anything that needs hands-on validation — such as confirming what a guest user or integration user can actually reach — is done in a sandbox that mirrors production. We do not run penetration tests against production without explicit written agreement, and we never change production configuration ourselves during the review.
No. The AppExchange security review is Salesforce's own certification process for ISVs publishing managed packages. Our service is an org-level audit for companies running Salesforce: it examines your sharing model, permissions, code and integrations, not a product you sell. If you are an ISV preparing a package submission, we can help you get through Salesforce's process, but that is a separate engagement.
Yes. Shield adds encryption at rest, event monitoring and field audit trail — valuable controls, but none of them fix a public-read-write sharing default, an over-permissioned integration user or Apex that ignores field-level security. Shield tells you more about what happened; a security review reduces what can happen. The two are complementary, and we often use Shield event data as an input to the review.
A health check is a broad, fast scan of org quality; an architecture review examines how the whole system is designed. A security review goes deep on one dimension: who can see and change what, and how the org can be attacked or leaked. The three share method and can be combined, but security findings get exploit-style validation and a severity model the broader reviews do not.
Both. Every finding ships with a concrete remediation recommendation, and most clients ask us to implement the critical fixes ourselves — typically the sharing model corrections, permission set restructuring and Apex hardening. Lower-severity items usually go into your team's backlog with our guidance. If you want ongoing coverage after remediation, our managed services team can take ownership of security regressions release over release.
A short scoping call is enough to size the review and give you a fixed quote. Read-only access, no disruption, and a findings register you can act on.