For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/web/security.md (or send Accept: text/markdown).
Sicherheit und Datenschutz
Rate Limits, Secrets, Datenexport und der Audit-Trail.
Schritt-für-Schritt für Einsteiger
Voraussetzungen: Lesen Sie die beiden folgenden Einsteigerhandbücher, schließen Sie die lokale Web-Einrichtung ab und öffnen Sie dieses Monorepo im Stammverzeichnis in Ihrem Editor. Webeinstellungen gehören in apps/web/.env.local; Next.js liest das Stammverzeichnis .env nicht. /dashboard im Standard-Fake-Modus ist eine Demo ohne Datenbank; /auth benötigt eine migrierte Datenbank.
Kurze Begriffe: Ein Arbeitsbereich umfasst die einzelnen Benutzer, Daten und Einstellungen eines Teams. Der Server ist das vertrauenswürdige Backend; Halten Sie Anbieterschlüssel aus Browser- und Telefoncodes fern. Eine Migration ist eine versionierte Datenbankänderung, die Tabellen erstellt oder aktualisiert. Ein KI-Modell ist der Motor, der antwortet; Der Modellkatalog ist die Liste der verfügbaren Modell-IDs und Preise des Servers. Ein Anbieter ist ein externer Dienst wie ein KI-, E-Mail- oder Abrechnungsdienst. Eine Berechtigung ist eine Bewilligung, die einem Arbeitsbereich die Nutzung einer Funktion ermöglicht. Ein Webhook ist eine Nachricht, die ein Dienst an den URL eines anderen Dienstes sendet.
1. Lösen Sie in der Serveraktion oder Route, die einen benutzereigenen Datensatz liest, vor der Abfrage die Mitgliedschaft des angemeldeten Benutzers und den aktiven workspaceId auf.
2. Bitten Sie Ihren Agenten, einen Fall für zulässige Mitglieder und eine Ablehnung für einen fremden Arbeitsbereich für den genauen Datensatzpfad hinzuzufügen. Geben Sie die beteiligten Rollen und Felder an.
3. Die erste Anfrage sollte erfolgreich sein und die zweite sollte „Kein Datensatz/Zugriff verweigert“ zurückgeben. Wenn durch Ändern nur der Schaltfläche der Zugriff ausgeblendet wird, direkte Anfragen jedoch weiterhin funktionieren, fehlt die Servergrenze.
Beginnen Sie für benutzerdefinierten Code mit dem bereitgestellten prompts/README.md und kopieren Sie die nächstgelegene Eingabeaufforderung: prompts/new-app-screen.md für einen App-Bildschirm oder prompts/new-landing-page.md für eine öffentliche Seite. Geben Sie Ihrem Programmieragenten für Server-, Datenbank- oder Anbieterarbeiten die Aufgabe dieses Handbuchs und bitten Sie ihn, AGENTS.md, .ai/PROJECT_CONTEXT.md und passende .ai/-Spiegel zu lesen; Überprüfen Sie die hier genannten genauen Quelldateien. Listen Sie Dateien auf und prüfen Sie sie vor der Bearbeitung. Bewahren Sie den Arbeitsbereichseigentum und die Nur-Server-Geheimnisse. und zeige dir den Unterschied. Teilen Sie ihm das gewünschte Verhalten, Eingabe- und Ausgabefelder, zulässige Rollen, erwartete Erfolge und Fehler sowie das Testkonto, den Anbieter oder das Gerät mit. Beispielwerte verwenden; Fügen Sie niemals ein echtes Geheimnis ein.
Mitgliedschaft vor Daten prüfen
Die Sitzung bestimmt die Identität; der Server löst den aktiven Workspace auf und prüft Mitgliedschaft und Rolle. Jeder nutzereigene Datensatz verwendet workspaceId. Ein Client-Feld, eine URL-ID oder ein vom Modell ausgewähltes Argument kann diese Eigentumsprüfung nicht ersetzen.
Marketing-Assets der Plattform und Admin-Datensätze der Plattform haben einen ausdrücklich festgelegten Plattformbereich. Erfinde keinen Workspace für anonyme Wartelisten-Einträge.
Grenze durch asynchrone Arbeit weiterführen
Aufgaben, Jobs, Tool-Kontext, API-Schlüssel, Inhalte, Speicher und ausgehende Ereignisse übernehmen den authentifizierten Workspace. Prüfe Ressourcen-IDs gemeinsam mit der Eigentümerschaft. Eine gültige ID aus einem anderen Workspace zuzulassen, ist weiterhin ein Autorisierungsfehler.
Ablehnungstests zuerst schreiben
Kombiniere jede erfolgreiche Änderung oder Abfrage mit Tests für anonyme Aufrufer, fremde Workspaces und unzureichende Rollen. Lege bei der Untersuchung eines verweigerten Zugriffs niemals Geheimnisse offen.
Einrichtung und Konfiguration
rate-limit-runtime stellt den geteilten Limiter, der in Auth-, Checkout-, API- und Submission-Routen verdrahtet ist — erweitere ihn auf neue missbrauchsanfällige Endpunkte, statt pro Route Zähler zu erfinden. Session-Konfiguration, HTTPS-only-Cookies und Provider-Secrets bleiben serverseitig.
Workspace-Audit-Records (audit-runtime.ts) erfassen sicherheitsrelevante Änderungen — Provider-Konfiguration, Member- und Rollen-Updates — und sind unter /settings/audit lesbar.
# Data subject export
src/data-export.ts — assembles a member's
workspace-owned records for account exportImplementierungsablauf
Halte Credentials aus Logs, Error-Payloads, Analytics-Properties und Audit-Werten heraus — die Observability-Schicht redaktiert bekannte Keys, aber Freitext liegt in der Verantwortung des Autors. Löse Autorisierung auf dem Server für jeden Read und Write auf; Interface-Zustand ist Präsentation, kein Beweis.
Account-Datenexport und Löschanfragen laufen über die Account-Grenze, sodass dieselben Ownership-Regeln gelten. Speichere nur die Daten, die das Produkt braucht.
Überprüfung und Fehlerbehebung
Teste den Limiter bis er ein retrybares 429 zurückgibt, verifiziere dass Audit-Zeilen für die Mutationen erscheinen, die sie erzeugen sollen, und exportiere die Daten eines Test-Mitglieds. Probe ein Cross-Workspace-Read pro Release — die billigste Regression, die zählt.