---
term: 'Segurança na Camada de Dados vs. na Camada de Aplicação'
seoTitle: 'Segurança na Camada de Dados vs. na de Aplicação: Onde Ficam as Regras'
headline: 'Segurança na Camada de Dados vs. na Camada de Aplicação'
slug: seguranca-camada-de-dados-vs-aplicacao
category: database
shortDefinition: '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.'
relatedTerms:
- row-level-security
- access-control-lists-acl
- class-level-permissions-clp
- data-encryption-at-rest-transit
- tenant-isolation
contrastsWith:
- row-level-security
aboutTerms:
- 'Segurança na Camada de Dados'
- 'Segurança na Camada de Aplicação'
faq:
- question: 'Qual a diferença entre segurança na camada de aplicação e na camada de dados?'
answer: 'A camada de aplicação protege o comportamento: autenticação, gestão de sessão, validação de entrada e as verificações de regra de negócio escritas no seu código. A camada de dados protege a informação armazenada em si: criptografia, políticas de acesso, regras em nível de linha e auditoria que valem não importa qual cliente ou caminho de código toque os dados. São camadas distintas — alguns glossários as confundem, e é exatamente assim que nascem as brechas.'
- question: 'Segurança na aplicação basta se o banco está atrás dela?'
answer: 'Não — e este é o consenso de todo tratamento sério do tema. Qualquer coisa que alcança o banco sem passar pela lógica da sua aplicação contorna toda regra escrita ali: clientes SQL de admin, ferramentas de BI e analytics, jobs em segundo plano, migrações, um segundo serviço compartilhando o banco. Regras na aplicação protegem uma porta; a camada de dados protege a sala.'
- question: 'Onde a autorização deveria ser aplicada — no código ou no banco?'
answer: 'Em camadas, por tipo de regra. Regras de negócio ricas em contexto ("gerentes aprovam faturas dentro do seu limite") pertencem ao código da aplicação, perto do workflow. Regras estruturais ("usuários veem só as próprias linhas", "tenants nunca se cruzam") pertencem à camada de dados — políticas ou ACLs que não podem ser esquecidas endpoint a endpoint. Nunca no cliente. A resposta madura é posicionamento, não torcida.'
- question: 'O que é IDOR e qual camada o previne?'
answer: 'Insecure Direct Object Reference — buscar um objeto por ID sem verificar se quem chama pode acessá-lo, a classe de vulnerabilidade de API mais bem ranqueada nas listas da OWASP. A correção imediata é uma verificação de propriedade na camada de aplicação em cada endpoint; a correção estrutural é a camada de dados, onde a verificação ausente falha fechada porque a própria linha recusa acesso não autorizado.'
- question: 'O que é defesa em profundidade?'
answer: 'O princípio de que nenhum controle deveria ser o único de pé — múltiplas barreiras sobrepostas, para que a falha de uma camada seja capturada pela seguinte. Aplicado aqui: valide e autorize na aplicação, e aplique o acesso na camada de dados mesmo assim. As camadas não são redundantes; elas falham de formas diferentes, e esse é exatamente o ponto.'
- question: 'Os dados deveriam ser criptografados na aplicação ou no banco?'
answer: 'Depende do modelo de ameaça — muitas vezes, nos dois. Criptografia em repouso no banco protege discos roubados e backups, mas é transparente para qualquer aplicação comprometida. Criptografia na camada de aplicação mantém as chaves totalmente longe do banco, protegendo contra comprometimento do lado do banco ao custo da capacidade de busca. Criptografia de transporte é o mínimo em todo salto.'
- question: 'Quais as desvantagens de aplicar segurança no banco?'
answer: 'Reais, e melhor gerenciadas do que negadas: políticas são invisíveis no código da aplicação, então depurar "cadê minhas linhas" exige disciplina; a avaliação de política por linha tem custo de performance; contexto de tenant por sessão interage sutilmente com connection pooling; e workflows de negócio complexos se expressam mal como predicados de linha. Regras estruturais prosperam ali; regras de workflow, não.'
- question: 'Como plataformas BaaS mudam onde a segurança vive?'
answer: 'Elas colapsam a camada intermediária confiável: clientes falam quase diretamente com o serviço de dados, então a autorização precisa viver em construções da camada de dados — ACLs por objeto, permissões em nível de classe, políticas de linha — em vez de verificações escritas à mão em controllers. Isso não é fraqueza, é o modelo: a plataforma aplica as regras declaradas em toda requisição, e funções server-side carregam o restante da lógica de negócio.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'OWASP Top 10 — Broken Access Control'
url: 'https://owasp.org/Top10/A01_2021-Broken_Access_Control/'
- name: 'OWASP API Security — Broken Object Level Authorization'
url: 'https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/'
- name: 'NIST glossary — defense in depth'
url: 'https://csrc.nist.gov/glossary/term/defense_in_depth'
- name: 'PostgreSQL Row Security Policies'
url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html'
cta:
title: 'Segurança que sobrevive ao seu próximo refactor'
text: 'O Back4app coloca as regras estruturais onde elas não podem ser esquecidas: ACLs em todo objeto, permissões em nível de classe em todo schema, aplicadas server-side em toda requisição — enquanto o Cloud Code carrega a lógica de negócio acima delas. Defesa em profundidade, por padrão.'
linkText: 'Comece grátis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: data-layer-vs-application-layer-security
---
**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
| Pergunta | Resposta |
| --- | --- |
| Camada de aplicação | Regras no código: authn, validação, autorização de workflow |
| Camada de dados | Regras nos dados: políticas, ACLs, criptografia, auditoria — todo caminho de acesso |
| A falha clássica | Um endpoint esquece a verificação de dono — IDOR, o número 1 da OWASP |
| O princípio | Defesa em profundidade: as camadas falham de formas diferentes, então empilhe-as |
| A regra de posicionamento | Regras de workflow no código; regras estruturais nos dados |
## O bug que define o debate
A verificação na camada de aplicação está correta — até alguém esquecer de repeti-la:
```javascript
// 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:**
```javascript
// 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
// 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
}
```
**Swift:**
```swift
// 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
}
}
```
**Kotlin:**
```kotlin
// 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
```mermaid
flowchart TB
accTitle: Defesa em profundidade ao redor dos dados armazenados
accDescr: As requisições passam por defesas de rede, depois pelos controles da camada de aplicação, como autenticação, validação e autorização de negócio, e por fim pelos controles da camada de dados — políticas, ACLs e criptografia — que também cobrem os caminhos que contornam a aplicação por completo.
N["Camada de rede
TLS, firewalls, gateways"] --> A["Camada de aplicação
authn · validação · authz de workflow"]
A --> D["Camada de dados
políticas · ACLs · criptografia · auditoria"]
B["Caminhos de bypass:
SQL de admin, ferramentas de BI, jobs, segundos serviços"] -.-> D
```
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](https://csrc.nist.gov/glossary/term/defense_in_depth) aplicada ao armazenamento: barreiras sobrepostas que falham de formas diferentes.
## Camada de dados vs. camada de aplicação: quem faz o quê
| Função | Camada de aplicação | Camada de dados |
| --- | --- | --- |
| Autenticação | Sessões, tokens, fluxos de login | Confia na identidade propagada |
| Validação de entrada | Primeira e principal linha | Tipos e constraints como retaguarda |
| Autorização de workflow | "Este papel pode fazer esta ação agora?" | Encaixe ruim — mantenha fora |
| Autorização estrutural | Verificações de conveniência | **Políticas, ACLs — o muro que vale** |
| Criptografia | No app, para separar chaves | Em repouso e por campo |
| Auditoria | Eventos de negócio | Todo acesso, todo caminho |
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](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) 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](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) — e [número 1 da lista específica de APIs](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) — é 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
| Coloque no código da aplicação quando… | Coloque na camada de dados quando… |
| --- | --- |
| A regra precisa de contexto ou estado de workflow | A regra é dono, tenant ou visibilidade |
| Ela atravessa serviços e efeitos colaterais | Ela precisa valer em todo caminho, bypasses incluídos |
| Ela muda a cada iteração do produto | A falha dela significa violação, não bug |
| Erros ricos e fluxos de UX importam | Falhar fechado e em silêncio é desejável |
| É política de negócio | É um invariante estrutural |
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.