Salesforce security glossary

Permissions and identities

Profile

The profile is the entitlement foundation of a Salesforce user: every account carries one, and only one. It is tied to a user license and carries a first set of object, field and system permissions.

Salesforce itself models it as a particular permission set — the one whose IsOwnedByProfile flag is true. Practical consequence: reading the assignments of a user brings back their profile and their permission sets in the same response.

Permission set

A permission set is a bundle of permissions assignable to a user on top of their profile, with no limit on the number. A permission set group brings several of them together under a single assignment.

Permissions add up: a permission set widens what the profile grants, it does not restrict it — except by explicit muting inside a group. A permission set with no active holder remains an available grant surface: it costs nothing as long as nobody receives it, and everything the day somebody does.

Effective permissions

The effective permissions of a user are the union of everything granted by their profile and by each of their assigned permission sets. That is the only view which says what an account can actually do.

No native screen displays it in a form usable across a whole org. Which is why an access review conducted profile by profile structurally misses accumulations: it examines layers, not sums.

Toxic permission

A toxic permission is a set of privileges whose combination on a single account enables an action that none of those privileges enabled on its own. None of the elements is abnormal in isolation: that is what explains why it survives reviews conducted permission by permission.

The form most documented on Salesforce pairs Modify All Data or View All Data, API access enabled, and the absence of a second factor. A compromised credential then becomes full access, with no human interaction and no interface trail. The common combinations, in detail.

Blast radius

The blast radius of an account is the extent of what an attacker taking control of it would obtain. On a Salesforce org it is measured on the effective permissions: reach of reads and writes, API access, ability to grant permissions to other accounts.

The notion moves the question from “is this permission legitimate?” to “what happens if this account falls?”. It is the second one that correctly ranks a population of privileged accounts.

Integration account

An integration account is a Salesforce user that corresponds to no person: it carries the authentication of a third-party system, of an ETL or of a middleware.

It concentrates two opposing tensions: it is granted broad permissions because it automates, and it is spared the second factor for the same reason. An integration account that also carries Modify All Data amplifies the blast radius of the slightest credential leak, and it has nobody to report that it is behaving abnormally.

Multi-factor authentication (MFA)

On Salesforce, the multi-factor authentication requirement is carried by a system permission assigned through a profile or a permission set, not by a global org setting. A user who receives that permission through none of their assignments is not covered by it.

The MFA coverage of an org is therefore a population to enumerate, not a box to tick. Useful caveat: an org that delegates the second factor to its identity provider does not express it through this permission — the real state of an account is not always deducible from a single reading, and an honest measurement says so.

Data visibility

OWD (organization-wide default)

The organization-wide default (OWD) sets, object by object, what a user sees of the records they do not own. It is the visibility floor: sharing rules, the role hierarchy and manual shares can only widen it.

Salesforce holds two distinct values per object, one internal and one external. An object set to public read/write on the external side is the widest exposure an org can declare: it reaches community and portal users.

Sharing

Sharing is the mechanism by which Salesforce decides, record by record, who sees what beyond the floor set by the OWD: sharing rules, role hierarchy, manual sharing, code-managed sharing.

It is bypassed by code and by automation. An Apex class declared without sharing, or a flow running in system mode without sharing, reads records without applying the visibility of the current user — nor their field-level security. Those executions are legitimate in some cases and invisible in all: they are inventoried, they are not guessed.

FLS (field-level security)

Field-level security (FLS) determines which fields of an object a profile or a permission set can read and edit. It is independent of object permissions: a user allowed to read a record can be denied one of its fields.

This is the layer where the exposure of regulated data plays out — social security number, IBAN, health data, salary, date of birth. The worst case is not a sensitive field readable by too many internal users, but a sensitive field readable by a guest profile or by an external profile.

Guest profile

The guest profile is the profile taken on by any unauthenticated visitor to an Experience Cloud site. Its object permissions therefore apply to anyone who reaches the URL of the site.

A read permission granted there is a publication. A create, edit or delete permission lets an anonymous visitor write into the org — and a View All or Modify All permission on an object exposes the whole table there. That is access control, not site configuration; it is re-read with the same eyes as a privileged internal profile.

Experience Cloud

Experience Cloud is the Salesforce building block that publishes sites — customer portals, partner spaces, public sites — backed by the data of the org.

It moves the boundary of the org: the same objects then serve internal users, authenticated external users and anonymous visitors, each with their own layer of permissions. External sharing and the guest profile become front-line controls, not web-project settings.

Application access and outbound flows

Connected app

A connected app is the declaration, inside a Salesforce org, of an external system authorised to authenticate and to call its API. Every authorisation granted by a user produces a token that stays valid until it is explicitly revoked.

An app authorised two years ago therefore keeps its access for as long as nobody withdraws it. The useful question is not “who has access?” but “which scopes were granted, to what, and which ones are still in use?”. A token never used is a permanent credential that has been forgotten.

OAuth scope

An OAuth scope delimits what a token allows: api for data access, web for the session, refresh_token for renewal without re-authentication, full for everything the bearer user can do. full granted to an integration that only needs to read a list is the textbook case of excessive privilege.

