Mit dem Summer ’26 Release führt Salesforce eine Reihe von Änderungen ein, die auf den ersten Blick technisch wirken. Wer genauer hinschaut, erkennt jedoch eine deutlich größere Entwicklung:
Salesforce verändert grundlegend, wie Sicherheit in Apex und SOQL behandelt wird.
Die zentrale Botschaft lautet, Sicherheit soll nicht mehr aktiv eingebaut werden müssen. Sicherheit soll der Standard sein. Für Entwickler, Architekten und technische Verantwortliche ist das eine der bedeutendsten Security-Anpassungen der letzten Jahre.
Das bisherige Problem?
Viele Apex-Entwickler kennen die Situation:
Eine SOQL-Abfrage funktioniert im Test, liefert Daten und erfüllt ihren Zweck.
Doch die Frage, ob der ausführende Benutzer diese Daten tatsächlich sehen darf, musste bisher häufig separat betrachtet werden.
Standardmäßig liefen viele Abfragen im sogenannten System Context. Dadurch konnte Code auf Felder und Datensätze zugreifen, für die der Benutzer selbst möglicherweise keine Berechtigung besaß.
Zwar existierten Mechanismen wie:
- Sharing Rules
- WITH SECURITY_ENFORCED
- Schema.Describe-Aufrufe
- FLS-Prüfungen
doch deren Verwendung lag letztlich in der Verantwortung des Entwicklers.
Die Folge:
Sicherheitsprüfungen wurden teilweise vergessen, unvollständig implementiert oder im Laufe der Zeit umgangen.
Der Paradigmenwechsel
Mit Summer ’26 verfolgt Salesforce einen anderen Ansatz.
Statt Entwicklern die Verantwortung für jede einzelne Sicherheitsprüfung zu überlassen, soll der Benutzerkontext künftig stärker automatisch berücksichtigt werden.
Die Plattform bewegt sich weg von:
“Der Entwickler muss Sicherheit aktiv einschalten”
hin zu:
“Sicherheit ist aktiv, sofern nichts anderes festgelegt wird”
Genau das versteht Salesforce unter Security by Default.
Warum das sinnvoll ist
Aus Security-Sicht ist dieser Schritt längst überfällig!
In vielen Unternehmen entstehen Risiken nicht durch böswillige Entwickler oder schlechte Architekturentscheidungen.
Die meisten Sicherheitsprobleme entstehen durch:
- Zeitdruck
- fehlende Berechtigungskonzepte
- fehlende Dokumentation
- historische Altlasten
- inkonsistente Entwicklungsstandards
Je mehr Sicherheitsentscheidungen automatisch durch die Plattform getroffen werden, desto geringer wird die Wahrscheinlichkeit menschlicher Fehler.
Genau diesen Ansatz verfolgen moderne Cloud-Plattformen seit Jahren.
Was bedeutet das für bestehende Anwendungen?
Je größer und älter eine Salesforce-Organisation ist, desto wahrscheinlicher werden solche Szenarien.
Hier wird es spannend.
Viele bestehende Anwendungen basieren auf Annahmen, die künftig nicht mehr automatisch gelten.
Typische Fragen sind:
- Welche Abfragen erwarten Systemzugriff?
- Wo werden Felder verwendet, die nicht jeder Benutzer sehen darf?
- Welche Komponenten verlassen sich auf implizite Berechtigungen?
- Welche Integrationen wurden nie unter realen Benutzerrechten getestet?
Je größer und älter eine Salesforce-Organisation ist, desto wahrscheinlicher werden solche Szenarien.
So behebt Ihr das Problem: Ihr gebt nun ausdrücklich an, wie eure Abfrage ausgeführt werden soll.
Query Style
Beispiel
Bedeutung
Impliziter Modus
List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account];
Risiko: Ohne explizite Angabe entscheidet der Standardmodus der API-Version. Ab API 67.0 kann das zu anderem Verhalten führen als erwartet.
User Mode
List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account WITH USER_MODE];
Best Practice: Salesforce berücksichtigt die Berechtigungen des ausführenden Benutzers.
System Mode
List<Account> accounts = [SELECT Id, Name, AnnualRevenue FROM Account WITH SYSTEM_MODE];
Mit Vorsicht nutzen: Salesforce führt die Query bewusst im Systemkontext aus.
Abschied von WITH SECURITY_ENFORCED
Ein weiteres Signal für den Strategiewechsel ist die zunehmende Ablösung von:
WITH SECURITY_ENFORCED
Lange Zeit galt diese Klausel als Best Practice, um Feld- und Objektberechtigungen bei SOQL-Abfragen zu berücksichtigen. Mit den neuen Sicherheitsmechanismen verliert dieser Ansatz jedoch an Bedeutung.
Die Richtung ist klar:
Sicherheit soll nicht länger über zusätzliche Spezialkonstrukte aktiviert werden müssen, sondern Teil des Standardverhaltens werden.
Security ist kein reines Entwickler-Thema
Die Änderungen betreffen zwar unmittelbar Apex- und SOQL-Entwickler. Die Auswirkungen reichen jedoch deutlich weiter. Architekten müssen bestehende Lösungen bewerten.
Administratoren sollten verstehen, welche Berechtigungen tatsächlich benötigt werden.
Unternehmen müssen sicherstellen, dass Rollen- und Berechtigungskonzepte sauber gepflegt werden.
Denn je stärker Salesforce Benutzerrechte technisch durchsetzt, desto sichtbarer werden Unstimmigkeiten in historisch gewachsenen Berechtigungsstrukturen.
Ein Trend, den wir bereits kennen
Interessant ist, dass Salesforce dieselbe Strategie aktuell an mehreren Stellen verfolgt.
Die verschärften Anforderungen an MFA, Passkeys und privilegierte Benutzer folgen derselben Logik wie die neuen Änderungen für SOQL und Apex:
- weniger Ausnahmen
- weniger implizites Vertrauen
- mehr technische Durchsetzung
- mehr Sicherheit als Standard
Aus Sicht der Plattform ergibt das absolut Sinn.
Je weniger Sicherheit von einzelnen Entscheidungen abhängt, desto sicherer wird das Gesamtsystem.
Fazit
Summer ’26 bringt nicht einfach nur neue SOQL-Funktionen oder zusätzliche Syntax. Die Änderungen zeigen einen grundlegenden Wandel in der Sicherheitsstrategie von Salesforce. Sicherheit wird zunehmend von einer optionalen Entwicklungsentscheidung zu einer festen Eigenschaft der Plattform.
Für Entwickler bedeutet das, bestehende Anwendungen kritisch zu überprüfen.
Für Unternehmen bedeutet es, Berechtigungen, Datenzugriffe und Sicherheitskonzepte regelmäßig zu hinterfragen. Und für Salesforce bedeutet es einen weiteren Schritt in Richtung einer Plattform, auf der Security nicht mehr nachträglich ergänzt werden muss, sondern von Anfang an Teil des Standards ist.
