---
term: 'Seguridad en la Capa de Datos vs. en la Capa de Aplicación'
seoTitle: 'Seguridad en la Capa de Datos vs. en la de Aplicación: Dónde Van las Reglas'
headline: 'Seguridad en la Capa de Datos vs. en la Capa de Aplicación'
slug: seguridad-capa-de-datos-vs-aplicacion
category: database
shortDefinition: 'La seguridad en la capa de aplicación es un guardia en tu código; la de la capa de datos, un guardia sobre los datos mismos: un sistema real necesita ambas.'
relatedTerms:
- row-level-security
- access-control-lists-acl
- class-level-permissions-clp
- data-encryption-at-rest-transit
- tenant-isolation
contrastsWith:
- row-level-security
aboutTerms:
- 'Data-Layer Security'
- 'Application-Layer Security'
faq:
- question: '¿Cuál es la diferencia entre seguridad en la capa de aplicación y en la capa de datos?'
answer: 'La capa de aplicación protege el comportamiento: autenticación, gestión de sesiones, validación de entrada y las verificaciones de reglas de negocio escritas en tu código. La capa de datos protege la información almacenada en sí: cifrado, políticas de acceso, reglas a nivel de fila y auditoría que valen sin importar qué cliente o ruta de código toque los datos. Son capas distintas — algunos glosarios las confunden, y así es exactamente como nacen las brechas.'
- question: '¿Basta la seguridad en la aplicación si la base de datos está detrás de ella?'
answer: 'No — y este es el consenso de todo tratamiento serio del tema. Todo lo que llega a la base de datos sin pasar por la lógica de tu aplicación esquiva cada regla escrita ahí: clientes SQL de administración, herramientas de BI y analítica, jobs en segundo plano, migraciones, un segundo servicio que comparte la base. Las reglas en la aplicación protegen una puerta; la capa de datos protege la sala.'
- question: '¿Dónde debería aplicarse la autorización — en el código o en la base de datos?'
answer: 'En capas, según el tipo de regla. Las reglas de negocio ricas en contexto ("los gerentes aprueban facturas dentro de su límite") pertenecen al código de la aplicación, cerca del workflow. Las reglas estructurales ("los usuarios ven solo sus filas", "los tenants nunca se cruzan") pertenecen a la capa de datos — políticas o ACLs que no pueden olvidarse endpoint por endpoint. Nunca en el cliente. La respuesta madura es ubicación, no bando.'
- question: '¿Qué es IDOR y qué capa lo previene?'
answer: 'Insecure Direct Object Reference — obtener un objeto por ID sin verificar que quien llama puede accederlo, la clase de vulnerabilidad de API mejor clasificada en las listas de OWASP. El arreglo inmediato es una verificación de propiedad en la capa de aplicación en cada endpoint; el arreglo estructural es la capa de datos, donde la verificación ausente falla cerrada porque la propia fila rechaza el acceso no autorizado.'
- question: '¿Qué es la defensa en profundidad?'
answer: 'El principio de que ningún control debería ser el único en pie — múltiples barreras superpuestas, para que la falla de una capa sea atrapada por la siguiente. Aplicado aquí: valida y autoriza en la aplicación, y aplica el acceso en la capa de datos de todos modos. Las capas no son redundantes; fallan de formas distintas, y ese es exactamente el punto.'
- question: '¿Los datos deberían cifrarse en la aplicación o en la base de datos?'
answer: 'Depende del modelo de amenaza — a menudo, en ambas. El cifrado en reposo en la base protege discos robados y backups, pero es transparente para cualquier aplicación comprometida. El cifrado en la capa de aplicación mantiene las claves totalmente lejos de la base, protegiendo contra un compromiso del lado de la base al costo de la capacidad de búsqueda. El cifrado en tránsito es lo mínimo en cada salto.'
- question: '¿Qué desventajas tiene aplicar la seguridad en la base de datos?'
answer: 'Reales, y mejor gestionadas que negadas: las políticas son invisibles en el código de la aplicación, así que depurar "dónde están mis filas" exige disciplina; la evaluación de políticas por fila tiene un costo de rendimiento; el contexto de tenant por sesión interactúa sutilmente con el connection pooling; y los workflows de negocio complejos se expresan mal como predicados de fila. Las reglas estructurales prosperan ahí; las de workflow, no.'
- question: '¿Cómo cambian las plataformas BaaS el lugar donde vive la seguridad?'
answer: 'Colapsan la capa intermedia confiable: los clientes hablan casi directamente con el servicio de datos, así que la autorización debe vivir en construcciones de la capa de datos — ACLs por objeto, permisos a nivel de clase, políticas de fila — en vez de verificaciones escritas a mano en controllers. Eso no es una debilidad, es el modelo: la plataforma aplica las reglas declaradas en cada solicitud, y las funciones server-side cargan el resto de la lógica de negocio.'
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: 'Seguridad que sobrevive a tu próximo refactor'
text: 'Back4app pone las reglas estructurales donde no pueden olvidarse: ACLs en cada objeto, permisos a nivel de clase en cada schema, aplicados server-side en cada solicitud — mientras Cloud Code carga la lógica de negocio por encima. Defensa en profundidad, por defecto.'
linkText: 'Empieza gratis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: data-layer-vs-application-layer-security
---
**La seguridad en la capa de aplicación es un guardia en tu código; la de la capa de datos, un guardia sobre los datos mismos: un sistema real necesita ambas.** No son sinónimos, aunque hasta glosarios bien posicionados las mezclan: la capa de aplicación protege el *comportamiento* (autenticación, validación, reglas de negocio); la capa de datos protege *la información almacenada* (políticas, ACLs, cifrado) contra toda ruta de acceso — incluidas las que tu código nunca ve.
## Puntos clave
| Pregunta | Respuesta |
| --- | --- |
| Capa de aplicación | Reglas en el código: authn, validación, autorización de workflow |
| Capa de datos | Reglas sobre los datos: políticas, ACLs, cifrado, auditoría — toda ruta de acceso |
| La falla clásica | Un endpoint olvida su verificación de propiedad — IDOR, el número 1 de OWASP |
| El principio | Defensa en profundidad: las capas fallan de formas distintas, así que apílalas |
| La regla de ubicación | Reglas de workflow en el código; reglas estructurales sobre los datos |
## El bug que define el debate
La verificación en la capa de aplicación es correcta — hasta que alguien olvida repetirla:
```javascript
// Endpoint uno: la verificación de propiedad, presente y correcta
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 dos, tres sprints después, otro archivo:
app.get('/contracts/:id/export', async (req, res) => {
const contract = await db.contracts.findById(req.params.id);
res.send(toPdf(contract)); // ← nadie reescribió la verificación. IDOR en producción.
});
```
La capa de datos invierte la falla: la regla viaja con la fila, así que la verificación olvidada no tiene nada que olvidar —
**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
}
```
## Defensa en profundidad: capas de seguridad alrededor de los datos
```mermaid
flowchart TB
accTitle: Defensa en profundidad alrededor de los datos almacenados
accDescr: Las solicitudes pasan por defensas de red, luego por los controles de la capa de aplicación, como autenticación, validación y autorización de negocio, y por último por los controles de la capa de datos — políticas, ACLs y cifrado — que también cubren las rutas que esquivan la aplicación por completo.
N["Capa de red
TLS, firewalls, gateways"] --> A["Capa de aplicación
authn · validación · authz de workflow"]
A --> D["Capa de datos
políticas · ACLs · cifrado · auditoría"]
B["Rutas de bypass:
SQL de admin, herramientas de BI, jobs, segundos servicios"] -.-> D
```
La flecha punteada es el argumento: todo lo que se salta tu aplicación sigue chocando con la capa de datos — y por eso las reglas que viven solo en controllers protegen una puerta de una sala llena de puertas. Eso es [defensa en profundidad](https://csrc.nist.gov/glossary/term/defense_in_depth) aplicada al almacenamiento: barreras superpuestas que fallan de formas distintas.
## Capa de datos vs. capa de aplicación: quién hace qué
| Función | Capa de aplicación | Capa de datos |
| --- | --- | --- |
| Autenticación | Sesiones, tokens, flujos de login | Confía en la identidad propagada |
| Validación de entrada | Primera y principal línea | Tipos y constraints como respaldo |
| Autorización de workflow | "¿Este rol puede hacer esta acción ahora?" | Mal encaje — mantenla fuera |
| Autorización estructural | Verificaciones de conveniencia | **Políticas, ACLs — el muro que se aplica** |
| Cifrado | En la app, para separar claves | En reposo y por campo |
| Auditoría | Eventos de negocio | Todo acceso, toda ruta |
Dos filas cargan el debate. Las **reglas de workflow** — cadenas de aprobación, máquinas de estado, límites — necesitan un contexto que solo el código tiene; forzarlas en predicados por fila produce una sopa de políticas imposible de mantener. Las **reglas estructurales** — propiedad, tenants, visibilidad — son exactamente lo que las [políticas de fila](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) y las ACLs por objeto aplican sin exigir disciplina endpoint por endpoint. Pon cada regla donde su modo de falla sea sobrevivible.
## IDOR: el debate de capas con una lista de CVEs
La [falla de control de acceso mejor clasificada](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) — y [número 1 de la lista específica de APIs](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) — es precisamente la verificación olvidada del código de arriba: usuarios autenticados obteniendo objetos por ID sin ninguna autorización por objeto. Las páginas de seguridad catalogan la vulnerabilidad; las de arquitectura catalogan las capas; la conexión es la parte útil: **IDOR es la cara de la seguridad solo-en-la-aplicación a escala**, y las políticas en la capa de datos son su arreglo estructural, porque la verificación perdida falla cerrada en vez de abierta.
## Cómo el BaaS mueve la frontera
Las plataformas de Backend as a Service vuelven arquitectónica la tesis de este artículo: con los clientes hablando (casi) directamente con el servicio de datos, no existe una capa de controllers escrita a mano que sostenga las verificaciones — así que la autorización *debe* vivir en construcciones de la capa de datos. Las ACLs por objeto cargan la propiedad, los permisos a nivel de clase controlan operaciones por schema, y la plataforma aplica ambos en cada solicitud, venga de la superficie que venga. La capa de aplicación no desaparece; se reubica en funciones server-side que cargan la validación y las reglas de workflow — la división en dos capas, impuesta por diseño en vez de por disciplina.
## Casos de uso comunes
- **SaaS multi-tenant.** La frontera entre tenants es la regla estructural canónica — aplicada en la capa de datos, probada adversarialmente, nunca confiada a cláusulas WHERE.
- **Registros por usuario.** Mensajes, documentos, pedidos: la propiedad va en la fila vía ACLs; el código de la app queda legible, los datos quedan sellados.
- **Acceso de analítica y BI.** La ruta de bypass vuelta segura: los analistas consultan réplicas directamente y ven solo lo que las reglas de la capa de datos permiten.
- **Evidencia de compliance.** Los auditores prefieren controles demostrables en la capa de datos antes que punteros al código de la aplicación.
- **Workflows de aprobación.** El contraejemplo: las reglas de negocio dependientes de estado viven en la lógica de la aplicación — con las reglas estructurales aún vigentes por debajo.
## ¿Dónde debería vivir cada regla? Matriz de decisión
| Ponla en el código de la aplicación cuando… | Ponla en la capa de datos cuando… |
| --- | --- |
| La regla necesita contexto o estado de workflow | La regla es propiedad, tenants o visibilidad |
| Atraviesa servicios y efectos secundarios | Debe valer en toda ruta, bypasses incluidos |
| Cambia con cada iteración del producto | Su falla significa brecha, no bug |
| Importan los errores ricos y los flujos de UX | Fallar cerrado y en silencio es deseable |
| Es política de negocio | Es un invariante estructural |
Y la regla permanente sobre ambas columnas: las capas son Y, no O — conserva las verificaciones en la aplicación por claridad y UX, y deja que la capa de datos haga sobrevivible su ausencia.
## Limitaciones y trade-offs
- **Solo en la aplicación:** lógica duplicada entre endpoints, deriva entre microservicios y toda ruta de bypass desprotegida — la fábrica de IDOR.
- **Solo en los datos:** reglas invisibles que desconciertan a quien depura, costo de evaluación por fila, sutilezas de contexto con el pooling y lógica de negocio contorsionada en predicados.
- **Las dos juntas cuestan coordinación.** Dos lugares que actualizar cuando una regla cambia; mantén las reglas estructurales pocas, estables y documentadas.
- **Dónde cifrar es una bifurcación real.** En la base es transparente y consultable; en la aplicación separa las claves pero complica las consultas — decide por campo, por amenaza.
- **La propia frontera necesita auditoría.** Quien tiene credenciales de bypass — roles de admin, master keys — está fuera de todos los anillos; esa lista es el perímetro de verdad.
## Las dos capas en Back4app
Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Entrega la conclusión de este artículo como arquitectura por defecto: la capa de datos sostiene las reglas estructurales — ACLs por objeto, permisos a nivel de clase, campos protegidos, aplicados server-side en cada solicitud — mientras los triggers de Cloud Code sostienen la parte de la capa de aplicación: validación, enriquecimiento y verificaciones de workflow que corren antes de que cualquier escritura aterrice. El bug del filtro olvidado no tiene por dónde pasar, y las reglas de negocio conservan un lugar donde vivir.