Se você mantém código Apex em uma org Salesforce, a Summer ’26 (API v67.0) traz uma mudança silenciosa que pode alterar completamente o que o seu código retorna sem exceção, sem falha no deploy, apenas resultados diferentes.
É uma mudança importante. E é exatamente o tipo de alteração que surpreende uma org em produção se ninguém a identificou a tempo.
Neste artigo, vamos dissecar o que está acontecendo, por que a Salesforce tomou essa decisão, e mais importante como preparar seu time e sua org para essa transição sem dores de cabeça.
O Problema: Apex Ignorava as Permissões do Usuário Corrente
Por toda a história do Apex, as operações de banco de dados rodavam em system mode por padrão. Isso significa que SOQL, SOSL, DML e os métodos da classe Database ignoravam completamente:
- Permissões de objeto do usuário
- Segurança em nível de campo (Field-Level Security | FLS)
- Regras de compartilhamento (sharing rules)
Em termos práticos: uma query em um controller retornaria registros que o usuário logado não deveria enxergar, e gravaria em campos que ele não deveria acessar a menos que você adicionasse proteções manualmente.
Imagine uma organização sem fins lucrativos onde um voluntário com perfil restrito consegue visualizar todo o histórico de doações de cada contato através de um componente Lightning customizado que ninguém testou de verdade. Isso acontecia porque o Apex rodava com privilégios elevados, independente de quem estava acessando.
A plataforma oferecia ferramentas para optar por segurança como WITH SECURITY_ENFORCED, Security.stripInaccessible() e with sharing nas classes, mas eram escolhas que o desenvolvedor precisava tomar ativamente. Se você esquecesse, o código rodava aberto. Segurança era algo que você precisava lembrar; insegurança era o padrão.
A Solução: Summer ’26 Inverte o Padrão para User Mode
Na API versão 67.0, esse padrão se inverte. Operações de banco de dados agora rodam em user mode por padrão, a menos que você especifique o contrário.
Concretamente, na v67.0:
- SOQL / SOSL / DML / Database methods passam a respeitar as permissões de objeto, FLS e regras de compartilhamento do usuário corrente por padrão.
- Uma classe sem declaração de sharing agora assume
with sharingpor padrão (anteriormente, a ausência de declaração efetivamente herdava o modo do chamador frequentemente without sharing). WITH SECURITY_ENFORCEDé removido e não compila mais você migra paraWITH USER_MODE.- Triggers sempre rodam em system mode e não podem declarar modo de sharing ou acesso.
O detalhe crucial: isso é vinculado à versão API da classe Apex. Classes existentes mantêm sua versão API atual e continuam se comportando como antes até que você as atualize para 67.0. Ou seja, a migração fica sob seu controle não é uma mudança forçada da noite para o dia em cada linha de código que você possui.
Novas classes criadas na v67.0 recebem o novo comportamento imediatamente. E você pode optar explicitamente pelo system mode quando realmente precisar:
// SOQL — inline
List<Opportunity> gifts = [SELECT Id, Amount FROM Opportunity WITH USER_MODE];
// enforce user access (agora o padrão)
List<Opportunity> all = [SELECT Id, Amount FROM Opportunity WITH SYSTEM_MODE];
// escape hatch intencional
// DML — respeitando o usuário
insert newGifts; // respeita permissões de create/FLS do usuário
// Database methods — passando o enum AccessLevel
List<Opportunity> dyn = Database.query('SELECT Id, Amount FROM Opportunity', AccessLevel.SYSTEM_MODE);
Database.insert(newGifts, AccessLevel.USER_MODE);O modelo mental é simples: user mode é o padrão seguro; SYSTEM_MODE / without sharing agora é algo que você escreve de propósito, de forma explícita, onde um revisor pode enxergar.
Exemplo Prático: Controller de Doações Antes e Depois
Vamos imaginar um componente Lightning que exibe o histórico de doações de um contato. Veja como o código se transforma com a v67.0:
Versão Anterior à v67.0 (Insegura por Padrão)
// Pre-Summer '26 — sem declaração de sharing, query em system mode
public class DonorGivingController {
@AuraEnabled(cacheable = true)
public static List<Opportunity> getGifts(Id contactId) {
// Roda em system mode: retorna doações independente de quem pergunta,
// e expõe o campo Amount mesmo se o usuário não tem FLS sobre ele.
return [
SELECT Id, Amount, CloseDate, StageName
FROM Opportunity
WHERE Primary_Contact__c = :contactId
];
}
}Versão na v67.0 (Segura por Padrão)
// Summer '26 — a intenção é explícita e o padrão é seguro
public with sharing class DonorGivingController {
@AuraEnabled(cacheable = true)
public static List<Opportunity> getGifts(Id contactId) {
return [
SELECT Id, Amount, CloseDate, StageName
FROM Opportunity
WHERE Primary_Contact__c = :contactId
];
}
}Na v67.0, a mesma classe sem nenhuma alteração de código agora se comporta como with sharing em user mode. Se um usuário restrito abrir o componente: doações em registros que ele não enxerga via sharing são filtradas, e se ele não tem FLS sobre o campo Amount, a query lança uma exceção em vez de vazar o dado.
Na maioria dos cenários, esse é o comportamento que você sempre quis.
O Que Muda para Seu Time de Desenvolvimento
Essa mudança tem profundas implicações para equipes que mantêm codebases Apex de longa data. Aqui estão os pontos-chave que seu time precisa considerar:
1. Migração Controlada por Versão de API
O comportamento novo é vinculado à versão da API da classe. Isso significa que classes legadas continuam funcionando como antes até que você explicitamente as atualize para a v67.0. Essa é uma decisão de design inteligente da Salesforce: a migração fica sob controle do time, sem surpresas automáticas em produção.
2. Novas Classes Começam Seguras
Qualquer classe nova criada com API version 67.0 já herda o comportamento seguro por padrão. Isso elimina um problema histórico onde desenvolvedores iniciantes facilmente esqueciam de adicionar proteções de segurança.
3. WITH SECURITY_ENFORCED Não Compila Mais
Se você usava WITH SECURITY_ENFORCED em queries SOQL, precisará migrar para WITH USER_MODE. Essa é uma mudança de sintaxe simples, mas que precisa ser feita antes de bumpar a versão da API.
4. Triggers Continuam em System Mode
Um ponto importante: triggers sempre rodam em system mode, independente da versão da API. Isso faz sentido, porque em cenários de trigger você precisa de acesso irrestrito para processar dados corretamente.
Checklist de Migração para Summer ’26
Para garantir uma transição suave, siga este checklist:
- Audite suas classes Apex — identifique todas as classes com API version anterior a 67.0 que fazem operações de banco de dados.
- Verifique o uso de WITH SECURITY_ENFORCED — substitua por
WITH USER_MODEem todas as queries afetadas. - Teste em Sandbox — antes de atualizar as versões de API, teste o comportamento em um ambiente de sandbox para identificar registros que serão filtrados.
- Identifique system mode intencional — para classes que genuinamente precisam de system mode (como processos batch de administração), adicione
WITH SYSTEM_MODEouAccessLevel.SYSTEM_MODEde forma explícita. - Atualize as versões de API — bumps das classes para v67.0 devem ser feitos de forma gradual e testada.
- Documente as decisões — adicione comentários nos pontos onde system mode é usado intencionalmente para que revisores entendam a intenção.
Impacto para Empresas e Desenvolvedores
Essa mudança da Salesforce é um passo significativo na direção de um modelo de segurança mais robusto para toda a plataforma. Para empresas, os benefícios são claros:
Redução de riscos de segurança: A maioria das vulnerabilidades de dados em orgs Salesforce historicamente aconteceu porque o código Apex rodava com privilégios excessivos. Com user mode como padrão, esses incidentes se tornam exceção em vez de regra.
Conformidade regulatória: Para organizações que precisam atender a LGPD, GDPR ou outros marcos regulatórios, ter o código Apex respeitando permissões por padrão simplifica significativamente auditorias e revisões de compliance.
Redução de technical debt: Muitas orgs acumularam código inseguro ao longo dos anos. Essa mudança força uma revisão saudável que elimina vulnerabilidades latentes.
Para desenvolvedores, a mudança traz uma curva de aprendizado inicial, mas a longo prazo resulta em código mais limpo, mais seguro e mais fácil de revisar. Quando system mode é usado, será porque alguém deliberadamente optou por ele e isso ficará evidente no código.
Conclusão: Abrace a Mudança Antes Que Ela o Surpreenda
A inversão de padrão para user mode na Summer ’26 é uma das mudanças mais significativas na segurança do Apex nos últimos anos. Ela reflete a maturidade da plataforma e o compromisso da Salesforce com um modelo onde segurança é o padrão, não a exceção.
A boa notícia é que a migração é controlada por você. Não há urgência de atualizar todas as classes de uma vez. Mas quanto antes você começar a auditar e planejar a transição, menos dor de cabeça terá quando as equipes começarem a criar novas classes na v67.0.
Recomendação prática: Comece revisando as classes mais críticas da sua org controllers de Lightning, classes de integração e processos batch. Identifique onde o system mode é usado e documente por quê. Em seguida, planeje a migração gradual para a v67.0.
O futuro do Apex é seguro por padrão. É hora de se preparar.
Quer se aprofundar em segurança no Salesforce? Confira também nosso artigo sobre OAuth Hacks no Salesforce e aprenda a proteger seu ecossistema contra vulnerabilidades em integrações de terceiros.