It is not equally readable depending on the declaration model. External client apps expose a flag per scope, so the scope is read there. A classic connected app exposes no scope at all to the Apex API: what is said about it then is an inference, and a serious tool states which of the two it is showing you.

Named Credential

A Named Credential is a Salesforce configuration object that ties a destination URL to an authentication method, and that code calls by name without ever handling the secret.

It has a second virtue, often overlooked: it is the most reliable inventory of the outbound destinations of an org. What the code actually calls is declared there, which makes it the natural starting point for mapping third-party flows.

Certificate

In a Salesforce org, “certificate” means two different things: the one the org presents to authenticate with a third party, and the TLS certificate presented by an endpoint it calls. The former are stored in the org with their expiry date; the latter belong to the remote server.

The distinction is operational: code running in an org cannot read the certificate of a remote peer. Watching those expiry dates requires a probe outside the org, and internal expiry dates are no more a matter of plain reading: they live in the Tooling Certificate object, reached through a self-callout via a Named Credential. In both cases, an expired certificate brings integrations down overnight, without any configuration having changed.

How the platform holds up

Governor limit

A governor limit is a ceiling Salesforce applies to a single transaction: 50,000 rows read in SOQL, 10,000 rows modified, 100 queries in synchronous context. Exceeding it raises an exception the code cannot catch: the transaction is rolled back in full.

Not to be confused with org limits — API calls over 24 hours, data and file storage, asynchronous processing — which are consumed over a rolling window and measured as a percentage of a quota. The former are exceeded abruptly and block a process; the latter fill up slowly and are watched by their remaining headroom.

EPT (Experienced Page Time)

EPT (Experienced Page Time) is the time, in milliseconds, between the request for a Lightning page and the moment the user can actually use it. Salesforce publishes it per page view in the Event Monitoring log files, and not in an object queryable in SOQL.

Two consequences. Without Event Monitoring, the measurement does not exist in the org. And an average EPT says nothing useful: it is the high percentiles that describe what the tail of users goes through — the ones who open the tickets.

Configuration drift

Configuration drift is the gap between the state of an org at a given moment and its earlier reference state. It presumes neither fault nor attack: it records that a profile, a permission set or a connected app is no longer what it was at the last reading.

It is detected by comparing fingerprints rather than values — a cryptographic fingerprint of the state, per component — which makes it possible to say “this has changed” without keeping the detail of what changed. Corollary: the first measurement can detect nothing, it sets the reference.

The vocabulary of measurement

Finding

A finding is the unit of result of a posture analysis: an identified problem, its target, its severity and the message that explains it. It carries a deduplication key, so that the same problem seen again at the next analysis updates the existing finding instead of creating a new one.

From that follow two counters worth more than a raw volume: the number of occurrences, which separates the recurrent from the isolated, and the number of regressions, which counts the times the problem came back after being closed — that is to say, the fixes that did not hold.

Severity

Severity classifies a finding on a closed scale — Info, Low, Medium, High, Critical — and determines its handling priority.

A scale is worth something only if each level weighs on a measurable index: otherwise it is a label, and everything ends up “high”. The usual model subtracts points from an index starting at 100, more for a critical than for a medium, nothing for an item of information.

Exposure in euros

Exposure in euros translates a population of open findings into a single amount: the number of findings in each severity-category pair is multiplied by a weighting in euros, then summed. It is an estimation model, of the simplified-FAIR family — not an observed loss.

Its value depends entirely on the weightings chosen, which are a parameter of the company and not a market datum. An amount published without its weightings cannot be checked. What it serves to do is to rank two work queues, not to provision a risk.

Compliance

DORA

DORA (EU Regulation 2022/2554, applicable since 17 January 2025) imposes a digital operational resilience framework on the financial entities of the Union. The entry criterion is the activity carried out, not the size; size then bears on how intense the obligations are.

On the Salesforce org side, five articles are technically observable: 7 (upkeep of systems), 8 (risk identification), 9 (protection and prevention), 10 (detection of anomalous activity) and 28 (third-party provider risk). The rest belongs to governance, to the contract or to the organisation: no org detector sees them. Article by article, in detail.

NIS2

NIS2 (EU Directive 2022/2555) imposes cybersecurity risk-management measures on the entities of the sectors listed in Annexes I and II, with a threshold in principle of 50 employees or €10 million turnover — the criterion is alternative. It is the national transposition that sets the applicable scope, not the directive on its own.

Its technical requirements are concentrated in Article 21(2), which has ten points. Six touch a Salesforce org: (b), (d), (e), (f), (h) and (i). The other four remain out of reach of an org detector, for two distinct reasons: (a), (c) and (g) are organisational requirements; (j) also covers secured voice, video and text communications, which do not live inside an org. One and the same company can fall under both NIS2 and DORA.

Partial mapping

A partial mapping links a piece of technical evidence to a regulatory requirement of which it observes only one facet. It stands against a full mapping, where the evidence covers what the article names.

Example: an inventory of connected apps that compares their names against a list of known export tools informs the supply-chain control requirement — it says nothing about the OAuth scopes actually granted. Declaring the scope of each mapping is what makes a compliance map defensible in front of an auditor; not declaring it turns a correspondence table into decoration. In our own map, 95 mappings out of 118 are declared partial.