--- term: 'Sicherheit in der Datenschicht vs. in der Anwendungsschicht' seoTitle: 'Datenschicht vs. Anwendungsschicht: wo Regeln hingehören' headline: 'Sicherheit in der Datenschicht vs. in der Anwendungsschicht' slug: datenschicht-vs-anwendungsschicht-sicherheit category: database shortDefinition: 'Sicherheit in der Anwendungsschicht ist ein Wächter in Ihrem Code, in der Datenschicht ein Wächter auf den Daten selbst – echte Systeme brauchen beides.' 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: 'Was ist der Unterschied zwischen Sicherheit in der Anwendungsschicht und in der Datenschicht?' answer: 'Die Anwendungsschicht sichert das Verhalten: Authentifizierung, Umgang mit Sessions, Eingabevalidierung und die Prüfungen der Geschäftslogik, die in Ihrem Code stehen. Die Datenschicht sichert die gespeicherte Information selbst: Verschlüsselung, Zugriffs-Policies, Regeln auf Zeilenebene und Auditing – und zwar unabhängig davon, welcher Client oder welcher Codepfad die Daten berührt. Das sind getrennte Schichten; manche Glossare werfen sie zusammen, und genau so entstehen Lücken.' - question: 'Genügt Sicherheit in der Anwendung, wenn die Datenbank dahinter liegt?' answer: 'Nein – und darin sind sich alle ernsthaften Darstellungen einig. Alles, was die Datenbank erreicht, ohne durch Ihre Anwendungslogik zu laufen, umgeht jede dort geschriebene Regel: administrative SQL-Clients, BI- und Analysewerkzeuge, Hintergrund-Jobs, Migrationen, ein zweiter Dienst auf derselben Datenbank. Regeln der Anwendungsschicht schützen eine Tür; die Datenschicht schützt den Raum.' - question: 'Wo sollte Autorisierung durchgesetzt werden – im Anwendungscode oder in der Datenbank?' answer: 'Mehrschichtig, nach Regeltyp. Kontextreiche Geschäftsregeln ("Manager genehmigen Rechnungen unterhalb ihres Limits") gehören in den Anwendungscode, nah am Workflow. Strukturelle Regeln ("Benutzer sehen nur ihre Zeilen", "Tenants kreuzen sich nie") gehören in die Datenschicht – als Policies oder ACLs, die man nicht pro Endpoint vergessen kann. Niemals auf der Client-Seite. Die reife Antwort ist eine Frage der Platzierung, nicht der Gefolgschaft.' - question: 'Was ist IDOR und welche Schicht verhindert es?' answer: 'Insecure Direct Object Reference – ein Objekt über seine ID holen, ohne zu prüfen, ob der Aufrufer darauf zugreifen darf; die Schwachstellenklasse, die in den OWASP-Listen für APIs ganz oben steht. Die unmittelbare Abhilfe ist eine Eigentümerprüfung in der Anwendungsschicht, auf jedem Endpoint; die strukturelle Abhilfe ist die Durchsetzung in der Datenschicht, wo die fehlende Prüfung zur Verweigerung führt, weil die Zeile selbst den unbefugten Zugriff ablehnt.' - question: 'Was ist mehrschichtige Verteidigung?' answer: 'Das Prinzip, dass keine einzelne Kontrolle allein dastehen darf – mehrere überlappende Barrieren, damit der Ausfall einer Schicht von der nächsten aufgefangen wird. Hier angewendet: Validieren und autorisieren Sie in der Anwendung, und setzen Sie den Zugriff trotzdem in der Datenschicht durch. Die Schichten sind nicht redundant; sie versagen unterschiedlich, und genau darum geht es.' - question: 'Sollten Daten in der Anwendungsschicht oder in der Datenbank verschlüsselt werden?' answer: 'Je nach Bedrohungsmodell, oft beides. Verschlüsselung im Ruhezustand auf Datenbankebene schützt gestohlene Platten und Backups, ist für eine kompromittierte Anwendung aber transparent. Verschlüsselung in der Anwendungsschicht hält die Schlüssel vollständig von der Datenbank fern und schützt gegen eine Kompromittierung auf Datenbankseite – zum Preis der Durchsuchbarkeit. Verschlüsselung bei der Übertragung ist auf jedem Abschnitt Pflicht.' - question: 'Welche Nachteile hat es, Sicherheit in der Datenbank durchzusetzen?' answer: 'Es gibt echte, die man besser handhabt als leugnet: Policies sind im Anwendungscode unsichtbar, deshalb erfordert das Debuggen von "wo sind meine Zeilen hin?" Disziplin; die Auswertung von Policies pro Zeile kostet Performance; ein Tenant-Kontext über die Session wirkt subtil mit Connection Pooling zusammen; und komplexe fachliche Workflows lassen sich schlecht als Zeilenprädikate ausdrücken. Strukturelle Regeln gedeihen dort, Workflow-Regeln nicht.' - question: 'Wie verschieben BaaS-Plattformen den Ort der Sicherheit?' answer: 'Sie lassen die vertrauenswürdige Mittelschicht entfallen: Clients sprechen nahezu direkt mit dem Datendienst, deshalb muss Autorisierung in Konstrukten der Datenschicht leben – ACLs pro Objekt, Klassenberechtigungen, Policies auf Zeilenebene – statt in handgeschriebenen Prüfungen in Controllern. Das ist keine Schwäche, sondern das Modell: Die Plattform setzt die deklarierten Regeln bei jeder Anfrage durch, und Funktionen auf dem Server tragen den Rest der Geschäftslogik.' 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: 'Sicherheit, die Ihr nächstes Refactoring überlebt' text: 'Back4app legt die strukturellen Regeln dorthin, wo man sie nicht vergessen kann: ACLs auf jedem Objekt, Klassenberechtigungen auf jedem Schema, serverseitig durchgesetzt bei jeder Anfrage – während Cloud Code die Geschäftslogik darüber trägt. Mehrschichtige Verteidigung, standardmäßig.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-26' translationKey: data-layer-vs-application-layer-security --- **Sicherheit in der Anwendungsschicht ist ein Wächter in Ihrem Code, in der Datenschicht ein Wächter auf den Daten selbst – echte Systeme brauchen beides.** Sie sind keine Synonyme, auch wenn selbst gut platzierte Glossare sie verwischen: Die Anwendungsschicht sichert das *Verhalten* (Authentifizierung, Validierung, Geschäftsregeln), die Datenschicht sichert *die gespeicherte Information* (Policies, ACLs, Verschlüsselung) gegen jeden Zugriffspfad – auch gegen die, die Ihr Code nie zu sehen bekommt. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Anwendungsschicht | Regeln im Code: Authentifizierung, Validierung, Workflow-Autorisierung | | Datenschicht | Regeln auf den Daten: Policies, ACLs, Verschlüsselung, Audit – auf jedem Zugriffspfad | | Der klassische Fehler | Ein Endpoint vergisst seine Eigentümerprüfung – IDOR, die Nummer 1 der OWASP | | Das Prinzip | Mehrschichtige Verteidigung: Die Schichten versagen unterschiedlich, also stapeln Sie sie | | Die Platzierungsregel | Workflow-Regeln in den Code, strukturelle Regeln auf die Daten | ## Der Bug, der die Debatte definiert Durchsetzung in der Anwendungsschicht ist richtig – bis jemand vergisst, sie zu wiederholen: ```javascript // Endpoint eins: die Eigentümerprüfung, vorhanden und korrekt 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 zwei, drei Sprints später, in einer anderen Datei: app.get('/contracts/:id/export', async (req, res) => { const contract = await db.contracts.findById(req.params.id); res.send(toPdf(contract)); // ← niemand hat die Prüfung wiederholt. IDOR ausgeliefert. }); ``` Durchsetzung in der Datenschicht kehrt den Fehlerfall um: Die Regel reist mit der Zeile, also hat die vergessene Prüfung nichts mehr zu vergessen – **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 } ``` ## Mehrschichtige Verteidigung: Schichten um gespeicherte Daten legen ```mermaid flowchart TB accTitle: Mehrschichtige Verteidigung um gespeicherte Daten accDescr: Anfragen durchlaufen die Netzwerkabwehr, dann Kontrollen der Anwendungsschicht wie Authentifizierung, Validierung und fachliche Autorisierung und schließlich Kontrollen der Datenschicht – Policies, ACLs und Verschlüsselung –, die auch Pfade abdecken, welche die Anwendung vollständig umgehen. N["Netzwerkschicht
TLS, Firewalls, Gateways"] --> A["Anwendungsschicht
Authn · Validierung · Workflow-Authz"] A --> D["Datenschicht
Policies · ACLs · Verschlüsselung · Audit"] B["Umgehungspfade:
Admin-SQL, BI-Werkzeuge, Jobs, zweite Dienste"] -.-> D ``` Der gestrichelte Pfeil ist das Argument: Alles, was Ihre Anwendung überspringt, trifft trotzdem auf die Datenschicht – deshalb schützen Regeln, die nur in Controllern leben, eine einzige Tür eines Raums mit vielen Türen. Das ist [mehrschichtige Verteidigung](https://csrc.nist.gov/glossary/term/defense_in_depth), angewendet auf gespeicherte Daten: überlappende Barrieren, die unterschiedlich versagen. ## Datenschicht vs. Anwendungsschicht: wer macht was | Funktion | Anwendungsschicht | Datenschicht | | --- | --- | --- | | Authentifizierung | Sessions, Token, Anmeldeabläufe | Vertraut der weitergereichten Identität | | Eingabevalidierung | Erste und wichtigste Linie | Typen und Constraints als Auffangnetz | | Workflow-Autorisierung | "Darf diese Rolle diese Aktion jetzt ausführen?" | Schlecht geeignet – heraushalten | | Strukturelle Autorisierung | Prüfungen der Bequemlichkeit halber | **Policies, ACLs – die durchgesetzte Mauer** | | Verschlüsselung | In der App, um Schlüssel zu trennen | Im Ruhezustand und pro Feld | | Audit | Fachliche Ereignisse | Jeder Zugriff, jeder Pfad | Zwei Zeilen tragen die ganze Debatte. **Workflow-Regeln** – Genehmigungsketten, Zustandsautomaten, Limits – brauchen Kontext, den nur der Code hat; presst man sie in Zeilenprädikate, entsteht eine nicht wartbare Policy-Suppe. **Strukturelle Regeln** – Eigentum, Tenant-Zugehörigkeit, Sichtbarkeit – sind genau das, was [Policies auf Zeilenebene](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) und ACLs pro Objekt ohne Disziplin je Endpoint durchsetzen. Platzieren Sie jede Regel dort, wo ihr Versagen überlebbar ist. ## IDOR: die Schichtendebatte mit CVE-Liste Der [am höchsten eingestufte Fehler bei der Zugriffskontrolle](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) – und die [Nummer 1 in der API-spezifischen Liste](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) – ist genau die vergessene Prüfung aus dem Code oben: authentifizierte Benutzer holen Objekte über deren ID, ohne jede Autorisierung pro Objekt. Sicherheitsseiten katalogisieren die Schwachstelle, Architekturseiten katalogisieren die Schichten; nützlich ist die Verbindung: **IDOR ist, wie Durchsetzung allein in der Anwendung im großen Maßstab aussieht**, und Policies in der Datenschicht sind die strukturelle Abhilfe, weil die verpasste Prüfung zur Verweigerung führt statt zur offenen Tür. ## Wie BaaS die Grenze verschiebt Plattformen für Backend as a Service machen die These dieses Artikels zur Architektur: Wenn Clients (nahezu) direkt mit dem Datendienst sprechen, gibt es keine handgeschriebene Controller-Schicht mehr, die die Prüfungen trägt – Autorisierung *muss* also in Konstrukten der Datenschicht leben. ACLs pro Objekt tragen das Eigentum, Klassenberechtigungen regeln Operationen pro Schema, und die Plattform setzt beides bei jeder Anfrage von jeder Oberfläche durch. Die Anwendungsschicht verschwindet nicht; sie zieht in Funktionen auf dem Server um, die Validierung und Workflow-Regeln tragen – die Zweiteilung, erzwungen durch das Design statt durch Disziplin. ## Typische Anwendungsfälle - **Multi-Tenant-SaaS.** Die Tenant-Zugehörigkeit ist die kanonische strukturelle Regel – in der Datenschicht durchgesetzt, feindselig getestet, niemals WHERE-Klauseln anvertraut. - **Datensätze im Besitz von Benutzern.** Nachrichten, Dokumente, Bestellungen: Das Eigentum hängt über die ACL an der Zeile; der App-Code bleibt lesbar, die Daten bleiben versiegelt. - **Zugriff für Analytik und BI.** Der Umgehungspfad, sicher gemacht: Analysten fragen Replikate direkt ab und sehen nur, was die Regeln der Datenschicht erlauben. - **Nachweise für Compliance.** Prüfer bevorzugen Kontrollen, die sich in der Datenschicht vorführen lassen, gegenüber Verweisen in den Anwendungscode. - **Genehmigungs-Workflows.** Der Gegenfall: Zustandsabhängige Geschäftsregeln leben in der Anwendungslogik – während die strukturellen Regeln darunter weiter halten. ## Wo gehört welche Regel hin? Entscheidungsmatrix | In den Anwendungscode, wenn … | In die Datenschicht, wenn … | | --- | --- | | Die Regel Workflow-Kontext oder Zustand braucht | Die Regel Eigentum, Tenant-Zugehörigkeit oder Sichtbarkeit betrifft | | Sie Dienste und Nebenwirkungen übergreift | Sie auf jedem Pfad halten muss, Umgehungen eingeschlossen | | Sie sich mit Produktiterationen ändert | Ihr Versagen ein Datenleck bedeutet, keinen Bug | | Aussagekräftige Fehler und UX-Abläufe zählen | Stilles Scheitern zur sicheren Seite erwünscht ist | | Es fachliche Policy ist | Es eine strukturelle Invariante ist | Und die stehende Regel über beiden Spalten: Die Schichten verknüpfen sich mit UND, nicht mit ODER – behalten Sie die Prüfungen der Anwendungsschicht für Klarheit und UX, und lassen Sie die Datenschicht ihr Fehlen überlebbar machen. ## Grenzen und Trade-offs - **Durchsetzung allein in der App:** duplizierte Logik über Endpoints hinweg, Drift zwischen Microservices und jeder Umgehungspfad ungeschützt – die IDOR-Fabrik. - **Durchsetzung allein in den Daten:** unsichtbare Regeln, die beim Debuggen verwirren, Auswertungskosten pro Zeile, Feinheiten beim Pooling-Kontext und in Prädikate verbogene Geschäftslogik. - **Beides zusammen kostet Abstimmung.** Zwei Stellen, die zu ändern sind, wenn sich eine Regel ändert; halten Sie strukturelle Regeln wenige, stabil und dokumentiert. - **Die Platzierung der Verschlüsselung ist eine echte Weggabelung.** Auf Datenbankseite ist sie transparent und durchsuchbar; auf Anwendungsseite trennt sie die Schlüssel, erschwert aber Abfragen – entscheiden Sie pro Feld, pro Bedrohung. - **Die Grenze selbst muss auditiert werden.** Wer Zugangsdaten zur Umgehung hält – Admin-Rollen, Master Keys –, steht außerhalb jedes Rings; diese Liste ist der tatsächliche Perimeter. ## Die beiden Schichten mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Schlussfolgerung dieses Artikels liefert sie als Standardarchitektur mit: Die Datenschicht hält die strukturellen Regeln – ACLs pro Objekt, Klassenberechtigungen, geschützte Felder, serverseitig durchgesetzt bei jeder Anfrage –, während Cloud-Code-Trigger den Anteil der Anwendungsschicht tragen: Validierung, Anreicherung und Workflow-Prüfungen, die laufen, bevor ein Schreibzugriff landet. Der Bug mit dem vergessenen Filter hat keinen Weg hindurch, und die Geschäftsregeln behalten einen Ort zum Leben.