"API Enabled" ligado por padrão: o problema que todo security review encontra em org antiga
Uma pergunta simples no Stack Exchange escancara um problema clássico de governança: permissões que vêm ligadas por padrão e que ninguém revisita depois
Uma dúvida aparentemente boba sobre a permissão "API Enabled" em profiles standard revela um problema recorrente de arquitetura: o que é padrão de fábrica na Salesforce nem sempre é o que deveria estar em produção anos depois.
A pergunta que motivou este post é simples: em orgs novas, "API Enabled" vem ligado ou desligado para os profiles? O contexto é ainda mais comum do que parece. Um security review recomendou desligar essa permissão em todos os profiles de uma org criada em 2016, e o time descobriu que ela estava ligada para quase todos, inclusive profiles standard, que não permitem edição direta dessa flag.
Se você já fez um assessment de segurança em org com mais de três ou quatro anos de vida, provavelmente já bateu nesse muro. "API Enabled" controla se o usuário daquele profile pode acessar a org via API, o que inclui integrações, ferramentas de terceiros, Data Loader, conectores de ETL, e qualquer client externo que fale com a Salesforce fora da UI padrão. Em profiles customizados, dá para desligar tranquilamente. Em profiles standard, como System Administrator, Standard User ou os profiles legados de licenças específicas, essa checkbox simplesmente não aparece editável, porque a Salesforce trata como parte do comportamento padrão daquele profile.
Por que isso incomoda tanto arquiteto e time de segurança
O ponto que fica subentendido na pergunta, e que eu reforço aqui com experiência de projeto, é que a resposta "depende da versão da org e de quando ela foi criada" não é satisfatória para quem faz auditoria. Orgs criadas em épocas diferentes carregam comportamentos de default diferentes, porque a Salesforce evolui esses padrões release a release, sem necessariamente documentar de forma explícita e histórica "a partir de tal versão, tal profile passou a vir com tal permissão ligada ou desligada".
Na prática, isso significa que você não consegue confiar no default como controle de segurança. Se a Salesforce decidiu, em algum ano, que Standard User vem com API Enabled ligado, isso provavelmente segue valendo até hoje em orgs novas, porque mudar esse comportamento quebraria expectativa de milhares de clientes que dependem de integração via profile standard. E é exatamente por isso que builds novos de org não podem ser tratados como "seguros por padrão".
O que fazer quando o profile standard não deixa desligar
A saída real, e que qualquer consultor de segurança vai recomendar, não é brigar com o profile standard. É migrar os usuários que não precisam de acesso via API para um profile customizado (clonado a partir do standard, se for o caso) e aplicar o princípio de menor privilégio ali. Profiles standard existem para dar baseline de funcionalidade, não para governança fina. Quando a exigência é reduzir superfície de ataque via API, o caminho é profile customizado, ou então usar Permission Set com controle mais granular combinado com Session Settings e IP Ranges para reduzir o raio de exposição, já que a checkbox em si pode ser inegociável no profile standard.
Segurança em Salesforce vive muito de suposição errada sobre defaults. Times acham que, se algo veio marcado de fábrica, é porque a Salesforce julgou seguro. Não é bem assim: muitos defaults existem para não quebrar funcionalidade esperada, não para minimizar risco. Isso é ainda mais crítico em orgs antigas, que carregam configuração de anos atrás sem que ninguém tenha revisitado o motivo daquela escolha.
Vale reforçar que a pergunta original no Stack Exchange não teve resposta aceita até o momento da curadoria, o que é comum em perguntas recentes. O conteúdo aqui é uma análise do problema estrutural que a pergunta expõe, não uma citação de resposta oficial da comunidade.
Se você é responsável por segurança ou arquitetura em uma org com alguns anos de vida, rode um relatório de profiles com "API Enabled" ligado e cruze com quem realmente usa integração via API (Data Loader, MuleSoft, conectores externos, ferramentas de RevOps). Para quem não precisa, migre para profile customizado sem essa permissão. Documente a decisão, porque em dois anos alguém vai perguntar de novo por que aquele profile tem ou não tem a flag.
Cuidado ao mexer em profile standard tentando "forçar" a remoção via clone: internal users que dependem de Connected Apps, OAuth flows ou apps que usam a API REST/SOAP vão quebrar silenciosamente se você desligar API Enabled sem mapear as dependências antes. Teste em sandbox e valide com o time de integração antes de aplicar em produção.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.