Segurança na Camada de Dados vs. na Camada de Aplicação

Segurança na camada de aplicação é um guarda no seu código; segurança na camada de dados é um guarda nos próprios dados — sistemas reais precisam das duas. Não são sinônimos, embora até glossários bem ranqueados as embaralhem: a camada de aplicação protege o comportamento (autenticação, validação, regras de negócio); a camada de dados protege a informação armazenada (políticas, ACLs, criptografia) contra todo caminho de acesso — inclusive os que o seu código nunca vê.

Principais pontos

O bug que define o debate

A verificação na camada de aplicação está correta — até alguém esquecer de repeti-la:

// Endpoint um: a verificação de dono, presente e correta
app.get('/contracts/:id', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  if (contract.ownerId !== req.user.id) return res.status(403).end();
  res.json(contract);
});

// Endpoint dois, três sprints depois, outro arquivo:
app.get('/contracts/:id/export', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  res.send(toPdf(contract));   // ← ninguém reescreveu a verificação. IDOR em produção.
});

A camada de dados inverte a falha: a regra viaja com a linha, então a verificação esquecida não tem o que esquecer —

// JavaScript / Node.js — Back4app JS SDK
// Data-layer enforcement: the rule travels with the row, not the code path
const doc = await new Parse.Query('Contract').get(contractId); // someone else's row
doc.set('total', 0);
try {
  await doc.save(); // rejected by the object's ACL — server-side, every path
} catch (e) {
  console.log(e.code); // 101: object not found for update
}

// Flutter / Dart — Back4app Flutter SDK
// Data-layer enforcement: the rule travels with the row, not the code path
final doc = ParseObject('Contract')..objectId = contractId;
doc.set('total', 0);
final response = await doc.save();
if (!response.success) {
  print(response.error?.code); // rejected by the object's ACL, server-side
}

// iOS / Swift — Back4app Swift SDK
// Data-layer enforcement: the rule travels with the row, not the code path
var doc = Contract(objectId: contractId)
doc.total = 0
doc.save { result in
  if case .failure(let error) = result {
    print(error.code ?? .unknownError) // rejected by the object's ACL
  }
}

// Android / Kotlin — Back4app Android SDK
// Data-layer enforcement: the rule travels with the row, not the code path
val doc = ParseObject.createWithoutData("Contract", contractId)
doc.put("total", 0)
doc.saveInBackground { e ->
  if (e != null) Log.d("Security", "blocked by ACL: ${e.code}") // server-side
}

Defesa em profundidade: camadas de segurança ao redor dos dados

A seta pontilhada é o argumento: tudo que pula a sua aplicação ainda bate na camada de dados — e é por isso que regras que vivem só em controllers protegem uma porta de uma sala cheia de portas. Isso é defesa em profundidade aplicada ao armazenamento: barreiras sobrepostas que falham de formas diferentes.

Camada de dados vs. camada de aplicação: quem faz o quê

Duas linhas carregam o debate. Regras de workflow — cadeias de aprovação, máquinas de estado, limites — precisam de contexto que só o código tem; forçá-las em predicados por linha produz uma sopa de políticas impossível de manter. Regras estruturais — dono, tenant, visibilidade — são exatamente o que políticas de linha e ACLs por objeto aplicam sem exigir disciplina endpoint a endpoint. Coloque cada regra onde o modo de falha dela é sobrevivível.

IDOR: o debate de camadas com uma lista de CVEs

A falha de controle de acesso mais bem ranqueada — e número 1 da lista específica de APIs — é precisamente a verificação esquecida do código acima: usuários autenticados buscando objetos por ID sem nenhuma autorização por objeto. Páginas de segurança catalogam a vulnerabilidade; páginas de arquitetura catalogam as camadas; a conexão é a parte útil: IDOR é a cara da segurança só na aplicação em escala, e políticas na camada de dados são sua correção estrutural, porque a verificação perdida falha fechada em vez de aberta.

Como o BaaS move a fronteira

Plataformas de Backend as a Service tornam a tese deste artigo arquitetural: com clientes falando (quase) diretamente com o serviço de dados, não existe camada de controllers escrita à mão para segurar as verificações — então a autorização precisa viver em construções da camada de dados. ACLs por objeto carregam o dono, permissões em nível de classe controlam operações por schema, e a plataforma aplica as duas em toda requisição, vinda de qualquer superfície. A camada de aplicação não desaparece; ela se realoca em funções server-side que carregam validação e regras de workflow — a divisão em duas camadas, imposta por design em vez de por disciplina.

Casos de uso comuns

• SaaS multi-tenant. A fronteira entre tenants é a regra estrutural canônica — aplicada na camada de dados, testada adversarialmente, nunca confiada a cláusulas WHERE.
• Registros por usuário. Mensagens, documentos, pedidos: dono na linha via ACLs; o código do app permanece legível, os dados permanecem selados.
• Acesso de analytics e BI. O caminho de bypass tornado seguro: analistas consultam réplicas diretamente e veem apenas o que as regras da camada de dados permitem.
• Evidência de compliance. Auditores preferem controles demonstráveis na camada de dados a ponteiros para o código da aplicação.
• Workflows de aprovação. O contraexemplo: regras de negócio dependentes de estado vivem na lógica da aplicação — com as regras estruturais ainda valendo por baixo.

Onde cada regra deveria viver? Matriz de decisão

E a regra permanente sobre as duas colunas: as camadas são E, não OU — mantenha as verificações na aplicação pela clareza e pela UX, e deixe a camada de dados tornar a ausência delas sobrevivível.

Limitações e trade-offs

• Só na aplicação: lógica duplicada entre endpoints, deriva entre microsserviços e todo caminho de bypass desprotegido — a fábrica de IDOR.
• Só nos dados: regras invisíveis que confundem quem depura, custo de avaliação por linha, sutilezas de contexto com pooling e lógica de negócio contorcida em predicados.
• As duas juntas custam coordenação. Dois lugares para atualizar quando uma regra muda; mantenha as regras estruturais poucas, estáveis e documentadas.
• O lugar da criptografia é uma bifurcação real. No banco é transparente e pesquisável; na aplicação separa as chaves, mas complica consultas — decida por campo, por ameaça.
• A própria fronteira precisa de auditoria. Quem detém credenciais de bypass — roles de admin, master keys — está fora de todos os anéis; essa lista é o perímetro de verdade.

As duas camadas 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. Ele entrega a conclusão deste artigo como arquitetura padrão: a camada de dados segura as regras estruturais — ACLs por objeto, permissões em nível de classe, campos protegidos, aplicados server-side em toda requisição — enquanto os triggers de Cloud Code seguram a parte da camada de aplicação: validação, enriquecimento e verificações de workflow que rodam antes de qualquer escrita aterrissar. O bug do filtro esquecido não tem por onde passar, e as regras de negócio mantêm um lugar para viver.