O que são Permissões em Nível de Classe (CLPs)?

Uma permissão em nível de classe é uma regra no schema da classe que controla quais usuários ou papéis podem executar cada operação naquela classe. É o gate mais externo da segurança na camada de dados: antes de qualquer verificação por linha, a própria classe decide se este chamador pode consultar, criar, atualizar ou excluir ali — uma regra, a tabela inteira, verificada primeiro.

Principais pontos

O gate da classe, declarado e sentido

Uma CLP é configuração de schema — aqui o payload REST que tranca uma classe Config em leitura pública e escrita só pelo servidor:

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // qualquer um pode consultar
    "get":    { "*": true },
    "create": {},                         // ninguém a partir do cliente
    "update": { "role:admin": true },     // somente admins
    "delete": {},
    "addField": {}                        // schema congelado
  }
}

O que os clientes experimentam é o gate fazendo seu trabalho — leituras fluem, escritas morrem na fronteira da classe antes de qualquer dado ser tocado:

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

Como permissões de classe e ACLs funcionam juntas

A escada de granularidade: CLP vs. ACL vs. pointer permissions vs. campos protegidos

O idioma de design que cai disso: traço largo no schema, grão fino nas linhas. Classes cuja regra de acesso é uniforme (config, catálogos, logs) precisam só do gate da classe; classes com dados por usuário adicionam ACLs ou pointer permissions embaixo dele.

O mesmo gate em outros engines

-- PostgreSQL: privilégios em nível de tabela são CLPs com outro nome
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

Bancos de documentos espelham isso com papéis restritos a ações em nível de coleção — um papel com find e insert em exatamente uma coleção. O conceito é universal; o que muda é a ergonomia: grants em SQL e documentos de papéis são administrados em código, enquanto plataformas BaaS expõem a mesma matriz como checkboxes no dashboard.

Configurações recomendadas por tipo de conteúdo

Essa tabela é o checklist de que a maioria dos lançamentos realmente precisa — note a constante na última coluna e sua regra irmã: criação de classes pelo cliente desligada em produção, para que o schema só mude de propósito.

Casos de uso comuns

• Congelar schemas de produção. Add field desligado em tudo; classes param de surgir e mutar a partir do tráfego de clientes.
• Dados de referência somente leitura. Catálogos e configurações legíveis publicamente, graváveis só por código do servidor — o padrão Config acima.
• Caixas de entrada só de escrita. Classes de feedback e telemetria nas quais clientes podem criar, mas nunca ler — o gate inverso que o código na camada de app costuma esquecer.
• Superfícies de admin por papel. Update e delete reservados a um papel de admin enquanto o app lê livremente.
• Defesa contra o dump clássico. A famigerada one-liner — um curl com um app ID consultando uma classe User aberta — morre no gate de find quando a classe exige autenticação.

Quem deveria aplicar a regra: o gate da classe ou o código no servidor? Matriz de decisão

Eles se compõem: o padrão endurecido para classes genuinamente sensíveis tranca as CLPs por completo e expõe funções no servidor como a única porta — o gate da classe garante que ninguém contorna o chokepoint.

Limitações e trade-offs

• Granularidade de classe é grossa por definição. Qualquer coisa por linha pertence às ACLs e pointer permissions; qualquer coisa condicional pertence à validação no servidor — CLPs guardam, não raciocinam.
• Os defaults são permissivos para desenvolvimento. Classes novas nascem abertas para o protótipo voar; a passada pré-lançamento que vira a tabela acima é uma disciplina, não um automatismo.
• A master key ignora tudo. Todo gate deste artigo é nulo onde essa chave viaja — por isso ela vive só no servidor, usada por operação, jamais embarcada.
• A superfície de enforcement precisa ser completa. Assinaturas em tempo real e endpoints especiais historicamente tiveram lacunas — mantenha a plataforma atualizada e teste os gates de um cliente real, não só do dashboard.
• Checkboxes também precisam de revisão. Segurança declarativa só é segurança auditável se alguém audita — a matriz de configurações pertence ao seu checklist de lançamento, não à memória tribal.

CLPs no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. As permissões em nível de classe são a sua superfície de segurança de schema em forma visual: cada classe no dashboard carrega a matriz de operações como checkboxes — público, exige autenticação, por papel — mais pointer permissions e campos protegidos, aplicados no servidor em toda requisição, igualmente pelos SDKs, REST e GraphQL. Embaixo ficam as ACLs por objeto; em cima, os triggers de Cloud Code para as regras que precisam de lógica. As diretrizes de segurança percorrem a passada pré-lançamento completa — a matriz de configurações deste artigo, aplicada clique a clique.