From b97c8ac0479149898514167dcb5273ce5653029c Mon Sep 17 00:00:00 2001
From: mdn-bot <108879845+mdn-bot@users.noreply.github.com>
Date: Wed, 18 Dec 2024 08:36:53 +0000
Subject: [PATCH] chore(de): translate diff [0d945ca6e3]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Machine translation from English using gpt-4o-2024-08-06.

Source: https://github.com/mdn/content/commit/0d945ca6e3ac02395dac9f1638ce6e488ada79f2

System prompt:

```md
You are tasked with translating MDN Web Docs content from English to German.

Ensure that the translation is accurate, preserves technical terminology, and follows the rules provided below.

# Rules for Translation

1. Format:

   - The input is a Markdown file.
   - The output should be a Markdown file.
   - Return the raw output, without wrapping it in a Markdown code block.
   - Keep GFM alert syntax untranslated, such as `> [!NOTE]`, `> [!WARNING]`, and `> [!CALLOUT]`.
   - If the input contains HTML tags wrapped in backticks (e.g. `<video>`), make sure they are wrapped in the output.

2. Language:

   - Prefer formal language ("Sie") over informal language ("du").

3. Code blocks:

   - Do not translate code blocks.
   - Do not translate terms wrapped in backticks.

4. Macro calls:

   - MDN uses macros for dynamic content insertion. These macros must remain **unchanged** and not translated.
   - Macro calls start with `{{`, followed by the macro name, optional parameters, and end with `}}`.
   - Avoid invalid macro calls by ensuring curly braces, parentheses, and quotes are closed properly.

5. Technical terms and code snippets in text:

   - Keep technical terms like element names, attributes, and method names in **English**. Only translate the surrounding descriptive text.

6. Links and References:

   - Translate link descriptions, but keep the URLs and their structure intact.
   - Do not change the locale in URLs.

7. Glossary:

   - "Browser compatibility" => "Browser-Kompatibilität"
   - "Guide" => "Leitfaden"
   - "How to" => "Anleitung"

# Translation Scope

Translate the following Markdown content from **English** to **German** while adhering to the rules above.
```
---
 files/de/_redirects.txt                       |   1 +
 files/de/glossary/clickjacking/index.md       |  18 -
 files/de/glossary/csp/index.md                |   6 +-
 .../other_embedding_technologies/index.md     | 146 ++++----
 .../implementing_a_promise-based_api/index.md |  56 ++--
 .../first_steps/what_is_javascript/index.md   | 238 +++++++------
 .../adding_bouncing_balls_features/index.md   | 109 +++---
 .../apache_configuration_htaccess/index.md    | 224 ++++++-------
 .../server-side/django/introduction/index.md  | 138 ++++----
 .../django/web_application_security/index.md  |  96 +++---
 .../first_steps/website_security/index.md     | 118 +++----
 .../document/requeststorageaccess/index.md    |  52 +--
 .../document/requeststorageaccessfor/index.md |  44 +--
 .../de/web/api/messagechannel/port2/index.md  |  10 +-
 .../web/api/mutationevent/attrchange/index.md |   8 +-
 .../web/api/mutationevent/attrname/index.md   |   6 +-
 files/de/web/api/mutationevent/index.md       |  40 +--
 .../mutationevent/initmutationevent/index.md  |  27 +-
 .../web/api/mutationevent/newvalue/index.md   |   8 +-
 .../web/api/mutationevent/prevvalue/index.md  |   6 +-
 .../api/mutationevent/relatednode/index.md    |   6 +-
 files/de/web/api/storage_access_api/index.md  | 116 +++----
 files/de/web/css/@view-transition/index.md    |  26 +-
 files/de/web/html/element/summary/index.md    |  76 ++---
 files/de/web/http/csp/index.md                | 312 +++++++++---------
 .../web/http/headers/x-frame-options/index.md |  42 +--
 .../security/attacks/clickjacking/index.md    |  72 ++++
 files/de/web/security/attacks/index.md        |  10 +-
 files/de/web/security/index.md                | 166 +++++-----
 .../clickjacking/index.md                     |  38 +--
 .../cookies/index.md                          |  46 +--
 .../practical_implementation_guides/index.md  |  52 +--
 .../de/web/security/types_of_attacks/index.md |  67 ++--
 33 files changed, 1236 insertions(+), 1144 deletions(-)
 delete mode 100644 files/de/glossary/clickjacking/index.md
 create mode 100644 files/de/web/security/attacks/clickjacking/index.md

diff --git a/files/de/_redirects.txt b/files/de/_redirects.txt
index b43a03929..bc6ef94c6 100644
--- a/files/de/_redirects.txt
+++ b/files/de/_redirects.txt
@@ -3557,6 +3557,7 @@
 /de/docs/Glossary/Bézier_curve	/de/docs/Glossary/Bezier_curve
 /de/docs/Glossary/CSS_property	/de/docs/Glossary/property/CSS
 /de/docs/Glossary/Cleartext	/de/docs/Glossary/Plaintext
+/de/docs/Glossary/Clickjacking	/de/docs/Web/Security/Attacks/Clickjacking
 /de/docs/Glossary/Client_hints	/de/docs/Web/HTTP/Client_hints
 /de/docs/Glossary/Condition	/de/docs/Glossary/Conditional
 /de/docs/Glossary/Content_type	/de/docs/Glossary/MIME_type
diff --git a/files/de/glossary/clickjacking/index.md b/files/de/glossary/clickjacking/index.md
deleted file mode 100644
index 1e3cc2608..000000000
--- a/files/de/glossary/clickjacking/index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Clickjacking
-slug: Glossary/Clickjacking
-l10n:
-  sourceCommit: 7e97f3c5ada65b6638909bde92881a4b8d46a2b8
----
-
-{{GlossarySidebar}}
-
-**Clickjacking** ist ein auf Benutzeroberflächen basierender Angriff, der Website-Benutzer dazu verleitet, unbewusst auf bösartige Links zu klicken. Beim Clickjacking betten die Angreifer ihre bösartigen Links in Schaltflächen oder legitime Seiten einer Website ein. In einer infizierten {{Glossary("Site", "Site")}} erhält der Angreifer jedes Mal, wenn ein Benutzer auf einen legitimen Link klickt, vertrauliche Informationen dieses Benutzers, was letztendlich die Privatsphäre des Benutzers im Internet gefährdet.
-
-Clickjacking kann durch die Implementierung einer [Content Security Policy (frame-ancestors)](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) und das Implementieren von [Set-Cookie Attributen](/de/docs/Web/HTTP/Headers/Set-Cookie#attributes) verhindert werden.
-
-## Siehe auch
-
-- [Web-Sicherheit: Schutz vor Clickjacking](/de/docs/Web/Security/Practical_implementation_guides/Clickjacking)
-- [Clickjacking](https://en.wikipedia.org/wiki/Clickjacking) auf Wikipedia
-- [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking) auf OWASP
diff --git a/files/de/glossary/csp/index.md b/files/de/glossary/csp/index.md
index 399c5ba29..afd532ac1 100644
--- a/files/de/glossary/csp/index.md
+++ b/files/de/glossary/csp/index.md
@@ -2,16 +2,16 @@
 title: CSP
 slug: Glossary/CSP
 l10n:
-  sourceCommit: 50e5edd07155de2eec2a8b6b2ad95820748cfec7
+  sourceCommit: 9c09d1ce824bd5e6ef879094428879c476ccbace
 ---
 
 {{GlossarySidebar}}
 
-Eine **CSP** ([Content Security Policy](/de/docs/Web/HTTP/CSP)) wird verwendet, um bestimmte Arten von webbasierten Angriffen zu erkennen und zu mindern, wie z. B. {{Glossary("Cross-site_scripting", "Cross-site_scripting")}}, {{Glossary("clickjacking", "clickjacking")}} und Dateninjektionen.
+Eine **CSP** ([Content Security Policy](/de/docs/Web/HTTP/CSP)) wird verwendet, um bestimmte Arten von Webseitenangriffen wie {{Glossary("Cross-site_scripting", "Cross-site_scripting")}}, [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) und Dateninjektionen zu erkennen und zu mildern.
 
 Die Implementierung basiert auf einem {{Glossary("HTTP", "HTTP")}}-Header namens {{HTTPHeader("Content-Security-Policy")}}.
 
 ## Siehe auch
 
-- [Content Security Policy-Dokumentation](/de/docs/Web/HTTP/CSP)
+- [Content Security Policy Dokumentation](/de/docs/Web/HTTP/CSP)
 - [Content Security Policy auf Wikipedia](https://en.wikipedia.org/wiki/Content_Security_Policy)
diff --git a/files/de/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md b/files/de/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
index 302698b88..c1f79ab7d 100644
--- a/files/de/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
+++ b/files/de/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
@@ -1,13 +1,13 @@
 ---
-title: Von Objekt zu iframe — andere Einbettungstechnologien
+title: Von object zu iframe — andere Einbettungstechnologien
 slug: Learn/HTML/Multimedia_and_embedding/Other_embedding_technologies
 l10n:
-  sourceCommit: baac7f2a43813a7930ff97b11d9c38b413f97c78
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{LearnSidebar}}{{PreviousMenuNext("Learn/HTML/Multimedia_and_embedding/Video_and_audio_content", "Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web", "Learn/HTML/Multimedia_and_embedding")}}
 
-Inzwischen sollten Sie wirklich den Dreh raus haben, wie man Dinge in Ihre Webseiten einbettet, einschließlich Bilder, Videos und Audio. An diesem Punkt möchten wir einen kleinen Seitenschritt machen und einige Elemente betrachten, die es Ihnen ermöglichen, eine Vielzahl von Inhaltstypen in Ihre Webseiten einzubetten: die {{htmlelement("iframe")}}, {{htmlelement("embed")}} und {{htmlelement("object")}} Elemente. `<iframe>`s dienen zum Einbetten anderer Webseiten, während die anderen beiden es Ihnen erlauben, externe Ressourcen wie PDF-Dateien einzubetten.
+Inzwischen sollten Sie wirklich den Dreh raus haben, Inhalte wie Bilder, Videos und Audio in Ihre Webseiten einzubetten. An dieser Stelle möchten wir einen kleinen Seitensprung machen und uns einige Elemente ansehen, mit denen Sie eine Vielzahl von Inhaltstypen in Ihre Webseiten einbetten können: die {{htmlelement("iframe")}}, {{htmlelement("embed")}} und {{htmlelement("object")}} Elemente. `<iframe>`s sind zum Einbetten anderer Webseiten gedacht, während die anderen beiden es Ihnen ermöglichen, externe Ressourcen wie PDF-Dateien einzubetten.
 
 <table>
   <tbody>
@@ -17,55 +17,55 @@ Inzwischen sollten Sie wirklich den Dreh raus haben, wie man Dinge in Ihre Webse
         <a
           href="/de/docs/Learn/Getting_started_with_the_web/Installing_basic_software"
           >Grundlegende Software installiert</a
-        >, grundlegendes Wissen über
+        >, Grundkenntnisse in
         <a
           href="/de/docs/Learn/Getting_started_with_the_web/Dealing_with_files"
-          >den Umgang mit Dateien</a
-        >, Vertrautheit mit HTML-Grundlagen (wie behandelt in
+          >Umgang mit Dateien</a
+        >, Vertrautheit mit den Grundlagen von HTML (wie im
         <a href="/de/docs/Learn/HTML/Introduction_to_HTML/Getting_started"
-          >Erste Schritte mit HTML</a
-        >) und den vorherigen Artikeln in diesem Modul.
+          >Einstieg in HTML</a
+        >) und den vorherigen Artikeln in diesem Modul behandelt.
       </td>
     </tr>
     <tr>
       <th scope="row">Ziel:</th>
       <td>
-        Zu lernen, wie man Elemente auf Webseiten mit
+        Lernen, wie man Gegenstände in Webseiten mit
         {{htmlelement("object")}}, {{htmlelement("embed")}} und
-        {{htmlelement("iframe")}} einbettet, wie PDF-Dokumente und andere Webseiten.
+        {{htmlelement("iframe")}} einbettet, wie z.B. PDF-Dokumente und andere Webseiten.
       </td>
     </tr>
   </tbody>
 </table>
 
-## Eine kurze Geschichte der Einbettung
+## Eine kurze Geschichte des Einbettens
 
-Vor langer Zeit im Web war es beliebt, **Frames** zu verwenden, um Websites zu erstellen — kleine Teile einer Website, die in einzelnen HTML-Seiten gespeichert sind. Diese wurden in ein Master-Dokument eingebettet, das als **Frameset** bezeichnet wurde. Damit konnten Sie den Bereich auf dem Bildschirm angeben, den jeder Frame ausfüllte, ähnlich wie die Größe von Spalten und Reihen einer Tabelle. Diese galten in den mittleren bis späten 90er Jahren als der Gipfel der Coolness, und es gab Hinweise darauf, dass das Aufteilen einer Webseite in kleinere Teile wie dieses besser für Downloadgeschwindigkeiten war — besonders bemerkbar bei so langsamen Netzverbindungen wie damals. Sie hatten allerdings viele Probleme, die alle Vorteile bei schneller werdenden Netzgeschwindigkeiten weit überwogen, weshalb Sie sie heutzutage nicht mehr verwendet sehen.
+Vor langer Zeit war es auf dem Web populär, **Frames** zur Erstellung von Webseiten zu verwenden – kleine Teile einer Website, die in einzelnen HTML-Seiten gespeichert wurden. Diese wurden in ein Hauptdokument namens **Frameset** eingebettet, das es Ihnen ermöglichte, den Bereich auf dem Bildschirm zu spezifizieren, den jeder Frame füllte, ähnlich wie das Größen von Spalten und Zeilen einer Tabelle. Diese wurden in den mittleren bis späten 90er Jahren als das Höchste der Coolness angesehen, und es gab Hinweise darauf, dass das Aufteilen einer Webseite in kleinere Teile, wie es dadurch geschieht, für schnellere Download-Geschwindigkeiten besser war – was besonders bei damals so langsamen Netzwerkverbindungen bemerkbar war. Sie hatten jedoch viele Probleme, die alle positiven Aspekte bei weitem überwogen, als die Netzwerkgeschwindigkeiten schneller wurden, sodass man sie heute nicht mehr sieht.
 
-Wenig später (Ende der 90er Jahre, Anfang der 2000er Jahre) wurden Plug-in-Technologien sehr populär, wie {{Glossary("Java", "Java-Applets")}} und {{Glossary("Adobe_Flash", "Flash")}} — diese ermöglichten es Webentwicklern, reichhaltige Inhalte wie Videos und Animationen in Webseiten einzubetten, die allein durch HTML nicht verfügbar waren. Diese Technologien wurden durch Elemente wie {{htmlelement("object")}} und das weniger genutzte {{htmlelement("embed")}} eingebettet und waren damals sehr nützlich. Sie sind seither aufgrund vieler Probleme, einschließlich Zugänglichkeit, Sicherheit, Dateigröße und mehr, aus der Mode gekommen. Heute haben große Browser aufgehört, Plug-ins wie Flash zu unterstützen.
+Ein wenig später (Ende der 90er, Anfang der 2000er Jahre) wurden Plugin-Technologien wie {{Glossary("Java", "Java Applets")}} und {{Glossary("Adobe_Flash", "Flash")}} sehr populär — diese ermöglichten es Webentwicklern, reichhaltige Inhalte wie Videos und Animationen in Webseiten einzubetten, die nur durch HTML alleine nicht verfügbar waren. Das Einbetten dieser Technologien wurde durch Elemente wie {{htmlelement("object")}} und das weniger verwendete {{htmlelement("embed")}} erreicht, und sie waren damals sehr nützlich. Sie sind inzwischen aus der Mode gekommen wegen vieler Probleme, einschließlich Zugänglichkeit, Sicherheit, Dateigröße und mehr. Heutzutage haben große Browser aufgehört, Plugins wie Flash zu unterstützen.
 
-Schließlich erschien das {{htmlelement("iframe")}}-Element (zusammen mit anderen Möglichkeiten zur Einbettung von Inhalten, wie {{htmlelement("canvas")}}, {{htmlelement("video")}}, usw.) Es bietet eine Möglichkeit, ein gesamtes Webdokument in ein anderes einzubetten, als ob es ein {{htmlelement("img")}} oder ein ähnliches Element wäre, und wird heute regelmäßig verwendet.
+Schließlich erschien das {{htmlelement("iframe")}}-Element (zusammen mit anderen Möglichkeiten zur Einbettung von Inhalten wie {{htmlelement("canvas")}}, {{htmlelement("video")}}, etc.). Es bietet eine Möglichkeit, ein ganzes Webdokument in ein anderes einzubetten, als ob es sich um ein {{htmlelement("img")}} oder ein anderes solches Element handelt, und wird heute regelmäßig verwendet.
 
-Mit der Geschichtsstunde aus dem Weg, lassen Sie uns weitermachen und sehen, wie einige dieser Technologien verwendet werden.
+Nachdem wir den Geschichtsunterricht abgeschlossen haben, lassen Sie uns weitermachen und sehen, wie wir einige dieser Technologien nutzen können.
 
-## Aktives Lernen: Klassische Einbettungsanwendungen
+## Aktives Lernen: Klassische Einbettungsverwendung
 
-In diesem Artikel steigen wir direkt in einen aktiven Lernabschnitt ein, um Ihnen sofort eine reale Vorstellung davon zu geben, wofür Einbettungstechnologien nützlich sind. Die Online-Welt ist sehr vertraut mit [YouTube](https://www.youtube.com/), aber viele Menschen kennen einige der Freigabemöglichkeiten nicht, die es bietet. Lassen Sie uns betrachten, wie YouTube es uns ermöglicht, ein Video auf jeder Seite einzufügen, die wir mögen, mit einem {{htmlelement("iframe")}}.
+In diesem Artikel tauchen wir direkt in einen aktiven Lernabschnitt ein, um Ihnen sofort eine wirkliche Vorstellung davon zu geben, wofür Einbettungstechnologien nützlich sind. Die Onlinewelt ist sehr vertraut mit [YouTube](https://www.youtube.com/), aber viele Leute wissen nicht über einige der verfügbaren Sharing-Funktionen. Lassen Sie uns ansehen, wie YouTube uns ermöglicht, ein Video in jede Seite, die wir mögen, mit einem {{htmlelement("iframe")}} einzubetten.
 
-1. Gehen Sie zuerst zu YouTube und suchen Sie ein Video, das Ihnen gefällt.
-2. Unter dem Video finden Sie einen _Teilen_ Button — klicken Sie darauf, um die Freigabeoptionen anzuzeigen.
-3. Wählen Sie den _Einbetten_ Button und Sie erhalten einige `<iframe>`-Code — kopieren Sie diesen.
+1. Gehen Sie zuerst zu YouTube und finden Sie ein Video, das Ihnen gefällt.
+2. Unter dem Video finden Sie einen _Teilen_-Button – wählen Sie diesen aus, um die Sharing-Optionen anzuzeigen.
+3. Wählen Sie den _Einbetten_-Button und Sie erhalten einige `<iframe>`-Code – kopieren Sie diesen.
 4. Fügen Sie ihn in das _Input_-Feld unten ein und sehen Sie, was das Ergebnis im _Output_ ist.
 
-Für Bonuspunkte könnten Sie auch versuchen, eine [Google Karte](https://www.google.com/maps/) in das Beispiel einzubetten:
+Als Bonus könnten Sie auch versuchen, eine [Google Map](https://www.google.com/maps/) im Beispiel einzubetten:
 
-1. Gehen Sie zu Google Maps und suchen Sie eine Karte, die Ihnen gefällt.
-2. Klicken Sie auf das "Hamburger-Menü" (drei horizontale Linien) in der oberen linken Ecke der Benutzeroberfläche.
-3. Wählen Sie die Option _Karte teilen oder einbetten_.
-4. Wählen Sie die Karte einbetten Option, die Ihnen einige `<iframe>`-Code gibt — kopieren Sie diesen.
+1. Gehen Sie zu Google Maps und finden Sie eine Karte, die Ihnen gefällt.
+2. Klicken Sie auf das "Hamburger Menü" (drei horizontale Linien) oben links in der Benutzeroberfläche.
+3. Wählen Sie die Option _Karte teilen oder einbetten_ aus.
+4. Wählen Sie die Option Karte einbetten, die Ihnen einige `<iframe>`-Code geben wird – kopieren Sie diesen.
 5. Fügen Sie ihn in das _Input_-Feld unten ein und sehen Sie, was das Ergebnis im _Output_ ist.
 
-Wenn Sie einen Fehler machen, können Sie ihn immer mit dem _Reset_ Button zurücksetzen. Wenn Sie wirklich feststecken, drücken Sie die _Show solution_ Taste, um eine Antwort zu sehen.
+Wenn Sie einen Fehler machen, können Sie es immer mit dem _Zurücksetzen_ Button zurücksetzen. Wenn Sie wirklich feststecken, drücken Sie den _Lösung anzeigen_ Button, um eine Antwort zu sehen.
 
 ```html hidden
 <h2>Live output</h2>
@@ -198,9 +198,9 @@ textarea.onkeyup = function () {
 
 ## iframes im Detail
 
-Das war einfach und hat Spaß gemacht, oder? {{htmlelement("iframe")}}-Elemente sind so konzipiert, dass Sie andere Webdokumente in das aktuelle Dokument einbetten können. Dies ist großartig für das Einbinden von Drittanbieter-Inhalten in Ihre Website, über die Sie möglicherweise keine direkte Kontrolle haben und die Sie nicht selbst implementieren möchten — wie Videos von Online-Videodiensten, Kommentarsysteme wie [Disqus](https://disqus.com/), Karten von Online-Kartenanbietern, Werbebanner usw. Sogar die live bearbeitbaren Beispiele, die Sie während dieses Kurses verwendet haben, sind mit `<iframe>`s implementiert.
+Das war einfach und macht Spaß, nicht wahr? {{htmlelement("iframe")}}-Elemente sind dazu gedacht, andere Webdokumente in das aktuelle Dokument einzubetten. Dies ist großartig, um Drittanbieterinhalte in Ihre Webseite zu integrieren, über die Sie möglicherweise keine direkte Kontrolle haben und die Sie nicht selbst implementieren möchten — wie Videos von Online-Videodiensten, Kommentarsysteme wie [Disqus](https://disqus.com/), Karten von Online-Kartenanbietern, Werbebanner, usw. Sogar die live bearbeitbaren Beispiele, die Sie in diesem Kurs verwendet haben, werden mit `<iframe>`s implementiert.
 
-Bevor Sie in die Verwendung von `<iframe>`-Elementen eintauchen, gibt es einige Sicherheitsbedenken, die beachtet werden müssen. Angenommen, Sie möchten das MDN-Glossar auf einer Ihrer Webseiten mit dem {{htmlelement("iframe")}}-Element einfügen, Sie könnten dann versuchen, etwas Ähnliches wie das nächste Code-Beispiel zu machen. Wenn Sie den folgenden Code in eine Ihrer Seiten einfügen, könnten Sie überrascht sein, eine Fehlermeldung anstelle der Glossarseite zu sehen:
+Bevor Sie sich in die Nutzung von `<iframe>`-Elementen stürzen, sollten Sie sich einiger Sicherheitsbedenken bewusst sein. Angenommen, Sie möchten das MDN-Glossar auf eine Ihrer Webseiten mit dem {{htmlelement("iframe")}}-Element einbinden, dann könnten Sie etwas wie das nächste Codebeispiel versuchen. Wenn Sie den unten stehenden Code in eine Ihrer Seiten einfügen, könnten Sie überrascht sein, eine Fehlermeldung anstelle der Glossarseite zu sehen:
 
 ```html
 <head>
@@ -226,86 +226,87 @@ Bevor Sie in die Verwendung von `<iframe>`-Elementen eintauchen, gibt es einige
 </body>
 ```
 
-Wenn Sie sich die Konsole Ihres Browsers ansehen, sehen Sie eine Fehlermeldung wie die folgende:
+Wenn Sie sich die Konsole Ihres Browsers ansehen, sehen Sie eine Fehlermeldung ähnlich der folgenden:
 
 ```plain
 Refused to display 'https://developer.mozilla.org/' in a frame because it set 'X-Frame-Options' to 'deny'.
 ```
 
-Der [Sicherheitsbereich](#sicherheitsbedenken) unten geht genauer darauf ein, warum diese Fehlermeldung erscheint, doch zunächst sehen wir uns an, was unser Code macht.
+Der Abschnitt [Sicherheit](#sicherheitsbedenken) weiter unten geht detaillierter darauf ein, warum Sie diese Fehlermeldung sehen, aber zuerst schauen wir uns an, was unser Code tut.
 
-Das Beispiel enthält das Nötigste, um ein `<iframe>` zu verwenden:
+Das Beispiel umfasst die wesentlichen Grundlagen, die zur Verwendung eines `<iframe>`s benötigt werden:
 
 - [`border: none`](/de/docs/Web/CSS/border)
-  - : Wird diese Option verwendet, wird das `<iframe>` ohne umgebenden Rahmen angezeigt. Andernfalls zeigen Browser das `<iframe>` standardmäßig mit einem umgebenden Rahmen an (was im Allgemeinen unerwünscht ist).
+  - : Wenn verwendet, wird das `<iframe>` ohne umgebenden Rahmen angezeigt. Andernfalls zeigen Browser standardmäßig das `<iframe>` mit einem umgebenden Rahmen an (was im Allgemeinen unerwünscht ist).
 - [`allowfullscreen`](/de/docs/Web/HTML/Element/iframe#allowfullscreen)
-  - : Ist dieses Attribut gesetzt, kann das `<iframe>` im Vollbildmodus mithilfe der [Fullscreen API](/de/docs/Web/API/Fullscreen_API) (ein wenig außerhalb des Umfangs dieses Artikels) angezeigt werden.
+  - : Wenn festgelegt, kann das `<iframe>` im Vollbildmodus mittels der [Fullscreen API](/de/docs/Web/API/Fullscreen_API) angezeigt werden (etwas außerhalb des Umfangs dieses Artikels).
 - [`src`](/de/docs/Web/HTML/Element/iframe#src)
-  - : Dieses Attribut, wie bei {{htmlelement("video")}}/{{htmlelement("img")}}, enthält einen Pfad zur URL des einzubettenden Dokuments.
+  - : Dieses Attribut enthält, wie bei {{htmlelement("video")}}/{{htmlelement("img")}}, einen Pfad, der auf die URL des einzubettenden Dokuments zeigt.
 - [`width`](/de/docs/Web/HTML/Element/iframe#width) und [`height`](/de/docs/Web/HTML/Element/iframe#height)
-  - : Diese Attribute geben an, welche Breite und Höhe das `iframe` haben soll.
+  - : Diese Attribute geben die Breite und Höhe an, die Sie für das iframe wünschen.
 - [`sandbox`](/de/docs/Web/HTML/Element/iframe#sandbox)
-  - : Dieses Attribut, das in etwas moderneren Browsern als der Rest der `<iframe>`-Funktionen funktioniert (z.B. IE 10 und höher), fordert erhöhte Sicherheitseinstellungen an; dazu mehr im nächsten Abschnitt.
+  - : Dieses Attribut, das in etwas moderneren Browsern funktioniert als der Rest der `<iframe>`-Funktionen (z. B. IE 10 und höher), fordert erhöhte Sicherheitseinstellungen an; wir werden im nächsten Abschnitt mehr dazu sagen.
 
 > [!NOTE]
-> Um die Geschwindigkeit zu verbessern, ist es eine gute Idee, das `src`-Attribut des iframes mit JavaScript zu setzen, nachdem der Hauptinhalt geladen wurde. Dadurch wird Ihre Seite früher nutzbar und die offizielle Ladezeit der Seite (eine wichtige {{Glossary("SEO", "SEO")}}-Metrik) verringert.
+> Um die Geschwindigkeit zu verbessern, ist es eine gute Idee, das `src`-Attribut des iframes mit JavaScript zu setzen, nachdem der Hauptinhalt geladen ist. Dies macht Ihre Seite schneller nutzbar und verringert Ihre offizielle Ladezeit der Seite (eine wichtige {{Glossary("SEO", "SEO")}} Metrik).
 
 ### Sicherheitsbedenken
 
-Oben haben wir Sicherheitsbedenken erwähnt — lassen Sie uns das jetzt etwas genauer betrachten. Wir erwarten nicht, dass Sie all diese Inhalte beim ersten Mal perfekt verstehen; wir möchten Sie nur auf dieses Problem aufmerksam machen und eine Referenz bereitstellen, auf die Sie zurückkommen können, wenn Sie erfahrener werden und beginnen, `<iframe>`s in Ihren Experimenten und Arbeiten zu verwenden. Außerdem besteht kein Grund zur Angst, `<iframe>`s nicht zu verwenden — Sie müssen nur vorsichtig sein. Lesen Sie weiter…
+Oben haben wir Sicherheitsbedenken erwähnt — lassen Sie uns jetzt etwas detaillierter darauf eingehen. Es wird nicht erwartet, dass Sie all diese Inhalte beim ersten Mal perfekt verstehen; wir wollen Ihnen nur dieses Anliegen bewusst machen und eine Referenz bereitstellen, zu der Sie zurückkehren können, wenn Sie mehr Erfahrung sammeln und beginnen, `<iframe>`s in Ihren Experimenten und Arbeiten in Betracht zu ziehen. Außerdem besteht kein Grund zur Panik und dazu, `<iframe>`s nicht zu verwenden — Sie müssen nur vorsichtig sein. Lesen Sie weiter...
 
-Browserentwickler und Webentwickler haben auf die harte Tour gelernt, dass iframes ein häufiges Ziel (offizieller Begriff: **Angriffsvektor**) für böswillige Personen im Web (oft als **Hacker** oder genauer als **Cracker** bezeichnet) sind, wenn sie versuchen, Ihre Webseite böswillig zu ändern oder Menschen dazu zu bringen, etwas zu tun, was sie nicht tun möchten, wie z.B. sensible Informationen wie Benutzernamen und Passwörter preiszugeben. Aus diesem Grund haben Spezifikationsingenieure und Browserentwickler verschiedene Sicherheitsmechanismen entwickelt, um `<iframe>`s sicherer zu machen, und es gibt auch bewährte Praktiken, die zu berücksichtigen sind — wir werden einige dieser Punkte unten behandeln.
+Browserhersteller und Webentwickler haben es auf die harte Tour gelernt, dass iframes ein häufiges Ziel (offizieller Ausdruck: **Angriffsvektor**) für böse Menschen im Web (oft als **Hacker** oder genauer gesagt als **Cracker** bezeichnet) sind, die versuchen, Ihre Webseite böswillig zu verändern oder Menschen dazu zu verleiten, etwas zu tun, das sie nicht wollen, wie z.B. sensible Informationen wie Benutzernamen und Passwörter preiszugeben. Aus diesem Grund haben Spezifikations-Ingenieure und Browser-Entwickler verschiedene Sicherheitsmechanismen entwickelt, um `<iframe>`s sicherer zu machen, und es gibt auch bewährte Praktiken, die man beachten sollte — einige davon werden wir hier behandeln.
 
-> **Hinweis:** {{Glossary("Clickjacking", "Clickjacking")}} ist eine Art häufiger iframe-Angriff, bei dem Hacker ein unsichtbares iframe in Ihr Dokument einbetten (oder Ihr Dokument in ihre eigene bösartige Website einbetten) und es verwenden, um Interaktionen der Benutzer zu erfassen. Dies ist eine häufige Methode, um Benutzer zu täuschen oder sensible Daten zu stehlen.
+> **Hinweis:** [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) ist eine Art von häufigem iframe-Angriff, bei dem Hacker ein unsichtbares iframe in Ihr Dokument einbetten (oder Ihr Dokument in ihre eigene bösartige Webseite einbetten) und es verwenden, um die Interaktionen der Benutzer einzufangen. Dies ist eine verbreitete Methode, um Benutzer zu täuschen oder sensible Daten zu stehlen.
 
-Ein schnelles Beispiel zuerst — versuchen Sie, das vorher gezeigte Beispiel in Ihrem Browser zu laden — Sie können es [live auf GitHub finden](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) ([sehen Sie sich auch den Quellcode](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) an). Anstelle der erwarteten Seite werden Sie wahrscheinlich eine Nachricht wie "Ich kann diese Seite nicht öffnen" sehen, und wenn Sie im _Konsolen_ Bereich der [Entwicklertools des Browsers](/de/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools) nachsehen, erhalten Sie eine Nachricht, die Ihnen erklärt, warum. In Firefox erhalten Sie eine Meldung wie _Das Laden von "https\://developer.mozilla.org/de/docs/Glossary" in einem Frame wird durch die "X-Frame-Options"-Direktive mit "DENY" verweigert_. Dies liegt daran, dass die Entwickler von MDN eine Einstellung auf dem Server integriert haben, der die Webseiten bereitstellt, um zu verhindern, dass sie in `<iframe>`s eingebettet werden (siehe [Konfigurieren von CSP-Direktiven](#konfigurieren_sie_csp-direktiven), unten). Das ergibt Sinn — eine gesamte MDN-Seite macht wirklich keinen Sinn, in andere Seiten eingebettet zu werden, es sei denn, Sie möchten etwas wie sie in Ihre Website einbetten und als Ihre eigenen beanspruchen — oder versuchen, Daten über {{Glossary("Clickjacking", "Clickjacking")}} zu stehlen, was beides wirklich schlechte Dinge sind. Plus, wenn das jeder anfangen würde, würde all die zusätzliche Bandbreite Mozilla eine Menge Geld kosten.
+Ein schnelles Beispiel zuerst — versuchen Sie das vorherige Beispiel, das wir oben gezeigt haben, in Ihrem Browser zu laden — Sie können es [live auf GitHub finden](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) (sehen Sie sich auch den [Quellcode](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) an). Statt der erwarteten Seite sehen Sie wahrscheinlich eine Art von Nachricht im Sinne von "Ich kann diese Seite nicht öffnen", und wenn Sie sich die _Konsole_ in den [Entwicklerwerkzeugen des Browsers](/de/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools) ansehen, erhalten Sie eine Nachricht die Ihnen erklärt warum. In Firefox werden Sie wahrscheinlich so etwas wie _Das Laden von "https:\://developer.mozilla.org/de/docs/Glossary" in einem Frame wird von "X-Frame-Options"-Directive auf "DENY" eingestellt verweigert._ Dies liegt daran, dass die Entwickler, die MDN gebaut haben, eine Einstellung auf dem Server, der die Webseiten bereitstellt, enthalten, um das Einbetten in `<iframe>`s zu verbieten (siehe [Befehlen Sie CSP-Direktiven konfigurieren](#csp-direktiven_konfigurieren), unten). Dies macht Sinn — eine gesamte MDN-Seite macht wirklich keinen Sinn, um in andere Seiten eingebettet zu werden, es sei denn, Sie möchten sie auf Ihrer Seite einbetten und als Ihre eigene beanspruchen — oder versuchen, Daten über Clickjacking zu stehlen, was beides wirklich schlechte Dinge sind, die man tun kann. Wenn alle damit anfangen würden, würde die zusätzliche Bandbreite Mozilla viel Geld kosten.
 
-#### Nur einbetten, wenn notwendig
+#### Nur einbetten, wenn es notwendig ist
 
-Manchmal macht es Sinn, Inhalte von Drittanbietern einzubetten — wie YouTube-Videos und Karten — aber Sie können sich viele Kopfschmerzen ersparen, wenn Sie Inhalte von Drittanbietern nur dann einbetten, wenn es absolut notwendig ist. Eine gute Regel für Websicherheit ist: _"Man kann nie zu vorsichtig sein. Wenn Sie es gemacht haben, überprüfen Sie es nochmal. Wenn es jemand anderes gemacht hat, gehen Sie davon aus, dass es gefährlich ist, bis das Gegenteil bewiesen ist."_
+Manchmal macht es Sinn, Drittanbieterinhalte einzubetten — wie YouTube-Videos und Karten — aber Sie können sich viele Kopfschmerzen ersparen, wenn Sie nur dann Drittanbieterinhalte einbetten, wenn es wirklich notwendig ist. Eine gute Regel für die Websicherheit lautet _"Man kann nie vorsichtig genug sein. Wenn Sie es gemacht haben, überprüfen Sie es trotzdem doppelt. Wenn es jemand anders gemacht hat, nehmen Sie an, dass es gefährlich ist, bis das Gegenteil bewiesen wird."_
 
-Neben der Sicherheit sollten Sie sich auch der Probleme des geistigen Eigentums bewusst sein. Die meisten Inhalte sind urheberrechtlich geschützt, offline und online, sogar Inhalte, bei denen Sie es vielleicht nicht erwarten (z.B. die meisten Bilder auf [Wikimedia Commons](https://commons.wikimedia.org/wiki/Main_Page)). Zeigen Sie niemals Inhalte auf Ihrer Webseite an, es sei denn, Sie besitzen sie oder die Eigentümer haben Ihnen schriftlich, eindeutig die Erlaubnis gegeben. Die Strafen für Urheberrechtsverletzungen sind streng. Wiederum, Vorsicht ist geboten.
+Neben der Sicherheit sollten Sie sich auch der Fragen des geistigen Eigentums bewusst sein. Die meisten Inhalte sind urheberrechtlich geschützt, offline und online, auch Inhalte, die Sie vielleicht nicht erwarten (zum Beispiel die meisten Bilder auf [Wikimedia Commons](https://commons.wikimedia.org/wiki/Main_Page)). Zeigen Sie niemals Inhalte auf Ihrer Webseite an, es sei denn, Sie besitzen sie oder die Eigentümer haben Ihnen schriftlich eine unmissverständliche Erlaubnis erteilt. Die Strafen für Urheberrechtsverletzungen sind schwerwiegend. Auch hier: Sie können nie vorsichtig genug sein.
 
-Wenn der Inhalt lizenziert ist, müssen Sie die Lizenzbedingungen einhalten. Zum Beispiel ist der Inhalt auf MDN [unter CC-BY-SA lizenziert](/de/docs/MDN/Writing_guidelines/Attrib_copyright_license#documentation). Das bedeutet, dass Sie [uns ordnungsgemäß attribuieren müssen](https://wiki.creativecommons.org/wiki/Best_practices_for_attribution), wenn Sie unseren Inhalt zitieren, selbst wenn Sie erhebliche Änderungen vornehmen.
+Wenn der Inhalt lizenziert ist, müssen Sie die Lizenzbedingungen einhalten. Zum Beispiel ist der Inhalt auf MDN [lizenziert unter CC-BY-SA](/de/docs/MDN/Writing_guidelines/Attrib_copyright_license#documentation). Das bedeutet, dass Sie [uns ordnungsgemäß erwähnen](https://wiki.creativecommons.org/wiki/Best_practices_for_attribution) müssen, wenn Sie unseren Inhalt zitieren, auch wenn Sie wesentliche Änderungen vornehmen.
 
-#### Nutzen Sie HTTPS
+#### Verwenden Sie HTTPS
 
-{{Glossary("HTTPS", "HTTPS")}} ist die verschlüsselte Version von {{Glossary("HTTP", "HTTP")}}. Sie sollten Ihre Webseiten wann immer möglich über HTTPS bereitstellen:
+{{Glossary("HTTPS", "HTTPS")}} ist die verschlüsselte Version von {{Glossary("HTTP", "HTTP")}}. Sie sollten Ihre Webseiten immer dann mit HTTPS ausliefern, wenn dies möglich ist:
 
-1. HTTPS verringert die Chance, dass entfernte Inhalte während der Übertragung manipuliert werden.
+1. HTTPS verringert die Wahrscheinlichkeit, dass entfernte Inhalte während der Übertragung manipuliert werden.
 2. HTTPS verhindert, dass eingebettete Inhalte auf Inhalte in Ihrem übergeordneten Dokument zugreifen, und umgekehrt.
 
-Die HTTPS-Bereitstellung Ihrer Seite erfordert ein spezielles Sicherheitszertifikat. Viele Hosting-Anbieter bieten HTTPS-fähiges Hosting, ohne dass Sie ein eigenes Setup zur Bereitstellung eines Zertifikats benötigen. Wenn Sie jedoch HTTPS-Unterstützung für Ihre Seite selbst einrichten müssen, bietet [Let's Encrypt](https://letsencrypt.org/) Tools und Anleitungen, die Ihnen beim automatischen Erstellen und Installieren des erforderlichen Zertifikats helfen — mit eingebauter Unterstützung für die am weitesten verbreiteten Webserver, einschließlich des Apache-Webservers, Nginx und anderer. Die Let's Encrypt-Tools sind so konzipiert, dass der Prozess so einfach wie möglich ist, sodass es wirklich keinen guten Grund gibt, deren Nutzung oder andere verfügbare Mittel zur HTTPS-Bereitstellung Ihrer Seite zu vermeiden.
+Das Aktivieren von HTTPS für Ihre Seite erfordert ein spezielles Sicherheitszertifikat. Viele Hosting-Anbieter bieten HTTPS-fähiges Hosting an, ohne dass Sie selbst eine Einrichtung vornehmen müssen, um ein Zertifikat zu installieren. Wenn Sie jedoch die HTTPS-Unterstützung für Ihre Seite selbst einrichten müssen, bietet [Let's Encrypt](https://letsencrypt.org/) Werkzeuge und Anweisungen, die Sie zur automatischen Erstellung und Installation des erforderlichen Zertifikats verwenden können — mit eingebauter Unterstützung für die am meisten verbreiteten Webserver, einschließlich des Apache-Webservers, Nginx und anderer. Das Let's Encrypt-Tooling ist darauf ausgelegt, den Prozess so einfach wie möglich zu gestalten, sodass es wirklich keinen guten Grund gibt, es oder andere verfügbare Mittel zur HTTPS-Aktivierung Ihrer Seite nicht zu nutzen.
 
-> **Hinweis:** [GitHub Pages](/de/docs/Learn/Common_questions/Tools_and_setup/Using_GitHub_pages) erlauben standardmäßig das Bereitstellen von Inhalten über HTTPS. Wenn Sie einen anderen Hosting-Anbieter verwenden, sollten Sie prüfen, welche Unterstützung er für das Bereitstellen von Inhalten mit HTTPS bietet.
+> **Hinweis:** [GitHub-Seiten](/de/docs/Learn/Common_questions/Tools_and_setup/Using_GitHub_pages) ermöglichen standardmäßig die Bereitstellung von Inhalten über HTTPS.
+> Wenn Sie einen anderen Hosting-Anbieter verwenden, sollten Sie überprüfen, welche Unterstützung dieser für die Bereitstellung von Inhalten mit HTTPS bietet.
 
 #### Verwenden Sie immer das `sandbox`-Attribut
 
-Sie wollen Angreifern so wenig Macht wie möglich geben, um schlechte Dinge auf Ihrer Website zu tun. Daher sollten Sie eingebetteten Inhalten _nur die Berechtigungen geben, die für die Erfüllung ihrer Aufgabe notwendig sind._ Natürlich gilt dies auch für Ihre eigenen Inhalte. Ein Container für Code, wo dieser angemessen verwendet werden kann — oder zum Testen — und nicht in der Lage ist, dem restlichen Codebestand Schaden zuzufügen (entweder versehentlich oder böswillig), wird als [Sandbox](<https://de.wikipedia.org/wiki/Sandbox_(Computersicherheit)>) bezeichnet.
+Sie möchten Angreifern so wenig Macht wie möglich geben, schlechte Dinge auf Ihrer Webseite zu tun, daher sollten Sie eingebetteten Inhalten _nur die Berechtigungen geben, die nötig sind, um ihre Arbeit zu erledigen_. Natürlich gilt dies auch für Ihre eigenen Inhalte. Ein Container für Code, in dem er geeignet verwendet werden kann — oder zum Testen — aber keinen Schaden am Rest der Codebasis (entweder versehentlich oder böswillig) verursachen kann, wird als [Sandbox](<https://en.wikipedia.org/wiki/Sandbox_(computer_security)>) bezeichnet.
 
-Inhalte, die nicht gesandboxed sind, könnten möglicherweise JavaScript ausführen, Formulare absenden, Popup-Fenster auslösen usw. Standardmäßig sollten Sie alle verfügbaren Einschränkungen durch die Verwendung des `sandbox`-Attributs ohne Parameter auferlegen, wie in unserem vorherigen Beispiel gezeigt.
+Nicht sandboxed Inhalte können möglicherweise JavaScript ausführen, Formulare absenden, Popup-Fenster auslösen usw. Standardmäßig sollten Sie mit dem `sandbox`-Attribut ohne Parameter alle verfügbaren Einschränkungen auferlegen, wie in unserem vorherigen Beispiel gezeigt.
 
-Wenn absolut erforderlich, können Sie Berechtigungen einzeln wieder hinzufügen (innerhalb des `sandbox=""`-Attributwerts) — siehe die [`sandbox`](/de/docs/Web/HTML/Element/iframe#sandbox)-Referenzeintrag für alle verfügbaren Optionen. Ein wichtiger Hinweis ist, dass Sie _niemals_ sowohl `allow-scripts` als auch `allow-same-origin` zu Ihrem `sandbox`-Attribut hinzufügen sollten — in diesem Fall könnte der eingebettete Inhalt die {{Glossary("Same-origin_policy", "Same-Origin-Policy")}} umgehen, die verhindert, dass Websites Skripte ausführen, und JavaScript verwenden, um das Sandboxen ganz auszuschalten.
+Wenn unbedingt erforderlich, können Sie Berechtigungen einzeln wieder hinzufügen (innerhalb des `sandbox=""`-Attributwerts) — siehe den [`sandbox`](/de/docs/Web/HTML/Element/iframe#sandbox) Referenzeintrag für alle verfügbaren Optionen. Ein wichtiger Hinweis ist, dass Sie _niemals_ sowohl `allow-scripts` als auch `allow-same-origin` zu Ihrem `sandbox`-Attribut hinzufügen sollten — in diesem Fall könnte der eingebettete Inhalt die {{Glossary("Same-origin_policy", "Same-origin policy")}} umgehen, die das Ausführen von Skripten aufhält, und JavaScript verwenden, um die Sandbox-Einschränkungen ganz aufzuheben.
 
 > [!NOTE]
-> Sandboxen bietet keinen Schutz, wenn Angreifer Menschen direkt zu bösartigen Inhalten (außerhalb eines `iframe`) verleiten können. Wenn es eine Wahrscheinlichkeit gibt, dass bestimmte Inhalte bösartig sein könnten (z.B. nutzergenerierte Inhalte), sollten diese von einer anderen {{Glossary("domain", "Domain")}} als Ihrer Hauptseite bereitgestellt werden.
+> Das Sandboxen bietet keinen Schutz, wenn Angreifer Menschen täuschen können, bösartige Inhalte direkt zu besuchen (außerhalb eines `iframe`). Wenn eine Chance besteht, dass bestimmte Inhalte bösartig sein könnten (z.B. nutzergenerierte Inhalte), stellen Sie bitte sicher, dass diese von einer anderen {{Glossary("domain", "Domain")}} als Ihre Hauptseite bereitgestellt werden.
 
-#### Konfigurieren Sie CSP-Direktiven
+#### CSP-Direktiven konfigurieren
 
-{{Glossary("CSP", "CSP")}} steht für **[Content Security Policy](/de/docs/Web/HTTP/CSP)** und bietet [einen Satz von HTTP-Headern](/de/docs/Web/HTTP/Headers/Content-Security-Policy) (Metadaten, die mit Ihren Webseiten gesendet werden, wenn sie von einem Webserver bereitgestellt werden), die dazu entwickelt sind, die Sicherheit Ihres HTML-Dokuments zu verbessern. Wenn es um die Sicherung von `<iframe>`s geht, können Sie _[Ihren Server so konfigurieren, dass ein entsprechender `X-Frame-Options`-Header gesendet wird.](/de/docs/Web/HTTP/Headers/X-Frame-Options)_ Dies kann verhindern, dass andere Websites Ihre Inhalte in ihre Webseiten einbetten (was {{Glossary("Clickjacking", "Clickjacking")}} und eine Reihe anderer Angriffe ermöglichen würde), was genau das ist, was die MDN-Entwickler getan haben, wie wir vorher gesehen haben.
+{{Glossary("CSP", "CSP")}} steht für **[Content Security Policy (Inhaltssicherheitsrichtlinien)](/de/docs/Web/HTTP/CSP)** und bietet [eine Reihe von HTTP-Headern](/de/docs/Web/HTTP/Headers/Content-Security-Policy) (Metadaten, die zusammen mit Ihren Webseiten bereitgestellt werden, wenn sie von einem Webserver ausgeliefert werden), die darauf ausgelegt sind, die Sicherheit Ihres HTML-Dokuments zu verbessern. Wenn es darum geht, `<iframe>`s abzusichern, können Sie _[Ihren Server so konfigurieren, dass er einen geeigneten `X-Frame-Options`-Header sendet.](/de/docs/Web/HTTP/Headers/X-Frame-Options)_ Dies kann verhindern, dass andere Webseiten Ihre Inhalte in ihre Webseiten einbetten (was [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) und eine Vielzahl anderer Angriffe ermöglichen würde), was genau das ist, was die MDN-Entwickler getan haben, wie wir oben gesehen haben.
 
 > [!NOTE]
-> Sie können Frederik Brauns Beitrag [On the X-Frame-Options Security Header](https://blog.mozilla.org/security/2013/12/12/on-the-x-frame-options-security-header/) für weitere Hintergrundinformationen zu diesem Thema lesen. Offensichtlich ist dies außerhalb des Rahmens für eine vollständige Erklärung in diesem Artikel.
+> Sie können Frederik Brauns Beitrag [On the X-Frame-Options Security Header](https://blog.mozilla.org/security/2013/12/12/on-the-x-frame-options-security-header/) für Hintergrundinformationen zu diesem Thema lesen. Offensichtlich ist es außerhalb des Umfangs für eine vollständige Erklärung in diesem Artikel.
 
 ## Die \<embed> und `<object>` Elemente
 
-Die {{htmlelement("embed")}} und {{htmlelement("object")}} Elemente dienen einem anderen Zweck als {{htmlelement("iframe")}} — diese Elemente sind allgemeine Einbettungswerkzeuge zum Einbetten externer Inhalte, wie PDFs.
+Die {{htmlelement("embed")}} und {{htmlelement("object")}} Elemente dienen einer anderen Funktion als {{htmlelement("iframe")}} — diese Elemente sind allgemeine Einbettungswerkzeuge zum Einbetten externer Inhalte, wie PDFs.
 
-Sie werden diese Elemente jedoch wahrscheinlich nicht sehr oft verwenden. Wenn Sie PDFs anzeigen müssen, ist es in der Regel besser, darauf zu verlinken, anstatt sie in die Seite einzubetten.
+Sie werden diese Elemente jedoch wahrscheinlich nicht sehr häufig verwenden. Wenn Sie PDFs anzeigen müssen, ist es normalerweise besser, sie zu verlinken, anstatt sie auf der Seite einzubetten.
 
-Historisch gesehen wurden diese Elemente auch zum Einbetten von Inhalten genutzt, die von Browser-Plugins gehandhabt werden, wie z.B. {{Glossary("Adobe_Flash", "Adobe Flash")}}, aber diese Technologie ist jetzt veraltet und wird von modernen Browsern nicht mehr unterstützt.
+Historisch wurden diese Elemente auch zum Einbetten von Inhalten verwendet, die von Browser-Plugins wie {{Glossary("Adobe_Flash", "Adobe Flash")}} verarbeitet werden, aber diese Technologie ist inzwischen veraltet und wird von modernen Browsern nicht mehr unterstützt.
 
-Wenn Sie das Einbetten von Plug-in-Inhalten in Erwägung ziehen, sind dies die Informationen, die Sie mindestens benötigen:
+Wenn Sie Inhalte von Plugins einbetten müssen, sind dies die Informationen, die Sie mindestens benötigen:
 
 <table class="standard-table no-markdown">
   <thead>
@@ -317,21 +318,20 @@ Wenn Sie das Einbetten von Plug-in-Inhalten in Erwägung ziehen, sind dies die I
   </thead>
   <tbody>
     <tr>
-      <td>{{Glossary("URL", "URL")}} der eingebetteten Inhalte</td>
+      <td>{{Glossary("URL", "URL")}} des eingebetteten Inhalts</td>
       <td><a href="/de/docs/Web/HTML/Element/embed#src"><code>src</code></a></td>
       <td><a href="/de/docs/Web/HTML/Element/object#data"><code>data</code></a></td>
     </tr>
     <tr>
       <td>
-        <em>Genauer </em>{{Glossary("MIME_type", "Medientyp")}}
-        der eingebetteten Inhalte
+        <em>Genauer</em> {{Glossary("MIME_type", "Medientyp")}} des eingebetteten Inhalts
       </td>
       <td><a href="/de/docs/Web/HTML/Element/embed#type"><code>type</code></a></td>
       <td><a href="/de/docs/Web/HTML/Element/object#type"><code>type</code></a></td>
     </tr>
     <tr>
       <td>
-        Höhe und Breite (in CSS-Pixeln) des von dem Plugin gesteuerten Feldes
+        Höhe und Breite (in CSS-Pixeln) des vom Plugin kontrollierten Rahmens
       </td>
       <td>
          <a href="/de/docs/Web/HTML/Element/embed#height"><code>height</code></a><br /><a href="/de/docs/Web/HTML/Element/embed#width"><code>width</code></a>
@@ -341,17 +341,17 @@ Wenn Sie das Einbetten von Plug-in-Inhalten in Erwägung ziehen, sind dies die I
       </td>
     </tr>
     <tr>
-      <td>Unabhängiger HTML-Inhalt als Rückfalloption für eine nicht verfügbare Ressource</td>
+      <td>Unabhängiger HTML-Inhalt als Fallback für eine nicht verfügbare Ressource</td>
       <td>Nicht unterstützt (<code>&#x3C;noembed></code> ist veraltet)</td>
       <td>
         Innerhalb der öffnenden und schließenden
-        <code>&#x3C;object></code>-Tags enthalten
+        <code>&#x3C;object></code> Tags enthalten
       </td>
     </tr>
   </tbody>
 </table>
 
-Sehen wir uns ein `<object>`-Beispiel an, das ein PDF in eine Seite einbettet (siehe das [Live-Beispiel](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/object-pdf.html) und den [Quellcode](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/object-pdf.html)):
+Sehen wir uns ein `<object>`-Beispiel an, das ein PDF in eine Seite einbettet (sehen Sie das [Live-Beispiel](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/object-pdf.html) und den [Quellcode](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/object-pdf.html)):
 
 ```html
 <object data="my-pdf.pdf" type="application/pdf" width="800" height="1200">
@@ -362,16 +362,16 @@ Sehen wir uns ein `<object>`-Beispiel an, das ein PDF in eine Seite einbettet (s
 </object>
 ```
 
-PDFs waren ein notwendiger Zwischenschritt zwischen Papier und Digital, aber sie stellen viele [Zugänglichkeitsherausforderungen](https://webaim.org/techniques/acrobat/acrobat) dar und können auf kleinen Bildschirmen schwer zu lesen sein. Sie sind in einigen Kreisen immer noch beliebt, aber es ist viel besser, darauf zu verlinken, damit sie heruntergeladen oder auf einer separaten Seite gelesen werden können, anstatt sie in eine Webseite einzubetten.
+PDFs waren ein notwendiger Zwischenschritt zwischen Papier und Digital, aber sie stellen viele [Barrierefreiheitsherausforderungen](https://webaim.org/techniques/acrobat/acrobat) dar und können auf kleinen Bildschirmen schwer zu lesen sein. Sie sind in einigen Kreisen nach wie vor beliebt, aber es ist viel besser, auf sie zu verweisen, damit sie heruntergeladen oder auf einer separaten Seite gelesen werden können, anstatt sie in eine Webseite einzubetten.
 
-## Testen Sie Ihre Fähigkeiten!
+## Testen Sie Ihr Können!
 
-Sie haben das Ende dieses Artikels erreicht, aber können Sie sich die wichtigste Information merken? Sie finden einige weitere Tests, um zu überprüfen, ob Sie sich diese Informationen gemerkt haben, bevor Sie weitermachen — siehe [Testen Sie Ihre Fähigkeiten: Multimedia und Einbettung](/de/docs/Learn/HTML/Multimedia_and_embedding/Video_and_audio_content/Test_your_skills:_Multimedia_and_embedding).
+Sie haben das Ende dieses Artikels erreicht, aber können Sie sich an die wichtigsten Informationen erinnern? Sie können einige zusätzliche Tests finden, um zu überprüfen, dass Sie diese Informationen behalten haben, bevor Sie fortfahren — siehe [Testen Sie Ihr Können: Multimedia und Einbettung](/de/docs/Learn/HTML/Multimedia_and_embedding/Video_and_audio_content/Test_your_skills:_Multimedia_and_embedding).
 
 ## Zusammenfassung
 
-Das Thema des Einbettens anderer Inhalte in Webdokumente kann schnell sehr komplex werden, daher haben wir in diesem Artikel versucht, es auf eine einfache, vertraute Weise einzuführen, die sofort relevant erscheint, während wir dennoch auf einige der fortgeschritteneren Funktionen der beteiligten Technologien hinweisen. Zunächst werden Sie wahrscheinlich nicht viel mehr als Drittanbieter-Inhalte wie Karten und Videos auf Ihren Seiten einbetten. Wenn Sie jedoch erfahrener werden, werden Sie wahrscheinlich weitere Anwendungen dafür finden.
+Das Thema der Einbettung anderer Inhalte in Webdokumente kann schnell sehr komplex werden, weshalb wir in diesem Artikel versucht haben, es auf eine einfache, vertraute Weise einzuführen, die sofort relevant erscheint, während wir immer noch auf einige der weiterentwickelten Funktionen der beteiligten Technologien hinweisen. Zu Beginn werden Sie die Einbettung wahrscheinlich nicht für viel mehr verwenden als das Einfügen von Drittanbieterinhalten wie Karten und Videos auf Ihre Seiten. Mit zunehmender Erfahrung werden Sie jedoch wahrscheinlich weitere Verwendungsmöglichkeiten für sie finden.
 
-Es gibt viele andere Technologien, die das Einbetten externer Inhalte beinhalten, neben denen, die wir hier besprochen haben. Einige haben wir bereits in früheren Artikeln gesehen, wie {{htmlelement("video")}}, {{htmlelement("audio")}} und {{htmlelement("img")}}, aber es gibt noch weitere zu entdecken, wie {{htmlelement("canvas")}} für JavaScript-generierte 2D- und 3D-Grafiken und {{SVGElement("svg")}} für das Einbetten von Vektorgrafiken. Im nächsten Artikel des Moduls schauen wir uns [SVG](/de/docs/Web/SVG) an.
+Es gibt viele andere Technologien, die neben den hier besprochenen das Einbetten externer Inhalte betreffen. Einige davon haben wir in früheren Artikeln gesehen, wie {{htmlelement("video")}}, {{htmlelement("audio")}} und {{htmlelement("img")}}, aber es gibt noch weitere zu entdecken, wie {{htmlelement("canvas")}} für durch JavaScript generierte 2D- und 3D-Grafiken, und {{SVGElement("svg")}} zum Einbetten von Vektorgrafiken. Im nächsten Artikel des Moduls werden wir uns mit [SVG](/de/docs/Web/SVG) befassen.
 
 {{PreviousMenuNext("Learn/HTML/Multimedia_and_embedding/Video_and_audio_content", "Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web", "Learn/HTML/Multimedia_and_embedding")}}
diff --git a/files/de/learn/javascript/asynchronous/implementing_a_promise-based_api/index.md b/files/de/learn/javascript/asynchronous/implementing_a_promise-based_api/index.md
index 98e28943a..3be35f3da 100644
--- a/files/de/learn/javascript/asynchronous/implementing_a_promise-based_api/index.md
+++ b/files/de/learn/javascript/asynchronous/implementing_a_promise-based_api/index.md
@@ -1,38 +1,38 @@
 ---
-title: Anleitung zur Implementierung einer Promise-basierten API
+title: Anleitung zur Implementierung einer auf Promises basierenden API
 slug: Learn/JavaScript/Asynchronous/Implementing_a_promise-based_API
 l10n:
-  sourceCommit: 1b4e6d1156e8471d38deeea1567c35ef412c5f42
+  sourceCommit: e2a558f8e077395153b0e38ccdc6554b33fd87bd
 ---
 
 {{LearnSidebar}}{{PreviousMenuNext("Learn/JavaScript/Asynchronous/Promises", "Learn/JavaScript/Asynchronous/Introducing_workers", "Learn/JavaScript/Asynchronous")}}
 
-Im letzten Artikel haben wir besprochen, wie man APIs verwendet, die Promises zurückgeben. In diesem Artikel betrachten wir die andere Seite — wie man APIs _implementiert_, die Promises zurückgeben. Dies ist eine weitaus weniger häufige Aufgabe als die Nutzung von Promise-basierten APIs, aber es ist dennoch wissenswert.
+Im letzten Artikel haben wir besprochen, wie man APIs verwendet, die Promises zurückgeben. In diesem Artikel betrachten wir die andere Seite – wie man APIs _implementiert_, die Promises zurückgeben. Dies ist eine deutlich seltenere Aufgabe als die Verwendung auf Promises basierender APIs, aber es ist dennoch wissenswert.
 
 <table>
   <tbody>
     <tr>
       <th scope="row">Voraussetzungen:</th>
       <td>
-        Ein fundiertes Verständnis der JavaScript-Grundlagen, einschließlich Ereignisbehandlung und die Grundlagen von Promises.
+        Ein angemessenes Verständnis der grundlegenden JavaScript-Konzepte, einschließlich der Ereignisbehandlung und der Grundlagen von Promises.
       </td>
     </tr>
     <tr>
       <th scope="row">Ziel:</th>
-      <td>Verstehen, wie man Promise-basierte APIs implementiert.</td>
+      <td>Zu verstehen, wie man auf Promises basierende APIs implementiert.</td>
     </tr>
   </tbody>
 </table>
 
-Im Allgemeinen, wenn Sie eine promise-basierte API implementieren, werden Sie einen asynchronen Vorgang umwickeln, der Ereignisse, einfache Rückrufe oder ein Nachrichtenübermittlungsmodell verwenden könnte. Sie werden dafür sorgen, dass ein `Promise`-Objekt den Erfolg oder das Scheitern dieses Vorgangs richtig handhabt.
+Im Allgemeinen wird bei der Implementierung einer auf Promises basierenden API eine asynchrone Operation umschlossen, die Ereignisse, einfache Rückrufmethoden oder ein Nachrichtenaustauschmodell verwenden könnte. Sie organisieren ein `Promise`-Objekt, um den Erfolg oder das Scheitern dieser Operation ordnungsgemäß zu behandeln.
 
 ## Implementierung einer `alarm()` API
 
-In diesem Beispiel implementieren wir eine Promise-basierte Alarm-API, genannt `alarm()`. Diese Funktion nimmt als Argumente den Namen der Person, die geweckt werden soll, und eine Verzögerung in Millisekunden, die gewartet werden soll, bevor die Person geweckt wird. Nach der Verzögerung sendet die Funktion eine "Wake up!"-Nachricht, inklusive des Namens der Person, die geweckt werden muss.
+In diesem Beispiel implementieren wir eine auf Promises basierende Alarm-API, genannt `alarm()`. Sie nimmt als Argumente den Namen der aufzuweckenden Person und eine Verzögerung in Millisekunden, bevor die Person geweckt wird. Nach der Verzögerung sendet die Funktion eine "Aufwachen!"-Nachricht, einschließlich des Namens der Person, die aufgeweckt werden muss.
 
-### Umhüllung von setTimeout()
+### Verwendung von setTimeout()
 
-Wir verwenden die [`setTimeout()`](/de/docs/Web/API/Window/setTimeout) API, um unsere `alarm()`-Funktion zu implementieren. Die `setTimeout()`-API nimmt als Argumente eine Rückruffunktion und eine Verzögerung in Millisekunden entgegen. Wenn `setTimeout()` aufgerufen wird, startet es einen Timer, der auf die angegebene Verzögerung eingestellt ist, und ruft die gegebene Funktion auf, wenn die Zeit abläuft.
+Wir verwenden die [`setTimeout()`](/de/docs/Web/API/Window/setTimeout) API, um unsere `alarm()`-Funktion zu implementieren. Die `setTimeout()` API nimmt als Argumente eine Rückruffunktion und eine Verzögerung in Millisekunden. Wenn `setTimeout()` aufgerufen wird, startet es einen Timer, der auf die angegebene Verzögerung eingestellt ist, und ruft bei Ablauf der Zeit die gegebene Funktion auf.
 
 Im folgenden Beispiel rufen wir `setTimeout()` mit einer Rückruffunktion und einer Verzögerung von 1000 Millisekunden auf:
 
@@ -60,23 +60,23 @@ function setAlarm() {
 button.addEventListener("click", setAlarm);
 ```
 
-{{EmbedLiveSample("Wrapping setTimeout()", 600, 100)}}
+{{EmbedLiveSample("Verwendung von setTimeout()", 600, 100)}}
 
-### Der Promise()-Konstruktor
+### Der Promise() Konstruktor
 
-Unsere `alarm()`-Funktion wird ein `Promise` zurückgeben, das erfüllt wird, wenn der Timer abläuft. Es wird eine "Wake up!"-Nachricht an den `then()`-Handler übergeben und das Promise ablehnen, wenn der Anrufer einen negativen Verzögerungswert übergibt.
+Unsere `alarm()`-Funktion wird ein `Promise` zurückgeben, das erfüllt wird, wenn der Timer abläuft. Es wird eine "Aufwachen!"-Nachricht an den `then()`-Handler übergeben und das Promise ablehnen, wenn der Aufrufer einen negativen Verzögerungswert angibt.
 
-Der Schlüsselkomponente hier ist der {{jsxref("Promise/Promise", "Promise()")}}-Konstruktor. Der `Promise()`-Konstruktor nimmt als Argument eine einzelne Funktion entgegen. Wir nennen diese Funktion den `executor`. Wenn Sie ein neues Promise erstellen, bieten Sie die Implementierung des Executors an.
+Der entscheidende Bestandteil hier ist der {{jsxref("Promise/Promise", "Promise()")}}-Konstruktor. Der `Promise()`-Konstruktor nimmt eine einzelne Funktion als Argument. Wir nennen diese Funktion den `executor`. Wenn Sie ein neues Promise erstellen, liefern Sie die Implementierung des Executors.
 
-Diese Executor-Funktion selbst nimmt zwei Argumente entgegen, die beide auch Funktionen sind und konventionell `resolve` und `reject` genannt werden. In Ihrer Executor-Implementierung rufen Sie die grundlegende asynchrone Funktion auf. Wenn die asynchrone Funktion erfolgreich ist, rufen Sie `resolve` auf, und wenn sie fehlschlägt, rufen Sie `reject` auf. Wenn die Executor-Funktion einen Fehler wirft, wird `reject` automatisch aufgerufen. Sie können einen einzelnen Parameter jeden Typs an `resolve` und `reject` übergeben.
+Diese Executor-Funktion selbst nimmt zwei Argumente, die beide ebenfalls Funktionen sind, und die konventionell `resolve` und `reject` genannt werden. In Ihrer Executor-Implementierung rufen Sie die zugrunde liegende asynchrone Funktion auf. Wenn die asynchrone Funktion erfolgreich ist, rufen Sie `resolve` auf, und wenn sie fehlschlägt, rufen Sie `reject` auf. Wenn die Executor-Funktion einen Fehler auslöst, wird `reject` automatisch aufgerufen. Sie können einen einzelnen Parameter beliebigen Typs in `resolve` und `reject` übergeben.
 
-So können wir `alarm()` wie folgt implementieren:
+So können wir `alarm()` implementieren:
 
 ```js
 function alarm(person, delay) {
   return new Promise((resolve, reject) => {
     if (delay < 0) {
-      throw new Error("Alarm delay must not be negative");
+      reject(new Error("Alarm delay must not be negative"));
     }
     setTimeout(() => {
       resolve(`Wake up, ${person}!`);
@@ -85,15 +85,15 @@ function alarm(person, delay) {
 }
 ```
 
-Diese Funktion erstellt und gibt ein neues `Promise` zurück. Im Executor für das Promise:
+Diese Funktion erstellt und gibt ein neues `Promise` zurück. Innerhalb des Executors für das Promise:
 
-- überprüfen wir, dass `delay` nicht negativ ist, und werfen einen Fehler, wenn es so ist.
+- Überprüfen wir, ob `delay` nicht negativ ist, und rufen `reject` mit einem benutzerdefinierten Fehler auf, wenn dies der Fall ist.
 
-- rufen wir `setTimeout()` auf, übergeben eine Rückruffunktion und `delay`. Die Rückruffunktion wird aufgerufen, wenn der Timer abläuft, und im Rückruf rufen wir `resolve` auf, wobei wir unsere "Wake up!"-Nachricht übergeben.
+- Rufen wir `setTimeout()` auf, übergeben einen Rückruf und `delay`. Der Rückruf wird aufgerufen, wenn der Timer abläuft, und im Rückruf rufen wir `resolve` auf und übergeben unsere `"Aufwachen!"`-Nachricht.
 
-## Verwendung der `alarm()` API
+## Verwendung der alarm() API
 
-Dieser Teil sollte aus dem letzten Artikel ziemlich vertraut sein. Wir können `alarm()` aufrufen und auf dem zurückgegebenen Promise `then()` und `catch()` aufrufen, um Handler für das Erfüllen und Ablehnen des Promises festzulegen.
+Dieser Teil sollte Ihnen aus dem letzten Artikel vertraut sein. Wir können `alarm()` aufrufen und auf dem zurückgegebenen Promise `then()` und `catch()` aufrufen, um Handler für die Erfüllung und Ablehnung des Promises festzulegen.
 
 ```html hidden
 <div>
@@ -130,7 +130,7 @@ const output = document.querySelector("#output");
 function alarm(person, delay) {
   return new Promise((resolve, reject) => {
     if (delay < 0) {
-      throw new Error("Alarm delay must not be negative");
+      reject(new Error("Alarm delay must not be negative"));
     }
     setTimeout(() => {
       resolve(`Wake up, ${person}!`);
@@ -145,13 +145,13 @@ button.addEventListener("click", () => {
 });
 ```
 
-{{EmbedLiveSample("Using the alarm() API", 600, 160)}}
+{{EmbedLiveSample("Verwendung der alarm() API", 600, 160)}}
 
-Versuchen Sie, verschiedene Werte für "Name" und "Delay" einzustellen. Versuchen Sie, einen negativen Wert für "Delay" einzustellen.
+Versuchen Sie, verschiedene Werte für "Name" und "Verzögerung" zu setzen. Versuchen Sie, einen negativen Wert für "Verzögerung" zu setzen.
 
-## Verwendung von async und await mit der `alarm()` API
+## Verwendung von async und await mit der alarm() API
 
-Da `alarm()` ein `Promise` zurückgibt, können wir alles mit ihm machen, was wir mit jedem anderen Promise auch machen könnten: Promise-Ketten, `Promise.all()` und `async` / `await`:
+Da `alarm()` ein `Promise` zurückgibt, können wir alles damit machen, was wir mit jedem anderen Promise tun könnten: Promise-Chaining, `Promise.all()` und `async` / `await`:
 
 ```html hidden
 <div>
@@ -188,7 +188,7 @@ const output = document.querySelector("#output");
 function alarm(person, delay) {
   return new Promise((resolve, reject) => {
     if (delay < 0) {
-      throw new Error("Alarm delay must not be negative");
+      reject(new Error("Alarm delay must not be negative"));
     }
     setTimeout(() => {
       resolve(`Wake up, ${person}!`);
@@ -206,7 +206,7 @@ button.addEventListener("click", async () => {
 });
 ```
 
-{{EmbedLiveSample("Using async and await with the alarm() API", 600, 160)}}
+{{EmbedLiveSample("Verwendung von async und await mit der alarm() API", 600, 160)}}
 
 ## Siehe auch
 
diff --git a/files/de/learn/javascript/first_steps/what_is_javascript/index.md b/files/de/learn/javascript/first_steps/what_is_javascript/index.md
index dec96b2f2..fe57235cb 100644
--- a/files/de/learn/javascript/first_steps/what_is_javascript/index.md
+++ b/files/de/learn/javascript/first_steps/what_is_javascript/index.md
@@ -2,46 +2,46 @@
 title: Was ist JavaScript?
 slug: Learn/JavaScript/First_steps/What_is_JavaScript
 l10n:
-  sourceCommit: 245715b48674c1729cb63417e4a27628e30ae28c
+  sourceCommit: f7e7b73ae9bb1e9230dd543c073d5d2ff083a61b
 ---
 
 {{LearnSidebar}}{{NextMenu("Learn/JavaScript/First_steps/A_first_splash", "Learn/JavaScript/First_steps")}}
 
-Willkommen beim MDN-Einsteigerkurs für JavaScript! In diesem Artikel betrachten wir JavaScript aus einer übergeordneten Perspektive, beantworten Fragen wie „Was ist es?“ und „Was können Sie damit machen?“ und stellen sicher, dass Sie mit dem Zweck von JavaScript vertraut sind.
+Willkommen zum MDN Einsteigerkurs für JavaScript!
+In diesem Artikel betrachten wir JavaScript aus einer hohen Perspektive und beantworten Fragen wie "Was ist es?" und "Was können Sie damit tun?". Zudem stellen wir sicher, dass Sie mit dem Zweck von JavaScript vertraut sind.
 
 <table>
   <tbody>
     <tr>
       <th scope="row">Voraussetzungen:</th>
-      <td>Ein grundlegendes Verständnis von HTML und CSS.</td>
+      <td>Ein Grundverständnis von HTML und CSS.</td>
     </tr>
     <tr>
       <th scope="row">Ziel:</th>
       <td>
-        Vertrautheit mit dem, was JavaScript ist, was es kann und wie es in
-        eine Website passt.
+        Vertrautheit mit dem, was JavaScript ist, was es tun kann und wie es in eine Webseite passt, erlangen.
       </td>
     </tr>
   </tbody>
 </table>
 
-## Eine allgemeine Definition
+## Eine Definition auf hoher Ebene
 
-JavaScript ist eine Skript- oder Programmiersprache, mit der Sie komplexe Funktionen auf Webseiten implementieren können – jedes Mal, wenn eine Webseite mehr tut, als nur da zu sitzen und statische Informationen für Sie anzuzeigen – rechtzeitige Inhaltsaktualisierungen anzuzeigen, interaktive Karten, animierte 2D/3D-Grafiken, scrollende Video-Jukeboxen usw. – können Sie wetten, dass JavaScript wahrscheinlich beteiligt ist. Es ist die dritte Schicht des Schichtkuchens der Standard-Webtechnologien, von denen wir zwei ([HTML](/de/docs/Learn/HTML) und [CSS](/de/docs/Learn/CSS)) in anderen Teilen des Lernbereichs viel ausführlicher behandelt haben.
+JavaScript ist eine Skript- oder Programmiersprache, die es Ihnen ermöglicht, komplexe Funktionen auf Webseiten zu implementieren. Jedes Mal, wenn eine Webseite mehr macht, als nur statische Informationen anzuzeigen — wie zum Beispiel aktuelle Inhalte zu aktualisieren, interaktive Karten, animierte 2D/3D-Grafiken, scrollende Video-Jukeboxen usw. — können Sie sicher sein, dass JavaScript wahrscheinlich daran beteiligt ist. Es ist die dritte Schicht des Schichtkuchens der standardmäßigen Webtechnologien, von denen zwei ([HTML](/de/docs/Learn/HTML) und [CSS](/de/docs/Learn/CSS)) wir ausführlicher in anderen Teilen des Lernbereichs behandelt haben.
 
-![Die drei Schichten der Standard-Webtechnologien; HTML, CSS und JavaScript](cake.png)
+![Die drei Schichten der Standard-Webtechnologien: HTML, CSS und JavaScript](cake.png)
 
-- {{Glossary("HTML", "HTML")}} ist die Auszeichnungssprache, die wir verwenden, um unseren Webinhalten Struktur zu verleihen und ihnen Bedeutung zu geben, beispielsweise Absätze, Überschriften und Datentabellen zu definieren oder Bilder und Videos in die Seite einzubetten.
-- {{Glossary("CSS", "CSS")}} ist eine Sprache mit Stilregeln, mit der wir HTML-Inhalte gestalten, beispielsweise das Festlegen von Hintergrundfarben und Schriftarten sowie das Anordnen unserer Inhalte in mehrere Spalten.
-- {{Glossary("JavaScript", "JavaScript")}} ist eine Skriptsprache, mit der Sie Inhalte dynamisch aktualisieren, Multimedia steuern, Bilder animieren und so ziemlich alles andere tun können. (Nun ja, nicht alles, aber es ist erstaunlich, was Sie mit nur wenigen Zeilen JavaScript-Code erreichen können.)
+- {{Glossary("HTML", "HTML")}} ist die Auszeichnungssprache, die wir verwenden, um unsere Webinhalte zu strukturieren und ihnen Bedeutung zu geben, z.B. indem wir Absätze, Überschriften und Datentabellen definieren oder Bilder und Videos in die Seite einbetten.
+- {{Glossary("CSS", "CSS")}} ist eine Sprache von Stilregeln, die wir verwenden, um Styling auf unsere HTML-Inhalte anzuwenden, z.B. um Hintergrundfarben und Schriftarten festzulegen und unsere Inhalte in mehreren Spalten anzuordnen.
+- {{Glossary("JavaScript", "JavaScript")}} ist eine Skriptsprache, die es Ihnen ermöglicht, dynamisch aktualisierte Inhalte zu erstellen, Multimedia zu steuern, Bilder zu animieren und praktisch alles andere zu tun. (Okay, nicht alles, aber es ist erstaunlich, was Sie mit ein paar Zeilen JavaScript-Code erreichen können.)
 
-Die drei Schichten bauen gut aufeinander auf. Nehmen wir als Beispiel einen Button. Wir können ihn mit HTML markieren, um ihm Struktur und Zweck zu geben:
+Die drei Schichten bauen schön aufeinander auf. Nehmen wir als Beispiel einen Button. Wir können ihn mit HTML markieren, um ihm Struktur und Zweck zu geben:
 
 ```html
 <button type="button">Player 1: Chris</button>
 ```
 
-![Button zeigt Player 1: Chris ohne Styling](just-html.png)
+![Button, der "Player 1: Chris" ohne Styling zeigt](just-html.png)
 
 Dann können wir etwas CSS hinzufügen, um ihn ansprechend aussehen zu lassen:
 
@@ -60,7 +60,7 @@ button {
 }
 ```
 
-![Button zeigt Player 1: Chris mit Styling](html-and-css.png)
+![Button, der "Player 1: Chris" mit Styling zeigt](html-and-css.png)
 
 Und schließlich können wir etwas JavaScript hinzufügen, um dynamisches Verhalten zu implementieren:
 
@@ -77,67 +77,75 @@ function updateName() {
 
 {{ EmbedLiveSample('A_high-level_definition', '100%', 80) }}
 
-Versuchen Sie, auf diese letzte Version der Textmarke zu klicken, um zu sehen, was passiert (beachten Sie auch, dass Sie dieses Demo auf GitHub finden können — sehen Sie sich den [Quellcode](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/javascript-label.html) an oder [führen Sie es live aus](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/javascript-label.html))!
+Versuchen Sie, auf diese letzte Version des Textlabels zu klicken, um zu sehen, was passiert (beachten Sie auch, dass Sie dieses Demo auf GitHub finden können — siehe den [Quellcode](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/javascript-label.html) oder [führen Sie es live aus](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/javascript-label.html))!
 
-JavaScript kann noch viel mehr tun — lassen Sie uns genauer erkunden, was.
+JavaScript kann noch viel mehr — lassen Sie uns dies im Detail erkunden.
 
-## Was kann es wirklich?
+## Was kann es wirklich tun?
 
-Die Kernsprache von JavaScript im Client-Bereich besteht aus einigen allgemeinen Programmierfunktionen, die es Ihnen ermöglichen, Dinge wie:
+Die Kernsprache JavaScript auf der Clientseite besteht aus einigen gängigen Programmierfunktionen, die Sie Dinge tun lassen wie:
 
-- Nützliche Werte in Variablen zu speichern. Im obigen Beispiel beispielsweise fordern wir die Eingabe eines neuen Namens an und speichern dann diesen Namen in einer Variablen namens `name`.
-- Operationen mit Textstücken (in der Programmierung als „Strings“ bekannt) durchzuführen. Im obigen Beispiel nehmen wir den String „Player 1: “ und fügen ihn mit der Variablen `name` zusammen, um das vollständige Textlabel zu erstellen, z. B. „Player 1: Chris“.
-- Code als Reaktion auf bestimmte Ereignisse auf einer Webseite auszuführen. Wir haben in unserem obigen Beispiel ein [`Klick`](/de/docs/Web/API/Element/click_event)-Ereignis verwendet, um zu erkennen, wann das Label angeklickt wird und dann den Code auszuführen, der das Textlabel aktualisiert.
+- Nützliche Werte in Variablen speichern. Im obigen Beispiel bitten wir beispielsweise um die Eingabe eines neuen Namens und speichern diesen Namen in einer Variable namens `name`.
+- Operationen an Textstellen durchführen (bekannt als "Zeichenketten" in der Programmierung). Im obigen Beispiel nehmen wir die Zeichenkette "Player 1: " und fügen sie mit der `name`-Variable zusammen, um das vollständige Textlabel zu erstellen, z.B. "Player 1: Chris".
+- Code ausführen als Reaktion auf bestimmte Ereignisse, die auf einer Webseite auftreten. Wir haben in unserem obigen Beispiel ein [`click`](/de/docs/Web/API/Element/click_event)-Ereignis verwendet, um zu erkennen, wann auf das Label geklickt wird, und dann den Code auszuführen, der das Textlabel aktualisiert.
 - Und vieles mehr!
 
-Noch aufregender sind jedoch die Funktionen, die auf der clientseitigen JavaScript-Sprache aufbauen. Die sogenannten **Application Programming Interfaces** (**APIs**) bieten Ihnen zusätzliche Superkräfte, die Sie in Ihrem JavaScript-Code verwenden können.
+Noch aufregender ist jedoch die Funktionalität, die auf der clientseitigen JavaScript-Sprache aufbaut. So genannte **Application Programming Interfaces** (**APIs**) bieten Ihnen zusätzliche Superkräfte zur Verwendung in Ihrem JavaScript-Code.
 
-APIs sind fertige Sets von Codebausteinen, die es einem Entwickler ermöglichen, Programme zu implementieren, die ansonsten schwer oder unmöglich zu implementieren wären. Sie tun das Gleiche für die Programmierung, wie es Möbelbaukästen für das Wohnungsbau tun — es ist viel einfacher, bereits zugeschnittene Platten zu nehmen und zusammenzuschrauben, um ein Bücherregal zu machen, als selbst das Design auszuarbeiten, das richtige Holz zu finden, alle Platten in die richtige Größe und Form zu schneiden, die Schrauben in der richtigen Größe zu finden und _dann_ zusammenzuschrauben, um ein Bücherregal zu machen.
+APIs sind fertige Sätze von Codebausteinen, die es einem Entwickler ermöglichen, Programme zu implementieren, die ansonsten schwer oder unmöglich zu implementieren wären.
+Sie tun dasselbe für die Programmierung wie fertige Möbelbausätze für den Hausbau – es ist viel einfacher, vorgefertigte Platten zu nehmen und zusammenzuschrauben, um ein Bücherregal zu bauen, als das Design selbst zu erarbeiten, das richtige Holz zu finden, alle Platten auf die richtige Größe und Form zuzuschneiden, die Schrauben in der richtigen Größe zu finden und _dann_ sie zusammenzusetzen, um ein Bücherregal zu bauen.
 
-Sie fallen im Allgemeinen in zwei Kategorien.
+Im Allgemeinen fallen sie in zwei Kategorien.
 
-![Zwei Kategorien von API; Drittanbieter-APIs werden neben dem Browser gezeigt und Browser-APIs sind im Browser](browser.png)
+![Zwei Kategorien von API; 3rd-Party-APIs werden neben dem Browser und Browser-APIs im Browser angezeigt](browser.png)
 
-**Browser-APIs** sind in Ihrem Webbrowser integriert und können Daten aus der umgebenden Computerumgebung bereitstellen oder nützliche komplexe Dinge tun. Beispielsweise:
+**Browser-APIs** sind in Ihrem Webbrowser eingebaut und können Daten aus der umgebenden Computerumgebung preisgeben oder nützliche komplexe Dinge tun. Zum Beispiel:
 
-- Die [DOM (Document Object Model) API](/de/docs/Web/API/Document_Object_Model) erlaubt es Ihnen, HTML und CSS zu manipulieren, HTML zu erstellen, zu entfernen und zu ändern, neue Stile dynamisch auf Ihre Seite anzuwenden usw. Jedes Mal, wenn ein Popup-Fenster auf einer Seite erscheint oder neuer Inhalt angezeigt wird (wie wir es oben in unserem einfachen Demo gesehen haben), ist das das DOM in Aktion.
-- Die [Geolocation API](/de/docs/Web/API/Geolocation_API) ruft geografische Informationen ab. So kann [Google Maps](https://www.google.com/maps) Ihren Standort finden und auf einer Karte anzeigen.
-- Die [Canvas](/de/docs/Web/API/Canvas_API) und [WebGL](/de/docs/Web/API/WebGL_API) APIs ermöglichen es Ihnen, animierte 2D- und 3D-Grafiken zu erstellen. Mit diesen Webtechnologien machen Leute erstaunliche Dinge — siehe [Chrome Experiments](https://experiments.withgoogle.com/collection/chrome) und [webglsamples](https://webglsamples.org/).
-- [Audio und Video APIs](/de/docs/Web/Media/Audio_and_video_delivery) wie [`HTMLMediaElement`](/de/docs/Web/API/HTMLMediaElement) und [WebRTC](/de/docs/Web/API/WebRTC_API) ermöglichen es Ihnen, wirklich interessante Dinge mit Multimedia zu tun, wie z.B. Audio und Video direkt auf einer Webseite abzuspielen oder Video von Ihrer Webcam aufzunehmen und auf einem anderen Computer anzuzeigen (probieren Sie unser einfaches [Snapshot-Demo](https://chrisdavidmills.github.io/snapshot/) aus, um die Idee zu bekommen).
+- Mit der [DOM (Document Object Model) API](/de/docs/Web/API/Document_Object_Model) können Sie HTML und CSS manipulieren, HTML erstellen, entfernen und ändern und neue Stile dynamisch auf Ihre Seite anwenden.
+  Jedes Mal, wenn Sie ein Popup-Fenster auf einer Seite erscheinen sehen oder neue Inhalte angezeigt werden (wie wir es oben in unserem einfachen Demo gesehen haben), ist das das DOM in Aktion.
+- Mit der [Geolocation API](/de/docs/Web/API/Geolocation_API) werden geografische Informationen abgerufen.
+  Dies ist der Grund, warum [Google Maps](https://www.google.com/maps) Ihren Standort finden und auf einer Karte anzeigen kann.
+- Die [Canvas](/de/docs/Web/API/Canvas_API) und [WebGL](/de/docs/Web/API/WebGL_API) APIs ermöglichen es Ihnen, animierte 2D- und 3D-Grafiken zu erstellen.
+  Menschen tun erstaunliche Dinge mit diesen Webtechnologien — siehe [Chrome Experiments](https://experiments.withgoogle.com/collection/chrome) und [webglsamples](https://webglsamples.org/).
+- [Audio- und Video-APIs](/de/docs/Web/Media/Audio_and_video_delivery) wie [`HTMLMediaElement`](/de/docs/Web/API/HTMLMediaElement) und [WebRTC](/de/docs/Web/API/WebRTC_API) ermöglichen Ihnen wirklich interessante Dinge mit Multimedia, wie z.B. Audio und Video direkt auf einer Webseite abzuspielen, oder Video von Ihrer Webcam zu erfassen und es auf dem Computer einer anderen Person anzuzeigen (versuchen Sie unser einfaches [Snapshot-Demo](https://chrisdavidmills.github.io/snapshot/), um eine Vorstellung zu bekommen).
 
 > [!NOTE]
-> Viele der oben genannten Demos funktionieren in einem älteren Browser nicht — beim Experimentieren ist es eine gute Idee, einen modernen Browser wie Firefox, Chrome, Edge oder Opera zu verwenden, um Ihren Code auszuführen. Sie müssen das Thema [Cross-Browser-Testing](/de/docs/Learn/Tools_and_testing/Cross_browser_testing) genauer betrachten, wenn Sie der Produktion von Code (d.h. echtem Code, den echte Kunden verwenden werden) näher kommen.
+> Viele der oben genannten Demos funktionieren in einem älteren Browser nicht – beim Experimentieren ist es eine gute Idee, einen modernen Browser wie Firefox, Chrome, Edge oder Opera zu verwenden, um Ihren Code auszuführen.
+> Sie müssen das [Cross-Browser-Testing](/de/docs/Learn/Tools_and_testing/Cross_browser_testing) genauer betrachten, wenn Sie sich der Bereitstellung von Produktionscode nähern (d.h. echter Code, den echte Kunden verwenden werden).
 
-**Drittanbieter-APIs** sind nicht standardmäßig im Browser integriert und Sie müssen ihren Code und Informationen in der Regel von irgendwo im Web abrufen. Beispielsweise:
+**Drittanbieter-APIs** sind nicht standardmäßig im Browser integriert, und Sie müssen deren Code und Informationen in der Regel von irgendwo im Web abrufen. Zum Beispiel:
 
-- Die [Twitter API](https://developer.twitter.com/en/docs) ermöglicht es Ihnen, Dinge wie Ihre neuesten Tweets auf Ihrer Website anzuzeigen.
-- Die [Google Maps API](https://developers.google.com/maps/) und [OpenStreetMap API](https://wiki.openstreetmap.org/wiki/API) ermöglichen es Ihnen, benutzerdefinierte Karten in Ihre Website einzubetten und andere ähnliche Funktionen bereitzustellen.
+- Die [Twitter API](https://developer.x.com/en/docs) ermöglicht Ihnen Dinge wie, Ihre neuesten Tweets auf Ihrer Website anzuzeigen.
+- Die [Google Maps API](https://developers.google.com/maps/) und [OpenStreetMap API](https://wiki.openstreetmap.org/wiki/API) ermöglichen es Ihnen, benutzerdefinierte Karten in Ihre Website einzubetten und ähnliche Funktionalitäten.
 
 > [!NOTE]
-> Diese APIs sind fortgeschritten und wir werden in diesem Modul keine dieser APIs behandeln. Weitere Informationen zu diesen APIs finden Sie in unserem [Clientseitige Web-APIs-Modul](/de/docs/Learn/JavaScript/Client-side_web_APIs).
+> Diese APIs sind fortgeschritten und wir werden keine dieser in diesem Modul behandeln. Sie können viel mehr darüber in unserem Modul zu [Client-seitigen Web-APIs](/de/docs/Learn/JavaScript/Client-side_web_APIs) erfahren.
 
-Es gibt noch viel mehr, aber lassen Sie sich noch nicht zu sehr begeistern. Sie werden nicht in der Lage sein, das nächste Facebook, Google Maps oder Instagram zu bauen, nachdem Sie 24 Stunden JavaScript studiert haben – es gibt viele Grundlagen, die Sie zuerst abdecken müssen. Und deshalb sind Sie hier – lassen Sie uns weitermachen!
+Es gibt noch viel mehr, was verfügbar ist! Aber lassen Sie sich jetzt nicht zu sehr begeistern. Sie werden nicht in der Lage sein, das nächste Facebook, Google Maps oder Instagram zu erstellen, nachdem Sie JavaScript 24 Stunden lang studiert haben — es gibt viele Grundlagen zu behandeln. Und genau deshalb sind Sie hier — gehen wir weiter!
 
 ## Was macht JavaScript auf Ihrer Seite?
 
-Hier werden wir tatsächlich etwas Code betrachten und dabei erkunden, was tatsächlich passiert, wenn Sie JavaScript auf Ihrer Seite ausführen.
+Hier werden wir tatsächlich anfangen, uns etwas Code anzusehen und dabei erkunden, was tatsächlich passiert, wenn Sie JavaScript auf Ihrer Seite ausführen.
 
-Lassen Sie uns kurz die Geschichte wiederholen, was passiert, wenn Sie eine Webseite in einem Browser laden (zuerst erwähnt in unserem Artikel [Wie funktioniert CSS?](/de/docs/Learn/CSS/First_steps/How_CSS_works#how_does_css_actually_work)). Wenn Sie eine Webseite in Ihrem Browser laden, führen Sie Ihren Code (HTML, CSS und JavaScript) in einer Ausführungsumgebung (im Browser-Tab) aus. Das ist wie eine Fabrik, die Rohstoffe (den Code) aufnimmt und ein Produkt (die Webseite) ausgibt.
+Lassen Sie uns kurz wiederholen, was passiert, wenn Sie eine Webseite in einem Browser laden (zuerst besprochen in unserem Artikel [Wie funktioniert CSS](/de/docs/Learn/CSS/First_steps/How_CSS_works#how_does_css_actually_work)). Wenn Sie eine Webseite in Ihrem Browser laden, führen Sie Ihren Code (das HTML, CSS und JavaScript) in einer Ausführungsumgebung aus (dem Browser-Tab). Das ist wie eine Fabrik, die Rohstoffe (den Code) aufnimmt und ein Produkt (die Webseite) ausgibt.
 
-![HTML-, CSS- und JavaScript-Code kommen zusammen, um den Inhalt im Browser-Tab zu erstellen, wenn die Seite geladen wird](execution.png)
+![HTML-, CSS- und JavaScript-Code werden beim Laden der Seite zusammengeführt, um den Inhalt im Browser-Tab zu erstellen](execution.png)
 
-Eine sehr häufige Verwendung von JavaScript ist die dynamische Änderung von HTML und CSS, um die Benutzeroberfläche über die Document Object Model API zu aktualisieren (wie oben erwähnt).
+Eine sehr häufige Verwendung von JavaScript besteht darin, HTML und CSS dynamisch zu modifizieren, um eine Benutzeroberfläche über die Document Object Model API (wie oben erwähnt) zu aktualisieren.
 
-### Browsersicherheit
+### Browser-Sicherheit
 
-Jeder Browser-Tab hat seinen eigenen separaten Eimer zur Ausführung von Code (diese Eimer werden technisch als "Ausführungsumgebungen" bezeichnet) – das bedeutet, dass in den meisten Fällen der Code in jedem Tab vollständig separat ausgeführt wird und der Code in einem Tab den Code in einem anderen Tab oder auf einer anderen Website nicht direkt beeinflussen kann. Dies ist eine gute Sicherheitsmaßnahme – wenn dies nicht der Fall wäre, könnten Piraten anfangen, Code zu schreiben, um Informationen von anderen Websites zu stehlen, und andere solche schlechten Dinge.
+Jeder Browser-Tab hat seinen eigenen separaten Container zur Ausführung von Code (diese Container werden in technischen Begriffen als "Ausführungsumgebungen" bezeichnet) — das bedeutet, dass in den meisten Fällen der Code in jedem Tab vollständig getrennt ausgeführt wird und der Code in einem Tab den Code in einem anderen Tab oder auf einer anderen Website nicht direkt beeinflussen kann.
+Dies ist eine gute Sicherheitsmaßnahme — wenn dies nicht der Fall wäre, könnten Bösewichte anfangen, Code zu schreiben, um Informationen von anderen Websites zu stehlen und andere solche schlechten Dinge zu tun.
 
 > [!NOTE]
-> Es gibt Möglichkeiten, Code und Daten zwischen verschiedenen Websites/Tabs auf sichere Weise zu senden, aber dies sind fortgeschrittene Techniken, die wir in diesem Kurs nicht behandeln werden.
+> Es gibt Möglichkeiten, um Code und Daten sicher zwischen verschiedenen Websites/Tabs zu senden, aber diese sind fortgeschrittene Techniken, die wir in diesem Kurs nicht behandeln werden.
 
 ### JavaScript-Ausführungsreihenfolge
 
-Wenn der Browser einen Block von JavaScript sieht, führt er ihn im Allgemeinen der Reihe nach aus, von oben nach unten. Das bedeutet, dass Sie darauf achten müssen, in welcher Reihenfolge Sie Dinge platzieren. Zum Beispiel, lassen Sie uns zum Block von JavaScript aus unserem ersten Beispiel zurückkehren:
+Wenn der Browser auf einen JavaScript-Block trifft, wird dieser im Allgemeinen in der Reihenfolge von oben nach unten ausgeführt.
+Das bedeutet, dass Sie darauf achten müssen, in welcher Reihenfolge Sie Dinge anordnen.
+Zum Beispiel, lassen Sie uns zum JavaScript-Block aus unserem ersten Beispiel zurückkehren:
 
 ```js
 const button = document.querySelector("button");
@@ -150,44 +158,60 @@ function updateName() {
 }
 ```
 
-Hier wählen wir zuerst einen Button mit `document.querySelector` aus und hängen dann einen Ereignislistener daran an, damit beim Klicken des Buttons der `updateName()`-Codeblock (Zeilen 5–8) ausgeführt wird. Der Codeblock `updateName()` (diese Arten von wiederverwendbaren Codeblöcken werden „Funktionen“ genannt) fordert den Benutzer auf, einen neuen Namen einzugeben und fügt diesen Namen dann in den Buttontext ein, um die Anzeige zu aktualisieren.
+Hier wählen wir zuerst einen Button mit `document.querySelector` aus und fügen dann einen Ereignislistener mit `addEventListener` hinzu, sodass beim Klicken auf den Button der `updateName()`-Codeblock (Zeilen 5–8) ausgeführt wird. Der `updateName()`-Codeblock (diese Arten von wiederverwendbaren Codeblöcken werden als "Funktionen" bezeichnet) fragt den Benutzer nach einem neuen Namen und fügt dann diesen Namen in den Button-Text ein, um die Anzeige zu aktualisieren.
 
-Wenn Sie die Reihenfolge der ersten beiden Codezeilen vertauschen würden, würde es nicht mehr funktionieren — stattdessen würden Sie einen Fehler in der [Browser-Entwicklungskonsole](/de/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools) erhalten — `Uncaught ReferenceError: Cannot access 'button' before initialization`. Das bedeutet, dass das `button`-Objekt noch nicht initialisiert wurde, also können wir keinen Ereignislistener daran anhängen.
+Wenn Sie die Reihenfolge der ersten beiden Codezeilen vertauschen würden, würde es nicht mehr funktionieren — stattdessen würden Sie im [Browser-Entwicklerkonsole](/de/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools) einen Fehler wie `Uncaught ReferenceError: Cannot access 'button' before initialization` sehen.
+Das bedeutet, dass das `button`-Objekt noch nicht initialisiert wurde, weshalb wir keinen Ereignislistener darauf hinzufügen können.
 
 > [!NOTE]
-> Dies ist ein sehr häufiger Fehler — Sie müssen darauf achten, dass die in Ihrem Code referenzierten Objekte existieren, bevor Sie versuchen, etwas mit ihnen zu machen.
+> Dies ist ein sehr häufiger Fehler — Sie müssen sicherstellen, dass die in Ihrem Code referenzierten Objekte existieren, bevor Sie mit ihnen arbeiten.
 
-### Interpretierter vs. kompiliertem Code
+### Interpretierter versus kompilierter Code
 
-Sie könnten die Begriffe **interpretiert** und **kompiliert** im Kontext der Programmierung hören. Bei interpretierten Sprachen wird der Code von oben nach unten ausgeführt und das Ergebnis der Ausführung des Codes sofort zurückgegeben. Sie müssen den Code nicht in eine andere Form umwandeln, bevor der Browser ihn ausführt. Der Code wird in seiner programmgerechten Textform empfangen und direkt davon verarbeitet.
+Sie könnten die Begriffe **interpretiert** und **kompiliert** im Kontext der Programmierung hören.
+In interpretierten Sprachen wird der Code von oben nach unten ausgeführt und das Ergebnis der Codeausführung wird sofort zurückgegeben.
+Sie müssen den Code nicht in eine andere Form transformieren, bevor der Browser ihn ausführt.
+Der Code wird in seiner benutzerfreundlichen Textform empfangen und direkt daraus verarbeitet.
 
-Kompilierte Sprachen hingegen werden vor ihrer Ausführung durch den Computer in eine andere Form umgewandelt (kompiliert). Beispielsweise werden C/C++ in Maschinencode kompiliert, der dann vom Computer ausgeführt wird. Das Programm wird in einem binären Format ausgeführt, das aus dem ursprünglichen Quellcode des Programms generiert wurde.
+Kompilierte Sprachen hingegen werden (kompiliert) in eine andere Form umgewandelt, bevor sie vom Computer ausgeführt werden.
+Beispielsweise werden C/C++ in Maschinencode kompiliert, der dann vom Computer ausgeführt wird.
+Das Programm wird aus einem binären Format ausgeführt, das aus dem ursprünglichen Programmquellcode generiert wurde.
 
-JavaScript ist eine leichtgewichtige interpretierte Programmiersprache. Der Webbrowser empfängt den JavaScript-Code in seiner ursprünglichen Textform und führt das Skript von dort aus. Technisch gesehen verwenden die meisten modernen JavaScript-Interpreter tatsächlich eine Technik namens **Just-in-Time-Compiling**, um die Leistung zu verbessern; der JavaScript-Quellcode wird während der Verwendung des Skripts in ein schnelleres, binäres Format kompiliert, damit er so schnell wie möglich ausgeführt werden kann. JavaScript wird jedoch immer noch als interpretierte Sprache betrachtet, da die Kompilierung zur Laufzeit und nicht vor der Zeit erfolgt.
+JavaScript ist eine leichtgewichtige interpretierte Programmiersprache.
+Der Webbrowser empfängt den JavaScript-Code in seiner ursprünglichen Textform und führt das Skript daraus aus.
+Aus technischer Sicht verwenden die meisten modernen JavaScript-Interpreter tatsächlich eine Technik namens **Just-in-time-Compiling**, um die Leistung zu verbessern; der JavaScript-Quellcode wird während der Ausführung des Skripts in ein schnelleres, binäres Format kompiliert, sodass er so schnell wie möglich ausgeführt werden kann.
+JavaScript wird jedoch immer noch als interpretierte Sprache angesehen, da die Kompilierung zur Laufzeit und nicht im Voraus gehandhabt wird.
 
-Beide Sprachtypen haben ihre Vorteile, aber wir werden sie jetzt nicht diskutieren.
+Es gibt Vorteile bei beiden Arten von Sprachen, aber wir werden sie jetzt nicht diskutieren.
 
-### Server-seitiger vs. client-seitiger Code
+### Server-seitiger versus Client-seitiger Code
 
-Sie könnten auch die Begriffe **serverseitig** und **clientseitig** hören, besonders im Kontext der Webentwicklung. Clientseitiger Code ist Code, der auf dem Computer des Benutzers ausgeführt wird — wenn eine Webseite angezeigt wird, wird der clientseitige Code der Seite heruntergeladen, dann ausgeführt und vom Browser angezeigt. In diesem Modul sprechen wir explizit über **clientseitiges JavaScript**.
+Sie könnten auch die Begriffe **server-seitiger** und **client-seitiger** Code hören, besonders im Zusammenhang mit Webentwicklung.
+Client-seitiger Code ist Code, der auf dem Computer des Benutzers ausgeführt wird — wenn eine Webseite angezeigt wird, wird der client-seitige Code der Seite heruntergeladen, dann von dem Browser ausgeführt und angezeigt.
+In diesem Modul sprechen wir ausdrücklich über **client-seitiges JavaScript**.
 
-Serverseitiger Code hingegen wird auf dem Server ausgeführt, dann werden seine Ergebnisse heruntergeladen und im Browser angezeigt. Beispiele für beliebte serverseitige Websprachen sind PHP, Python, Ruby, ASP.NET und sogar JavaScript! JavaScript kann auch als serverseitige Sprache verwendet werden, zum Beispiel in der populären Node.js-Umgebung — Sie können mehr über serverseitiges JavaScript in unserem Thema [Dynamische Websites – Serversseitige Programmierung](/de/docs/Learn/Server-side) herausfinden.
+Server-seitiger Code hingegen wird auf dem Server ausgeführt, und seine Ergebnisse werden heruntergeladen und im Browser angezeigt.
+Beispiele für beliebte server-seitige Websprachen sind PHP, Python, Ruby, C# und sogar JavaScript!
+JavaScript kann auch als server-seitige Sprache verwendet werden, zum Beispiel in der beliebten Node.js-Umgebung — Sie können mehr über server-seitiges JavaScript in unserem Thema [Dynamische Websites – Server-seitige Programmierung](/de/docs/Learn/Server-side) erfahren.
 
-### Dynamischer vs. statischer Code
+### Dynamischer versus statischer Code
 
-Das Wort **dynamisch** wird sowohl verwendet, um clientseitiges JavaScript als auch serverseitige Sprachen zu beschreiben — es bezieht sich auf die Fähigkeit, die Anzeige einer Webseite/App zu aktualisieren, um in verschiedenen Umständen unterschiedliche Dinge zu zeigen und neuen Inhalt nach Bedarf zu generieren. Serverseitiger Code generiert dynamisch neuen Inhalt auf dem Server, zum Beispiel durch das Abrufen von Daten aus einer Datenbank, während clientseitiges JavaScript dynamisch neuen Inhalt im Browser auf dem Client generiert, zum Beispiel durch das Erstellen einer neuen HTML-Tabelle, das Füllen dieser mit vom Server angeforderten Daten und das Anzeigen der Tabelle auf einer dem Benutzer gezeigten Webseite. Die Bedeutung ist in den beiden Kontexten leicht unterschiedlich, aber verwandt, und beide Ansätze (serverseitig und clientseitig) arbeiten in der Regel zusammen.
+Das Wort **dynamisch** wird verwendet, um sowohl client-seitiges JavaScript als auch server-seitige Sprachen zu beschreiben — es bezieht sich auf die Fähigkeit, die Anzeige einer Webseite/App zu aktualisieren, um verschiedene Dinge in unterschiedlichen Umständen anzuzeigen und bei Bedarf neue Inhalte zu generieren.
+Server-seitiger Code generiert dynamisch neue Inhalte auf dem Server, z.B. beim Abrufen von Daten aus einer Datenbank, während client-seitiges JavaScript dynamisch neue Inhalte im Browser auf dem Client generiert, z.B. indem eine neue HTML-Tabelle erstellt, gefüllt mit vom Server angeforderten Daten und dann die Tabelle in einer dem Benutzer angezeigten Webseite angezeigt wird.
+Die Bedeutung ist in beiden Kontexten leicht unterschiedlich, aber verwandt, und beide Ansätze (serverseitig und clientseitig) arbeiten normalerweise zusammen.
 
-Eine Webseite ohne dynamisch aktualisierten Inhalt wird als **statisch** bezeichnet — sie zeigt die ganze Zeit denselben Inhalt.
+Eine Webseite ohne dynamisch aktualisierende Inhalte wird als **statisch** bezeichnet — sie zeigt immer denselben Inhalt.
 
-## Wie fügen Sie Ihrer Seite JavaScript hinzu?
+## Wie fügen Sie JavaScript auf Ihrer Seite hinzu?
 
-JavaScript wird Ihrer HTML-Seite auf ähnliche Weise wie CSS hinzugefügt. Während CSS {{htmlelement("link")}}-Elemente verwendet, um externe Stylesheets anzuwenden, und {{htmlelement("style")}}-Elemente, um interne Stylesheets auf HTML anzuwenden, benötigt JavaScript nur einen Freund in der Welt von HTML — das {{htmlelement("script")}}-Element. Lassen Sie uns lernen, wie das funktioniert.
+JavaScript wird Ihrer HTML-Seite in ähnlicher Weise wie CSS hinzugefügt.
+Während CSS {{htmlelement("link")}}-Elemente verwendet, um externe Stylesheets und {{htmlelement("style")}}-Elemente zu verwenden, um interne Stylesheets auf HTML anzuwenden, benötigt JavaScript nur einen Freund in der Welt des HTML — das {{htmlelement("script")}}-Element. Lassen Sie uns lernen, wie das funktioniert.
 
 ### Internes JavaScript
 
-1. Machen Sie zunächst eine lokale Kopie unserer Beispieldatei [apply-javascript.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript.html). Speichern Sie sie in einem sinnvollen Verzeichnis.
-2. Öffnen Sie die Datei in Ihrem Webbrowser und in Ihrem Texteditor. Sie werden sehen, dass das HTML eine einfache Webseite erstellt, die einen klickbaren Button enthält.
-3. Gehen Sie als Nächstes zu Ihrem Texteditor und fügen Sie am Ende Ihres Body — direkt vor Ihrem schließenden `</body>`-Tag — Folgendes hinzu:
+1. Zuerst erstellen Sie eine lokale Kopie unserer Beispieldatei [apply-javascript.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript.html). Speichern Sie sie in einem vernünftigen Verzeichnis.
+2. Öffnen Sie die Datei in Ihrem Webbrowser und in Ihrem Texteditor. Sie werden sehen, dass das HTML eine einfache Webseite mit einem klickbaren Button erstellt.
+3. Gehen Sie dann zu Ihrem Texteditor und fügen Sie Folgendes am unteren Ende Ihres Body-Bereichs hinzu — direkt vor Ihrem schließenden `</body>`-Tag:
 
    ```html
    <script>
@@ -195,9 +219,9 @@ JavaScript wird Ihrer HTML-Seite auf ähnliche Weise wie CSS hinzugefügt. Währ
    </script>
    ```
 
-   Beachten Sie, dass der Code in Ihren Webdokumenten in der Reihenfolge geladen und ausgeführt wird, in der er auf der Seite erscheint. Indem wir das JavaScript am Ende platzieren, stellen wir sicher, dass alle HTML-Elemente geladen sind. (Siehe auch [Strategien zum Laden von Skripten](#strategien_zum_laden_von_skripten) unten.)
+   Beachten Sie, dass der Code in Ihren Webdokumenten im Allgemeinen in der Reihenfolge geladen und ausgeführt wird, in der er auf der Seite erscheint. Durch das Platzieren des JavaScripts am unteren Ende, stellen wir sicher, dass alle HTML-Elemente geladen werden. (Siehe auch [Script-Ladestrategien](#script-ladestrategien) unten.)
 
-4. Jetzt fügen wir unser {{htmlelement("script")}}-Element hinzu, um die Seite interessanter zu gestalten — fügen Sie den folgenden Code direkt unter der Linie "// JavaScript goes here" hinzu:
+4. Jetzt fügen wir etwas JavaScript in unser {{htmlelement("script")}}-Element ein, um die Seite etwas interessanter zu machen — fügen Sie den folgenden Code direkt unter der Linie "// JavaScript goes here" ein:
 
    ```js
    function createParagraph() {
@@ -213,26 +237,29 @@ JavaScript wird Ihrer HTML-Seite auf ähnliche Weise wie CSS hinzugefügt. Währ
    }
    ```
 
-5. Speichern Sie Ihre Datei und aktualisieren Sie den Browser — jetzt sollten Sie sehen, dass jedes Mal, wenn Sie den Button klicken, ein neuer Paragraph generiert und unten platziert wird.
+5. Speichern Sie Ihre Datei und aktualisieren Sie den Browser — jetzt sollten Sie sehen, dass beim Klicken auf den Button ein neuer Absatz erzeugt und unten platziert wird.
 
 > [!NOTE]
-> Wenn Ihr Beispiel nicht zu funktionieren scheint, gehen Sie die Schritte noch einmal durch und überprüfen Sie, ob Sie alles richtig gemacht haben. Haben Sie Ihre lokale Kopie des Anfangscodes als `.html`-Datei gespeichert? Haben Sie Ihr {{htmlelement("script")}}-Element direkt before dem `</body>`-Tag hinzugefügt? Haben Sie das JavaScript genauso eingegeben, wie angezeigt? **JavaScript ist besonders auf Groß- und Kleinschreibung und Syntax empfindlich und muss genau so eingegeben werden, wie gezeigt, sonst funktioniert es möglicherweise nicht.**
+> Wenn Ihr Beispiel nicht zu funktionieren scheint, gehen Sie die Schritte erneut durch und überprüfen Sie, ob Sie alles richtig gemacht haben.
+> Haben Sie Ihre lokale Kopie des Startcodes als `.html`-Datei gespeichert?
+> Haben Sie Ihr {{htmlelement("script")}}-Element direkt vor dem `</body>`-Tag eingefügt?
+> Haben Sie das JavaScript genau eingegeben wie gezeigt? **JavaScript ist fallempfindlich und sehr heikel, daher müssen Sie die Syntax genau wie angegeben eingeben, ansonsten kann es möglicherweise nicht funktionieren.**
 
 > [!NOTE]
-> Sie können diese Version auf GitHub als [apply-javascript-internal.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript-internal.html) ansehen ([sehen Sie es auch live](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/apply-javascript-internal.html)).
+> Sie können diese Version auf GitHub als [apply-javascript-internal.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript-internal.html) ([sehen Sie sich sie auch live an](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/apply-javascript-internal.html)).
 
 ### Externes JavaScript
 
-Das funktioniert großartig, aber was, wenn wir unser JavaScript in einer externen Datei speichern möchten? Lassen Sie uns das jetzt erkunden.
+Das funktioniert großartig, aber was, wenn wir unser JavaScript in eine externe Datei legen möchten? Lassen Sie uns dies jetzt erkunden.
 
-1. Erstellen Sie zuerst eine neue Datei im gleichen Verzeichnis wie Ihre HTML-Beispieldatei. Nennen Sie sie `script.js` — achten Sie darauf, dass sie diese .js-Dateiendung hat, da das als JavaScript erkannt wird.
-2. Entfernen Sie Ihr aktuelles {{htmlelement("script")}}-Element am unteren Ende des `</body>` und fügen Sie das folgende direkt vor dem schließenden `</head>`-Tag hinzu (auf diese Weise kann der Browser die Datei früher laden als wenn sie am Boden ist):
+1. Erstellen Sie zuerst eine neue Datei im gleichen Verzeichnis wie Ihre Beispiel-HTML-Datei. Nennen Sie sie `script.js` — achten Sie darauf, dass sie diese .js-Dateierweiterung hat, da sie so als JavaScript erkannt wird.
+2. Entfernen Sie Ihr aktuelles {{htmlelement("script")}}-Element am unteren Ende des `</body>` und fügen Sie das folgende direkt vor dem schließenden `</head>`-Tag ein (auf diese Weise kann der Browser die Datei früher laden, als wenn es am Ende ist):
 
    ```html
    <script type="module" src="script.js"></script>
    ```
 
-3. Fügen Sie in `script.js` das folgende Skript hinzu:
+3. Fügen Sie innerhalb von `script.js` das folgende Skript ein:
 
    ```js
    function createParagraph() {
@@ -248,17 +275,20 @@ Das funktioniert großartig, aber was, wenn wir unser JavaScript in einer extern
    }
    ```
 
-4. Speichern und aktualisieren Sie Ihren Browser. Sie werden feststellen, dass das Klicken auf den Button keine Wirkung hat, und wenn Sie die Konsole Ihres Browsers überprüfen, wird ein Fehler angezeigt, wie z.B. `Cross-origin request blocked`. Das liegt daran, dass wie viele externe Ressourcen, JavaScript-Module aus dem [gleichen Ursprung](/de/docs/Web/Security/Same-origin_policy) wie das HTML geladen werden müssen und `file://`-URLs nicht qualifiziert sind. Es gibt zwei Lösungen, um dieses Problem zu beheben:
-   - Unsere empfohlene Lösung ist der [Leitfaden zur Einrichtung eines lokalen Testservers](/de/docs/Learn/Common_questions/Tools_and_setup/set_up_a_local_testing_server) zu folgen. Mit dem aktiven Serverprogramm und den Dateien `apply-javascript-external.html` und `script.js`, die auf Port `8000` bereitgestellt werden, öffnen Sie Ihren Browser und gehen zu `http://localhost:8000`.
-   - Wenn Sie keinen lokalen Server ausführen können, können Sie auch `<script defer src="script.js"></script>` anstelle von `<script type="module" src="script.js"></script>` verwenden. Für weitere Informationen siehe [Strategien zum Laden von Skripten](#strategien_zum_laden_von_skripten) unten. Beachten Sie jedoch, dass Funktionen, die wir in anderen Teilen des Tutorials verwenden, möglicherweise trotzdem einen lokalen HTTP-Server benötigen.
-5. Jetzt funktioniert die Website genauso wie zuvor, aber jetzt haben wir unser JavaScript in einer externen Datei. Dies ist im Allgemeinen eine gute Sache im Hinblick auf die Organisation Ihres Codes und die Wiederverwendbarkeit über mehrere HTML-Dateien hinweg. Plus, das HTML ist einfacher zu lesen, ohne große Chunks von Skript darin zu haben.
+4. Speichern Sie und aktualisieren Sie Ihren Browser. Sie werden feststellen, dass das Klicken auf den Button keine Wirkung hat und wenn Sie die Konsole Ihres Browsers überprüfen, sehen Sie einen Fehler wie `Cross-origin request blocked`. Das liegt daran, dass wie viele externe Ressourcen JavaScript-Module von demselben [Ursprung](/de/docs/Web/Security/Same-origin_policy) wie das HTML geladen werden müssen und `file://`-URLs nicht qualifizieren. Es gibt zwei Lösungen, um dieses Problem zu beheben:
+   - Unsere empfohlene Lösung besteht darin, dem [Leitfaden zum Einrichten eines lokalen Testservers](/de/docs/Learn/Common_questions/Tools_and_setup/set_up_a_local_testing_server) zu folgen. Mit dem laufenden Serverprogramm, das die Dateien `apply-javascript-external.html` und `script.js` auf Port `8000` bedient, öffnen Sie Ihren Browser und gehen zu `http://localhost:8000`.
+   - Wenn Sie keinen lokalen Server starten können, können Sie auch `<script defer src="script.js"></script>` anstelle von `<script type="module" src="script.js"></script>` verwenden. Weitere Informationen finden Sie unter [Script-Ladestrategien](#script-ladestrategien) unten. Beachten Sie jedoch, dass Funktionen, die wir in anderen Teilen des Tutorials verwenden, möglicherweise ohnehin einen lokalen HTTP-Server erfordern.
+5. Nun funktioniert die Webseite genau wie zuvor, aber jetzt haben wir unser JavaScript in einer externen Datei.
+   Dies ist im Allgemeinen eine gute Sache in Bezug auf das Organisieren Ihres Codes und macht ihn wiederverwendbar über mehrere HTML-Dateien hinweg.
+   Außerdem ist das HTML leichter lesbar, ohne dass große Skriptblöcke darin enthalten sind.
 
 > [!NOTE]
-> Sie können diese Version auf GitHub als [apply-javascript-external.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript-external.html) und [script.js](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/script.js) ansehen ([sehen Sie es auch live](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/apply-javascript-external.html)).
+> Sie können diese Version auf GitHub als [apply-javascript-external.html](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/apply-javascript-external.html) und [script.js](https://github.com/mdn/learning-area/blob/main/javascript/introduction-to-js-1/what-is-js/script.js) sehen ([sehen Sie sich sie auch live an](https://mdn.github.io/learning-area/javascript/introduction-to-js-1/what-is-js/apply-javascript-external.html)).
 
 ### Inline-JavaScript-Handler
 
-Beachten Sie, dass Sie manchmal Teile von aktuellem JavaScript-Code in HTML vorfinden. Es könnte etwa so aussehen:
+Beachten Sie, dass Sie manchmal auf Teile von eigentlichem JavaScript-Code stoßen, die sich innerhalb von HTML befinden.
+Es könnte so aussehen:
 
 ```js example-bad
 function createParagraph() {
@@ -276,13 +306,16 @@ Sie können diese Version unseres Demos unten ausprobieren.
 
 {{ EmbedLiveSample('Inline_JavaScript_handlers', '100%', 150) }}
 
-Dieses Demo hat genau dieselbe Funktionalität wie in den vorhergehenden beiden Abschnitten, außer dass das {{htmlelement("button")}}-Element einen Inline-`onclick`-Handler beinhaltet, um die Funktion auszuführen, wenn der Button gedrückt wird.
+Dieses Demo hat genau die gleiche Funktionalität wie in den vorherigen beiden Abschnitten, außer dass das {{htmlelement("button")}}-Element einen Inline-`onclick`-Handler enthält, um die Funktion auszuführen, wenn der Button gedrückt wird.
 
-**Bitte tun Sie das jedoch nicht.** Es ist schlechte Praxis, Ihr HTML mit JavaScript zu verschmutzen, und es ist ineffizient — Sie müssten das `onclick="createParagraph()"`-Attribut auf jeden Button anwenden, auf den JavaScript wirken soll.
+**Bitte tun Sie das jedoch nicht.** Es ist schlechte Praxis, Ihr HTML mit JavaScript zu verschmutzen, und es ist ineffizient — Sie müssten das `onclick="createParagraph()"`-Attribut an jedem Button hinzufügen, auf den das JavaScript angewendet werden soll.
 
-### Verwendung von addEventListener stattdessen
+### Verwenden von addEventListener stattdessen
 
-Anstatt JavaScript in Ihr HTML einzufügen, verwenden Sie einen reinen JavaScript-Konstruktion. Die Funktion `querySelectorAll()` ermöglicht es Ihnen, alle Buttons auf einer Seite auszuwählen. Sie können dann durch die Buttons schleifen und mit `addEventListener()` einen Handler für jeden zuweisen. Der Code dafür sieht wie folgt aus:
+Anstelle von JavaScript in Ihr HTML einzuschließen, verwenden Sie eine reine JavaScript-Konstruktion.
+Die Funktion `querySelectorAll()` ermöglicht es Ihnen, alle Buttons auf einer Seite auszuwählen.
+Sie können dann durch die Buttons schleifen und mit `addEventListener()` jedem einen Handler zuweisen.
+Der Code dafür wird unten gezeigt:
 
 ```js
 const buttons = document.querySelectorAll("button");
@@ -292,29 +325,35 @@ for (const button of buttons) {
 }
 ```
 
-Dies könnte etwas länger sein als das `onclick`-Attribut, aber es wird für alle Buttons funktionieren — egal wie viele sich auf der Seite befinden, oder wie viele hinzugefügt oder entfernt werden. Das JavaScript muss nicht geändert werden.
+Dies mag etwas länger sein als das `onclick`-Attribut, aber es wird für alle Buttons funktionieren — egal wie viele auf der Seite sind oder wie viele hinzugefügt oder entfernt werden.
+Das JavaScript muss nicht geändert werden.
 
 > [!NOTE]
-> Versuchen Sie, Ihre Version von `apply-javascript.html` zu bearbeiten und fügen Sie einige weitere Buttons in die Datei ein. Wenn Sie neu laden, sollten Sie feststellen, dass alle Buttons bei einem Klick einen Paragraphen erstellen. Ziemlich ordentlich, nicht wahr?
+> Versuchen Sie, Ihre Version von `apply-javascript.html` zu bearbeiten und ein paar weitere Buttons in die Datei hinzuzufügen.
+> Wenn Sie neu laden, sollten Sie feststellen, dass alle Buttons, wenn sie geklickt werden, einen Absatz erstellen.
+> Ziemlich cool, oder?
 
-### Strategien zum Laden von Skripten
+### Script-Ladestrategien
 
-Der gesamte HTML-Inhalt auf einer Seite wird in der Reihenfolge geladen, in der er erscheint. Wenn Sie JavaScript verwenden, um Elemente auf der Seite zu manipulieren (oder genauer gesagt, das [Document Object Model](/de/docs/Learn/JavaScript/Client-side_web_APIs/Manipulating_documents#the_document_object_model)), wird Ihr Code nicht funktionieren, wenn das JavaScript geladen und analysiert wird, bevor das HTML, mit dem Sie etwas machen möchten.
+Der gesamte HTML-Code auf einer Seite wird in der Reihenfolge geladen, in der er erscheint.
+Wenn Sie JavaScript verwenden, um Elemente auf der Seite zu manipulieren (oder genauer gesagt, das [Document Object Model](/de/docs/Learn/JavaScript/Client-side_web_APIs/Manipulating_documents#the_document_object_model)), funktioniert Ihr Code nicht, wenn das JavaScript geladen und geparst wird, bevor das HTML, auf das Sie etwas anwenden möchten.
 
-Es gibt einige verschiedene Strategien, um sicherzustellen, dass Ihr JavaScript nur läuft, nachdem das HTML analysiert wurde:
+Es gibt einige verschiedene Strategien, um sicherzustellen, dass Ihr JavaScript erst nach dem Parsen des HTMLs ausgeführt wird:
 
-- Im obigen Beispiel für internes JavaScript wird das Skriptelement am unteren Ende des Body-Dokuments platziert und daher erst nach dem Analysieren des restlichen HTML-Bodys ausgeführt.
-- Im obigen Beispiel für externes JavaScript wird das Skriptelement im Kopf des Dokuments platziert, bevor der HTML-Body analysiert wird. Da wir jedoch `<script type="module">` verwenden, wird der Code als [Modul](/de/docs/Web/JavaScript/Guide/Modules) behandelt und der Browser wartet darauf, dass das gesamte HTML verarbeitet wird, bevor er JavaScript-Module ausführt. (Sie könnten externe Skripte auch am unteren Ende des Bodys platzieren. Aber wenn es viel HTML gibt und das Netzwerk langsam ist, kann es viel Zeit in Anspruch nehmen, bevor der Browser überhaupt anfangen kann, das Skript zu holen und zu laden, sodass das Platzieren externer Scripts im Kopf im Allgemeinen besser ist.)
-- Wenn Sie dennoch Nicht-Modul-Skripte im Dokumentkopf verwenden möchten, was die gesamte Seitendarstellung blockieren und Fehler verursachen könnte, weil es ausgeführt wird, bevor das HTML analysiert ist:
+- In dem oben genannten Beispiel für internes JavaScript wird das Skript-Element am unteren Ende des Bodys des Dokuments platziert und daher erst nach dem Rest des HTML-Bodys geparst ausgeführt.
+- Im obigen Beispiel für externes JavaScript wird das Skript-Element im Kopf des Dokuments platziert, bevor der HTML-Body geparst wird. Aber da wir `<script type="module">` verwenden, wird der Code als [Modul](/de/docs/Web/JavaScript/Guide/Modules) behandelt und der Browser wartet darauf, dass das gesamte HTML verarbeitet wird, bevor JavaScript-Module ausgeführt werden. (Sie könnten auch externe Skripte am Ende des Bodys platzieren. Aber wenn es viel HTML gibt und das Netzwerk langsam ist, kann es viel Zeit in Anspruch nehmen, bevor der Browser überhaupt anfangen kann, das Skript zu laden und zu laden, sodass das Platzieren externer Skripte im Kopf im Allgemeinen besser ist.)
+- Wenn Sie dennoch nicht-modulare Skripte im Dokumentenkopf verwenden möchten, die die gesamte Seite blockieren könnten und Fehler verursachen könnten, da sie ausgeführt werden, bevor das HTML geparst wird:
 
-  - Für externe Skripte sollten Sie das `defer` (oder falls Sie es nicht benötigen, das `async`) Attribut auf dem {{htmlelement("script")}}-Element hinzufügen.
-  - Für interne Skripte sollten Sie den Code in einem [`DOMContentLoaded`-Ereignishandler](/de/docs/Web/API/Document/DOMContentLoaded_event) einwickeln.
+  - Für externe Skripte sollten Sie das `defer` (oder wenn das HTML nicht sofort bereit ist, das `async`) Attribut auf dem {{htmlelement("script")}}-Element hinzufügen.
+  - Für interne Skripte sollten Sie den Code in einem [`DOMContentLoaded`-Ereignis-Listener](/de/docs/Web/API/Document/DOMContentLoaded_event) einwickeln.
 
-  Dies liegt jenseits des Umfangs des Tutorials an diesem Punkt, aber es sei denn, Sie müssen sehr alte Browser unterstützen, müssen Sie das nicht tun und können stattdessen einfach `<script type="module">` verwenden.
+  Das ist über den Rahmen des Tutorials an diesem Punkt hinausgehend, aber es sei denn, Sie müssen sehr alte Browser unterstützen, müssen Sie dies nicht tun und können stattdessen einfach `<script type="module">` verwenden.
 
 ## Kommentare
 
-Wie bei HTML und CSS ist es möglich, Kommentare in Ihren JavaScript-Code zu schreiben, die vom Browser ignoriert werden und Anweisungen an Ihre Kollegen enthalten, die erklären, wie der Code funktioniert (und für Sie, wenn Sie nach sechs Monaten zu Ihrem Code zurückkehren und sich nicht erinnern können, was Sie getan haben). Kommentare sind sehr nützlich und sollten häufig verwendet werden, insbesondere für größere Anwendungen. Es gibt zwei Typen:
+Wie mit HTML und CSS ist es möglich, Kommentare in Ihren JavaScript-Code zu schreiben, die vom Browser ignoriert werden und existieren, um Ihren Kollegen Anweisungen zu geben, wie der Code funktioniert (und Ihnen, wenn Sie nach sechs Monaten zu Ihrem Code zurückkehren und sich nicht mehr erinnern können, was Sie gemacht haben).
+Kommentare sind sehr nützlich und Sie sollten sie oft verwenden, besonders bei größeren Anwendungen.
+Es gibt zwei Arten:
 
 - Einzeilige Kommentare werden nach einem doppelten Schrägstrich (`//`) geschrieben, z.B.
 
@@ -331,7 +370,7 @@ Wie bei HTML und CSS ist es möglich, Kommentare in Ihren JavaScript-Code zu sch
   */
   ```
 
-Beispielsweise könnten wir das letzte JavaScript-Demo mit Kommentaren wie folgt kommentieren:
+So könnten wir beispielsweise das JavaScript unseres letzten Demos mit Kommentaren wie folgt annotieren:
 
 ```js
 // Function: creates a new paragraph and appends it to the bottom of the HTML body.
@@ -357,12 +396,15 @@ for (const button of buttons) {
 ```
 
 > [!NOTE]
-> Im Allgemeinen sind mehr Kommentare normalerweise besser als weniger, aber Sie sollten vorsichtig sein, wenn Sie feststellen, dass Sie viele Kommentare hinzufügen, um zu erklären, was Variablen sind (möglicherweise sollten Ihre Variablennamen intuitiver sein) oder um sehr einfache Vorgänge zu erklären (vielleicht ist Ihr Code überkompliziert).
+> Generell sind mehr Kommentare normalerweise besser als weniger, aber Sie sollten vorsichtig sein, wenn Sie feststellen, dass Sie viele Kommentare hinzufügen, um zu erklären, was Variablen sind (vielleicht sollten Ihre Variablennamen intuitiver sein), oder um sehr einfache Operationen zu erklären (vielleicht ist Ihr Code überkomplex).
 
 ## Zusammenfassung
 
-Da haben Sie es, Ihr erster Schritt in die Welt von JavaScript. Wir haben nur mit der Theorie begonnen, um Sie allmählich an die Gründe zu gewöhnen, warum Sie JavaScript verwenden könnten, und welche Art von Dingen Sie damit machen können. Auf dem Weg dorthin haben Sie einige Codebeispiele gesehen und gelernt, wie JavaScript mit dem Rest des Codes auf Ihrer Webseite zusammenpasst, unter anderen Dingen.
+Da haben Sie es, Ihren ersten Schritt in die Welt von JavaScript.
+Wir haben nur mit Theorie begonnen, um Sie daran zu gewöhnen, warum Sie JavaScript verwenden würden und welche Art von Dingen Sie damit tun können.
+Unterwegs haben Sie einige Codebeispiele gesehen und gelernt, wie JavaScript in den Rest des Codes auf Ihrer Webseite passt, unter anderem.
 
-JavaScript mag jetzt noch etwas einschüchternd erscheinen, aber keine Sorge – in diesem Kurs werden wir Sie in einfachen Schritten führen, die im weiteren Verlauf Sinn machen werden. Im nächsten Artikel werden wir [direkt in die Praxis einsteigen](/de/docs/Learn/JavaScript/First_steps/A_first_splash) und Sie dazu bringen, direkt einzutauchen und Ihre eigenen JavaScript-Beispiele zu erstellen.
+JavaScript mag jetzt ein bisschen überwältigend erscheinen, aber keine Sorge — in diesem Kurs werden wir Sie Schritt für Schritt durch das Thema führen, sodass es in der Zukunft Sinn macht.
+Im nächsten Artikel werden wir [direkt in die Praxis eintauchen](/de/docs/Learn/JavaScript/First_steps/A_first_splash) und Sie dazu bringen, direkt einzusteigen und Ihre eigenen JavaScript-Beispiele zu erstellen.
 
 {{NextMenu("Learn/JavaScript/First_steps/A_first_splash", "Learn/JavaScript/First_steps")}}
diff --git a/files/de/learn/javascript/objects/adding_bouncing_balls_features/index.md b/files/de/learn/javascript/objects/adding_bouncing_balls_features/index.md
index 01a5cf78b..c7e5e8753 100644
--- a/files/de/learn/javascript/objects/adding_bouncing_balls_features/index.md
+++ b/files/de/learn/javascript/objects/adding_bouncing_balls_features/index.md
@@ -2,27 +2,25 @@
 title: Hinzufügen von Funktionen zu unserem hüpfenden Kugeln-Demo
 slug: Learn/JavaScript/Objects/Adding_bouncing_balls_features
 l10n:
-  sourceCommit: bc0d0d1ef796435e969f6d65c7e5d3c08f4023aa
+  sourceCommit: 792424fa731eef9558b5e48c1239c7a76b143f81
 ---
 
 {{LearnSidebar}}{{PreviousMenuNext("Learn/JavaScript/Objects/Object_building_practice", "", "Learn/JavaScript/Objects")}}
 
-Bei dieser Bewertung sollen Sie das hüpfende Kugeln-Demo aus dem vorherigen Artikel als Ausgangspunkt verwenden und einige neue und interessante Funktionen hinzufügen.
+In dieser Bewertung wird erwartet, dass Sie das hüpfende Kugeln-Demo aus dem vorherigen Artikel als Ausgangspunkt verwenden und einige neue und interessante Funktionen hinzufügen.
 
 <table>
   <tbody>
     <tr>
       <th scope="row">Voraussetzungen:</th>
       <td>
-        Bevor Sie diese Bewertung angehen, sollten Sie alle Artikel in diesem Modul
-        durchgearbeitet haben.
+        Bevor Sie diese Bewertung versuchen, sollten Sie bereits alle Artikel in diesem Modul durchgearbeitet haben.
       </td>
     </tr>
     <tr>
       <th scope="row">Ziel:</th>
       <td>
-        Das Verständnis von JavaScript-Objekten und objektorientierten Konstrukten
-        zu testen.
+        Verständnis von JavaScript-Objekten und objektorientierten Konstrukten testen
       </td>
     </tr>
   </tbody>
@@ -30,29 +28,29 @@ Bei dieser Bewertung sollen Sie das hüpfende Kugeln-Demo aus dem vorherigen Art
 
 ## Ausgangspunkt
 
-Um mit dieser Bewertung zu beginnen, erstellen Sie eine lokale Kopie von [index-finished.html](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/index-finished.html), [style.css](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/style.css), und [main-finished.js](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/main-finished.js) aus unserem letzten Artikel in einem neuen Verzeichnis auf Ihrem lokalen Computer.
+Um mit dieser Bewertung zu beginnen, erstellen Sie eine lokale Kopie von [index-finished.html](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/index-finished.html), [style.css](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/style.css) und [main-finished.js](https://github.com/mdn/learning-area/blob/main/javascript/oojs/bouncing-balls/main-finished.js) aus unserem letzten Artikel in einem neuen Verzeichnis auf Ihrem lokalen Computer.
 
-Alternativ können Sie einen Online-Editor wie [CodePen](https://codepen.io/), [JSFiddle](https://jsfiddle.net/) oder [Glitch](https://glitch.com/) verwenden. Sie könnten das HTML, CSS und JavaScript in einen dieser Online-Editoren einfügen. Wenn der Online-Editor, den Sie verwenden, kein separates JavaScript-Panel hat, können Sie es gerne innerhalb eines `<script>`-Elements auf der HTML-Seite einfügen.
+Alternativ könnten Sie einen Online-Editor wie [CodePen](https://codepen.io/), [JSFiddle](https://jsfiddle.net/) oder [Glitch](https://glitch.com/) verwenden. Sie könnten das HTML, CSS und JavaScript in einen dieser Online-Editoren einfügen. Wenn der von Ihnen verwendete Online-Editor kein separates JavaScript-Panel hat, können Sie es gerne inline in ein `<script>`-Element innerhalb der HTML-Seite einfügen.
 
 > [!NOTE]
-> Wenn Sie nicht weiterkommen, können Sie sich in einem unserer [Kommunikationskanäle](/de/docs/MDN/Community/Communication_channels) an uns wenden.
+> Wenn Sie stecken bleiben, können Sie sich in einem unserer [Kommunikationskanäle](/de/docs/MDN/Community/Communication_channels) an uns wenden.
 
-## Tipps und Hinweise
+## Hinweise und Tipps
 
-Ein paar Hinweise, bevor Sie beginnen.
+Einige Hinweise, bevor Sie beginnen.
 
-- Diese Bewertung ist ziemlich anspruchsvoll. Lesen Sie die gesamte Bewertung, bevor Sie mit dem Codieren beginnen, und nehmen Sie sich für jeden Schritt langsam und sorgfältig Zeit.
-- Es könnte eine gute Idee sein, nach jeder erfolgreichen Stufe eine separate Kopie des Demos zu speichern, damit Sie darauf zurückgreifen können, wenn Sie später in Schwierigkeiten geraten.
+- Diese Bewertung ist recht anspruchsvoll. Lesen Sie die gesamte Bewertung, bevor Sie mit der Programmierung beginnen, und nehmen Sie sich für jeden Schritt Zeit und gehen Sie sorgfältig vor.
+- Es könnte eine gute Idee sein, nach jedem erfolgreich abgeschlossenen Stadium eine separate Kopie des Demos zu speichern, damit Sie darauf zurückgreifen können, wenn Sie später in Schwierigkeiten geraten.
 
-## Projektbeschreibung
+## Projektauftrag
 
-Unser hüpfendes Kugel-Demo macht Spaß, aber jetzt möchten wir es etwas interaktiver gestalten, indem wir einen benutzerkontrollierten bösen Kreis hinzufügen, der die Kugeln frisst, wenn er sie fängt. Wir möchten auch Ihre Objektbau-Fähigkeiten testen, indem wir ein generisches `Shape()`-Objekt erstellen, von dem unsere Kugeln und der böse Kreis erben können. Schließlich möchten wir einen Punktezähler hinzufügen, um die Anzahl der Kugeln zu verfolgen, die noch erfasst werden müssen.
+Unser hüpfendes Kugeln-Demo macht Spaß, aber jetzt wollen wir es etwas interaktiver gestalten, indem wir einen vom Benutzer gesteuerten bösen Kreis hinzufügen, der die Kugeln frisst, wenn er sie fängt. Außerdem möchten wir Ihre Objektbau-Fähigkeiten testen, indem wir ein generisches `Shape()`-Objekt erstellen, von dem unsere Kugeln und der böse Kreis erben können. Schließlich wollen wir einen Zähler hinzufügen, um die Anzahl der verbleibenden Kugeln zu erfassen.
 
-Der folgende Screenshot gibt Ihnen eine Vorstellung davon, wie das fertige Programm aussehen sollte:
+Das folgende Screenshot gibt Ihnen eine Vorstellung davon, wie das fertige Programm aussehen sollte:
 
 ![Screenshot der hüpfenden Kugeln-Demo-Seite. Ein weiß umrandeter Kreis ist zusätzlich zu den farbigen Kugeln sichtbar, und der Text "Ball count: 23" ist unter der Überschrift sichtbar.](bouncing-evil-circle.png)
 
-Um Ihnen eine genauere Vorstellung zu geben, werfen Sie einen Blick auf das [fertige Beispiel](https://mdn.github.io/learning-area/javascript/oojs/assessment/) (ohne in den Quellcode zu spähen!)
+Um Ihnen noch mehr von einer Vorstellung zu geben, schauen Sie sich das [fertige Beispiel](https://mdn.github.io/learning-area/javascript/oojs/assessment/) an (schauen Sie nicht im Quellcode nach!)
 
 ## Schritte zur Fertigstellung
 
@@ -60,17 +58,20 @@ Die folgenden Abschnitte beschreiben, was Sie tun müssen.
 
 ### Erstellen einer Shape-Klasse
 
-Zuerst erstellen Sie eine neue `Shape`-Klasse. Diese hat nur einen Konstruktor. Der `Shape`-Konstruktor sollte die Eigenschaften `x`, `y`, `velX` und `velY` auf die gleiche Weise definieren, wie es der `Ball()`-Konstruktor ursprünglich tat, jedoch nicht die Eigenschaften `color` und `size`.
+Zunächst einmal erstellen Sie eine neue `Shape`-Klasse. Diese hat nur einen Konstruktor. Der `Shape`-Konstruktor sollte die Eigenschaften `x`, `y`, `velX` und `velY` auf die gleiche Weise definieren, wie es der `Ball()`-Konstruktor ursprünglich getan hat, jedoch nicht die Eigenschaften `color` und `size`.
 
-Die `Ball`-Klasse sollte durch `extends` von `Shape` abgeleitet werden. Der Konstruktor für `Ball` sollte:
+Die `Ball`-Klasse sollte von `Shape` mit `extends` abgeleitet werden. Der Konstruktor für `Ball` sollte:
 
 - die gleichen Argumente wie zuvor annehmen: `x`, `y`, `velX`, `velY`, `size` und `color`
-- den `Shape`-Konstruktor unter Verwendung von `super()` aufrufen und ihm die Argumente `x`, `y`, `velX` und `velY` übergeben
-- seine eigenen `color`- und `size`-Eigenschaften aus den übergebenen Parametern initialisieren.
+- den `Shape`-Konstruktor mit `super()` aufrufen, wobei die Argumente `x`, `y`, `velX` und `velY` übergeben werden
+- seine eigenen Eigenschaften `color` und `size` aus den gegebenen Parametern initialisieren.
 
-Der `Ball`-Konstruktor sollte eine neue Eigenschaft namens `exists` definieren, die verwendet wird, um zu verfolgen, ob die Kugeln im Programm existieren (nicht vom bösen Kreis gefressen wurden). Dies sollte ein boolescher Wert (`true`/`false`) sein, der im Konstruktor auf `true` initialisiert wird.
+> [!NOTE]
+> Stellen Sie sicher, dass die `Shape`-Klasse oberhalb der bestehenden `Ball`-Klasse erstellt wird, sonst erhalten Sie einen Fehler wie: "Uncaught ReferenceError: Cannot access 'Shape' before initialization"
+
+Der `Ball`-Konstruktor sollte eine neue Eigenschaft namens `exists` definieren, die verwendet wird, um zu verfolgen, ob die Kugeln im Programm existieren (nicht vom bösen Kreis gefressen wurden). Dies sollte ein boolean (`true`/`false`) sein, der im Konstruktor auf `true` initialisiert wird.
 
-Die `collisionDetect()`-Methode der `Ball`-Klasse benötigt ein kleines Update. Eine Kugel muss nur dann für die Kollisionsdetektion in Betracht gezogen werden, wenn die Eigenschaft `exists` den Wert `true` hat. Ersetzen Sie daher den vorhandenen `collisionDetect()`-Code durch den folgenden:
+Die `collisionDetect()`-Methode der `Ball`-Klasse benötigt ein kleines Update. Eine Kugel muss nur für die Kollisionserkennung in Betracht gezogen werden, wenn die Eigenschaft `exists` `true` ist. Ersetzen Sie also den vorhandenen `collisionDetect()`-Code durch folgenden Code:
 
 ```js
 collisionDetect() {
@@ -88,27 +89,27 @@ collisionDetect() {
 }
 ```
 
-Wie oben erwähnt, ist die einzige Ergänzung, dass überprüft wird, ob die Kugel existiert — indem `ball.exists` in der `if`-Bedingung verwendet wird.
+Wie oben besprochen, besteht die einzige Ergänzung darin, zu überprüfen, ob die Kugel existiert — indem `ball.exists` in der `if`-Bedingung verwendet wird.
 
-Die Methoden `draw()` und `update()` der Kugel sollten genauso bleiben können, wie sie zuvor waren.
+Die Definitionen der Methoden `draw()` und `update()` der Kugel sollten genauso bleiben können, wie sie vorher waren.
 
-Versuchen Sie zu diesem Zeitpunkt, den Code neu zu laden — er sollte genauso funktionieren wie zuvor, mit unseren neu gestalteten Objekten.
+An diesem Punkt sollten Sie den Code neu laden — er sollte genauso wie zuvor funktionieren, mit unseren neu gestalteten Objekten.
 
-### Definition des EvilCircle
+### Definieren von EvilCircle
 
-Nun ist es an der Zeit, den Bösewicht kennenzulernen — den `EvilCircle()`! Unser Spiel wird nur einen bösen Kreis beinhalten, aber wir werden ihn trotzdem mit einem Konstruktor definieren, der von `Shape()` erbt, um Ihnen etwas Übung zu geben. Vielleicht möchten Sie später einen weiteren Kreis zur App hinzufügen, der von einem anderen Spieler gesteuert werden kann, oder mehrere computergesteuerte böse Kreise haben. Sie werden die Welt wahrscheinlich nicht mit einem einzigen bösen Kreis erobern, aber er wird für diese Bewertung genügen.
+Es ist jetzt an der Zeit, den Bösewicht kennenzulernen — den `EvilCircle()`! Unser Spiel wird nur einen bösen Kreis beinhalten, aber wir werden ihn trotzdem mit einem Konstruktor definieren, der von `Shape()` erbt, um Ihnen etwas Übung zu geben. Sie könnten später einen weiteren Kreis zur App hinzufügen, der von einem anderen Spieler gesteuert werden kann, oder mehrere computer-gesteuerte böse Kreise haben. Sie werden wahrscheinlich nicht die Welt mit einem einzelnen bösen Kreis beherrschen, aber für diese Bewertung reicht es.
 
-Erstellen Sie eine Definition für eine `EvilCircle`-Klasse. Sie sollte per `extends` von `Shape` erben.
+Erstellen Sie eine Definition für eine `EvilCircle`-Klasse. Sie sollte von `Shape` mit `extends` erben.
 
 #### EvilCircle-Konstruktor
 
 Der Konstruktor für `EvilCircle` sollte:
 
 - nur die Argumente `x`, `y` übergeben bekommen
-- die Argumente `x`, `y` an die `Shape`-Superklasse zusammen mit Werten für `velX` und `velY`, die fest auf 20 gesetzt sind, weitergeben. Sie sollten dies mit einem Code wie `super(x, y, 20, 20);` tun.
+- die Argumente `x`, `y` an die `Shape`-Superklasse zusammen mit Werten für `velX` und `velY`, die fest auf 20 gesetzt werden, übergeben. Sie sollten dies mit Code wie `super(x, y, 20, 20);` tun.
 - `color` auf `white` und `size` auf `10` setzen.
 
-Schließlich sollte der Konstruktor den Code einrichten, der es dem Benutzer ermöglicht, den bösen Kreis auf dem Bildschirm zu bewegen:
+Schließlich sollte der Konstruktor den Code einrichten, der es dem Benutzer ermöglicht, den bösen Kreis über den Bildschirm zu bewegen:
 
 ```js
 window.addEventListener("keydown", (e) => {
@@ -129,47 +130,47 @@ window.addEventListener("keydown", (e) => {
 });
 ```
 
-Dies fügt dem `window`-Objekt einen `keydown`-Event-Listener hinzu, sodass bei einem Tastendruck die [`key`](/de/docs/Web/API/KeyboardEvent/key)-Eigenschaft des Ereignisobjekts abgefragt wird, um zu sehen, welche Taste gedrückt wurde. Wenn es eine der vier angegebenen Tasten ist, bewegt sich der böse Kreis nach links/rechts/oben/unten.
+Dies fügt dem `window`-Objekt einen `keydown`-Event-Listener hinzu, sodass, wenn eine Taste gedrückt wird, die [`key`-Eigenschaft](/de/docs/Web/API/KeyboardEvent/key) des Event-Objekts konsultiert wird, um festzustellen, welche Taste gedrückt wurde. Wenn es eine der vier angegebenen Tasten ist, bewegt sich der böse Kreis nach links/rechts/oben/unten.
 
-### Definition der Methoden für EvilCircle
+### Definieren von Methoden für EvilCircle
 
 Die `EvilCircle`-Klasse sollte drei Methoden haben, wie unten beschrieben.
 
 #### draw()
 
-Diese Methode hat denselben Zweck wie die `draw()`-Methode für `Ball`: Sie zeichnet die Objektinstanz auf der Leinwand. Die `draw()`-Methode für `EvilCircle` wird auf sehr ähnliche Weise arbeiten, sodass Sie mit dem Kopieren der `draw()`-Methode für `Ball` beginnen können. Sie sollten dann die folgenden Änderungen vornehmen:
+Diese Methode hat denselben Zweck wie die `draw()`-Methode für `Ball`: Sie zeichnet die Objektinstanz auf der Leinwand. Die `draw()`-Methode für `EvilCircle` wird auf sehr ähnliche Weise funktionieren, sodass Sie mit dem Kopieren der `draw()`-Methode für `Ball` beginnen können. Sie sollten dann die folgenden Änderungen vornehmen:
 
-- Wir möchten, dass der böse Kreis nicht gefüllt ist, sondern nur eine Außenlinie (Umriss) hat. Dies können Sie erreichen, indem Sie [`fillStyle`](/de/docs/Web/API/CanvasRenderingContext2D/fillStyle) und [`fill()`](/de/docs/Web/API/CanvasRenderingContext2D/fill) durch [`strokeStyle`](/de/docs/Web/API/CanvasRenderingContext2D/strokeStyle) und [`stroke()`](/de/docs/Web/API/CanvasRenderingContext2D/stroke) ersetzen.
-- Wir möchten auch den Umriss etwas dicker machen, damit Sie den bösen Kreis etwas leichter sehen können. Dies kann erreicht werden, indem ein Wert für [`lineWidth`](/de/docs/Web/API/CanvasRenderingContext2D/lineWidth) irgendwo nach dem Aufruf von [`beginPath()`](/de/docs/Web/API/CanvasRenderingContext2D/beginPath) gesetzt wird (3 reicht aus).
+- Wir wollen, dass der böse Kreis nicht ausgefüllt ist, sondern nur eine äußere Linie (Strich) hat. Sie können dies erreichen, indem Sie [`fillStyle`](/de/docs/Web/API/CanvasRenderingContext2D/fillStyle) und [`fill()`](/de/docs/Web/API/CanvasRenderingContext2D/fill) auf [`strokeStyle`](/de/docs/Web/API/CanvasRenderingContext2D/strokeStyle) und [`stroke()`](/de/docs/Web/API/CanvasRenderingContext2D/stroke) aktualisieren.
+- Wir wollen auch den Strich etwas dicker machen, sodass Sie den bösen Kreis etwas einfacher sehen können. Dies kann erreicht werden, indem ein Wert für [`lineWidth`](/de/docs/Web/API/CanvasRenderingContext2D/lineWidth) irgendwo nach dem Aufruf von [`beginPath()`](/de/docs/Web/API/CanvasRenderingContext2D/beginPath) gesetzt wird (3 wäre ausreichend).
 
 #### checkBounds()
 
-Diese Methode wird dasselbe tun wie der erste Teil der `update()`-Methode für `Ball` — prüfen, ob der böse Kreis vom Rand des Bildschirms verschwinden wird, und ihn daran hindern. Auch hier können Sie größtenteils die `update()`-Methode für `Ball` kopieren, aber es gibt einige Änderungen, die Sie vornehmen sollten:
+Diese Methode soll dasselbe tun wie der erste Teil der `update()`-Methode für `Ball` — überprüfen, ob der böse Kreis vom Bildschirmrand abweichen wird, und ihn daran hindern. Auch hier können Sie größtenteils die `update()`-Methode für `Ball` kopieren, allerdings gibt es einige Änderungen, die Sie vornehmen sollten:
 
-- Entfernen Sie die letzten beiden Zeilen — wir möchten die Position des bösen Kreises nicht automatisch bei jedem Frame aktualisieren, weil wir ihn auf andere Weise bewegen werden, wie Sie unten sehen werden.
-- In den `if ()`-Anweisungen, wenn die Tests "wahr" zurückgeben, möchten wir `velX`/`velY` nicht aktualisieren; wir möchten stattdessen den Wert von `x`/`y` ändern, sodass der böse Kreis leicht wieder auf den Bildschirm zurückspringt. Das Hinzufügen oder Subtrahieren (je nach Fall) der `size`-Eigenschaft des bösen Kreises wäre sinnvoll.
+- Entfernen Sie die letzten beiden Zeilen — wir wollen den Standort des bösen Kreises nicht bei jedem Frame automatisch aktualisieren, weil wir ihn auf andere Weise bewegen werden, wie Sie unten sehen werden.
+- Innerhalb der `if ()`-Anweisungen, wenn die Tests wahr zurückgeben, wollen wir `velX`/`velY` nicht aktualisieren; wir wollen stattdessen den Wert von `x`/`y` ändern, damit der böse Kreis leicht auf den Bildschirm zurückspringt. Es würde Sinn machen, die Größe des bösen Kreises zum Addieren oder Subtrahieren zu verwenden (je nach Situation).
 
 #### collisionDetect()
 
-Diese Methode wird auf sehr ähnliche Weise wie die `collisionDetect()`-Methode für `Ball` arbeiten, sodass Sie eine Kopie davon als Grundlage für diese neue Methode verwenden können. Aber es gibt ein paar Unterschiede:
+Diese Methode wird auf sehr ähnliche Weise wie die `collisionDetect()`-Methode für `Ball` funktionieren, sodass Sie eine Kopie davon als Grundlage für diese neue Methode verwenden können. Aber es gibt ein paar Unterschiede:
 
-- In der äußeren `if`-Anweisung müssen Sie nicht mehr prüfen, ob die aktuelle Kugel in der Iteration die gleiche ist wie die Kugel, die die Prüfung durchführt — denn es ist keine Kugel mehr, es ist der böse Kreis! Stattdessen müssen Sie einen Test durchführen, um zu sehen, ob die Kugel, die geprüft wird, existiert (mit welcher Eigenschaft könnten Sie dies tun?). Wenn sie nicht existiert, wurde sie bereits vom bösen Kreis gefressen, sodass es keinen Grund mehr gibt, sie erneut zu prüfen.
-- In der inneren `if`-Anweisung möchten Sie nicht mehr, dass sich die Objekte bei einer Kollision verfärben — stattdessen möchten Sie alle Kugeln, die mit dem bösen Kreis kollidieren, so setzen, dass sie nicht mehr existieren (wieder einmal, wie denken Sie, würden Sie das tun?).
+- In der äußeren `if`-Anweisung müssen Sie nicht mehr überprüfen, ob die aktuelle Kugel in der Iteration dieselbe ist wie die Kugel, die die Überprüfung durchführt — da es nicht mehr eine Kugel, sondern der böse Kreis ist! Stattdessen müssen Sie einen Test durchführen, um zu sehen, ob die zu überprüfende Kugel existiert (mit welcher Eigenschaft könnten Sie dies tun?). Wenn sie nicht existiert, wurde sie bereits vom bösen Kreis gefressen, sodass es nicht notwendig ist, sie erneut zu überprüfen.
+- In der inneren `if`-Anweisung wollen Sie nicht mehr, dass die Objekte ihre Farbe ändern, wenn eine Kollision festgestellt wird — stattdessen möchten Sie festlegen, dass alle Kugeln, die mit dem bösen Kreis kollidieren, nicht mehr existent sind (wie würden Sie das wohl tun?).
 
-### Einbringen des bösen Kreises in das Programm
+### Einführen des bösen Kreises ins Programm
 
-Jetzt, da wir den bösen Kreis definiert haben, müssen wir ihn tatsächlich in unserer Szene erscheinen lassen. Dazu müssen Sie einige Änderungen an der `loop()`-Funktion vornehmen.
+Nachdem wir nun den bösen Kreis definiert haben, müssen wir ihn tatsächlich in unserer Szene erscheinen lassen. Dafür müssen Sie einige Änderungen an der `loop()`-Funktion vornehmen.
 
-- Erstellen Sie zunächst eine neue Objektinstanz des bösen Kreises (spezifizieren Sie die erforderlichen Parameter). Sie müssen dies nur einmal tun, nicht bei jeder Iteration der Schleife.
-- An der Stelle, an der Sie durch jede Kugel iterieren und die `draw()`, `update()` und `collisionDetect()`-Funktionen für jede aufrufen, stellen Sie sicher, dass diese Funktionen nur aufgerufen werden, wenn die aktuelle Kugel existiert.
-- Rufen Sie die `draw()`, `checkBounds()` und `collisionDetect()`-Methoden der bösen Kreisinstanz bei jeder Iteration der Schleife auf.
+- Erstellen Sie zuerst ein neues Objekt des bösen Kreises (mit den erforderlichen Parametern). Sie müssen dies nur einmal tun, nicht bei jeder Iteration der Schleife.
+- An der Stelle, an der Sie durch jede Kugel iterieren und die Funktionen `draw()`, `update()` und `collisionDetect()` für jede aufrufen, sorgen Sie dafür, dass diese Funktionen nur aufgerufen werden, wenn die aktuelle Kugel existiert.
+- Rufen Sie die Methoden `draw()`, `checkBounds()` und `collisionDetect()` der bösen Kreisinstanz bei jeder Iteration der Schleife auf.
 
-### Implementierung des Punktezählers
+### Implementieren des Punktzählers
 
-Um den Punktezähler zu implementieren, führen Sie die folgenden Schritte aus:
+Um den Punktzähler zu implementieren, gehen Sie wie folgt vor:
 
 1. Fügen Sie in Ihrer HTML-Datei ein {{HTMLElement("p")}}-Element direkt unter dem {{HTMLElement("Heading_Elements", "h1")}}-Element hinzu, das den Text "Ball count: " enthält.
-2. Fügen Sie in Ihrer CSS-Datei die folgende Regel am Ende hinzu:
+2. Fügen Sie in Ihrer CSS-Datei folgende Regel am Ende hinzu:
 
    ```css
    p {
@@ -181,11 +182,11 @@ Um den Punktezähler zu implementieren, führen Sie die folgenden Schritte aus:
    }
    ```
 
-3. In Ihrem JavaScript nehmen Sie die folgenden Aktualisierungen vor:
+3. Machen Sie in Ihrem JavaScript folgende Aktualisierungen:
 
    - Erstellen Sie eine Variable, die eine Referenz auf den Absatz speichert.
-   - Halten Sie irgendwie die Anzahl der Kugeln auf dem Bildschirm fest.
-   - Erhöhen Sie die Zählung und zeigen Sie die aktualisierte Anzahl der Kugeln jedes Mal an, wenn eine Kugel zur Szene hinzugefügt wird.
-   - Verringern Sie die Zählung und zeigen Sie die aktualisierte Anzahl der Kugeln jedes Mal an, wenn der böse Kreis eine Kugel frisst (sie verursacht, dass sie nicht mehr existiert).
+   - Halten Sie die Anzahl der Kugeln auf dem Bildschirm in irgendeiner Weise fest.
+   - Erhöhen Sie die Zählung und zeigen Sie die aktualisierte Anzahl der Kugeln an, jedes Mal, wenn eine Kugel zur Szene hinzugefügt wird.
+   - Verringern Sie die Zählung und zeigen Sie die aktualisierte Anzahl der Kugeln an, jedes Mal, wenn der böse Kreis eine Kugel frisst (verursacht, dass sie nicht mehr existiert).
 
 {{PreviousMenuNext("Learn/JavaScript/Objects/Object_building_practice", "", "Learn/JavaScript/Objects")}}
diff --git a/files/de/learn/server-side/apache_configuration_htaccess/index.md b/files/de/learn/server-side/apache_configuration_htaccess/index.md
index ae6194feb..69c98649d 100644
--- a/files/de/learn/server-side/apache_configuration_htaccess/index.md
+++ b/files/de/learn/server-side/apache_configuration_htaccess/index.md
@@ -2,24 +2,24 @@
 title: "Apache-Konfiguration: .htaccess"
 slug: Learn/Server-side/Apache_Configuration_htaccess
 l10n:
-  sourceCommit: d71da812ee94c20658cb1916a123a42254ea545c
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{LearnSidebar}}
 
-Apache .htaccess-Dateien ermöglichen es Benutzern, Verzeichnisse des Webservers zu konfigurieren, die sie kontrollieren, ohne die Hauptkonfigurationsdatei zu ändern.
+Apache `.htaccess`-Dateien ermöglichen es Benutzern, Verzeichnisse des Webservers, den sie kontrollieren, zu konfigurieren, ohne die Hauptkonfigurationsdatei zu ändern.
 
-Obwohl dies nützlich ist, ist es wichtig zu beachten, dass die Verwendung von `.htaccess`-Dateien Apache verlangsamt. Wenn Sie Zugriff auf die Hauptkonfigurationsdatei des Servers haben (die normalerweise `httpd.conf` genannt wird), sollten Sie diese Logik dort in einem `Directory`-Block hinzufügen.
+Obwohl dies nützlich ist, ist es wichtig zu beachten, dass die Verwendung von `.htaccess`-Dateien Apache verlangsamt. Wenn Sie Zugang zur Hauptserver-Konfigurationsdatei haben (welche normalerweise `httpd.conf` genannt wird), sollten Sie diese Logik dort unter einem `Directory`-Block hinzufügen.
 
-Weitere Details darüber, was .htaccess-Dateien tun können, finden Sie unter [.htaccess](https://httpd.apache.org/docs/current/howto/htaccess.html) in der Apache HTTPD-Dokumentationsseite.
+Sehen Sie [.htaccess](https://httpd.apache.org/docs/current/howto/htaccess.html) in der Apache HTTPD-Dokumentationsseite für weitere Details darüber, was `.htaccess`-Dateien tun können.
 
-Der Rest dieses Dokuments wird verschiedene Konfigurationsoptionen erörtern, die Sie zur `.htaccess` hinzufügen können, und deren Funktionalität erklären.
+Der Rest dieses Dokuments wird verschiedene Konfigurationsoptionen diskutieren, die Sie zu `.htaccess` hinzufügen können und was sie bewirken.
 
-Die meisten der folgenden Blöcke verwenden die [IfModule](https://httpd.apache.org/docs/2.4/mod/core.html#ifmodule)-Direktive, um die Anweisungen im Block nur auszuführen, wenn das entsprechende Modul korrekt konfiguriert und vom Server geladen wurde. So verhindern wir, dass unser Server abstürzt, wenn das Modul nicht geladen wurde.
+Die meisten der folgenden Blöcke verwenden die [IfModule](https://httpd.apache.org/docs/2.4/mod/core.html#ifmodule) Direktive, um die Anweisungen innerhalb des Blocks nur auszuführen, wenn das entsprechende Modul richtig konfiguriert wurde und der Server es geladen hat. Auf diese Weise schützen wir unseren Server vor Abstürzen, wenn das Modul nicht geladen wurde.
 
 ## Umleitungen
 
-Es gibt Zeiten, in denen wir den Benutzern mitteilen müssen, dass eine Ressource entweder temporär oder dauerhaft verschoben wurde. Dafür verwenden wir `Redirect` und `RedirectMatch`.
+Es gibt Zeiten, in denen wir den Benutzern mitteilen müssen, dass eine Ressource entweder vorübergehend oder dauerhaft verschoben wurde. Dafür verwenden wir `Redirect` und `RedirectMatch`.
 
 ```apacheconf
 <IfModule mod_alias.c>
@@ -41,26 +41,26 @@ Es gibt Zeiten, in denen wir den Benutzern mitteilen müssen, dass eine Ressourc
 </IfModule>
 ```
 
-Die möglichen Werte für den ersten Parameter sind unten aufgelistet. Wenn der erste Parameter nicht enthalten ist, ist der Standardwert `temp`.
+Die möglichen Werte für den ersten Parameter sind unten aufgeführt. Wenn der erste Parameter nicht enthalten ist, wird `temp` als Standardwert verwendet.
 
 - permanent
-  - : Gibt einen permanenten Weiterleitungsstatus (301) zurück, der anzeigt, dass die Ressource dauerhaft verschoben wurde.
+  - : Gibt einen permanenten Umleitungsstatus (301) zurück, der anzeigt, dass die Ressource dauerhaft verschoben wurde.
 - temp
-  - : Gibt einen temporären Weiterleitungsstatus (302) zurück. **Dies ist der Standardwert**.
+  - : Gibt einen temporären Umleitungsstatus (302) zurück. **Dies ist der Standard**.
 - seeother
   - : Gibt einen "See Other"-Status (303) zurück, der anzeigt, dass die Ressource ersetzt wurde.
 - gone
-  - : Gibt einen "Gone"-Status (410) zurück, der anzeigt, dass die Ressource dauerhaft entfernt wurde. Bei Verwendung dieses Status sollte das _URL_-Argument weggelassen werden.
+  - : Gibt einen "Gone"-Status (410) zurück, der anzeigt, dass die Ressource dauerhaft entfernt wurde. Wenn dieser Status verwendet wird, sollte das _URL_-Argument weggelassen werden.
 
 ## Cross-Origin-Ressourcen
 
-Die erste Reihe von Direktiven steuert den Zugriff auf [CORS](https://fetch.spec.whatwg.org/) (Cross-Origin Resource Sharing)-Ressourcen vom Server. CORS ist ein auf HTTP-Headern basierender Mechanismus, der es einem Server ermöglicht, die externen Ursprünge (Domain, Protokoll oder Port) anzugeben, deren Laden von Ressourcen ein Browser erlauben soll.
+Der erste Satz von Direktiven steuert den Zugang zu [CORS](https://fetch.spec.whatwg.org/) (Cross-Origin Resource Sharing) Ressourcen vom Server. CORS ist ein HTTP-Header basierter Mechanismus, der es einem Server ermöglicht, die externen Ursprünge (Domain, Protokoll oder Port) zu kennzeichnen, die ein Browser laden darf.
 
-Aus Sicherheitsgründen beschränken Browser Cross-Origin-HTTP-Anfragen, die von Skripten initiiert werden. Beispielsweise folgen XMLHttpRequest und die Fetch-API der Same-Origin-Policy. Eine Webanwendung, die diese APIs verwendet, kann nur Ressourcen von derselben Herkunft anfordern, von der die Anwendung geladen wurde, es sei denn, die Antwort von anderen Ursprüngen enthält die entsprechenden CORS-Header.
+Aus Sicherheitsgründen beschränken Browser Cross-Origin-HTTP-Anfragen, die von Skripten initiiert werden. Zum Beispiel folgen `XMLHttpRequest` und die `Fetch-API` der Same-Origin-Policy. Eine Webanwendung, die diese APIs verwendet, kann nur Ressourcen von demselben Ursprung anfordern, von dem die Anwendung geladen wurde, es sei denn, die Antwort von anderen Ursprüngen enthält die entsprechenden CORS-Header.
 
-### Allgemeiner CORS-Zugriff
+### Allgemeiner Zugriff auf CORS
 
-Diese Direktive fügt allen Ressourcen im Verzeichnis den CORS-Header für jede Website hinzu.
+Diese Direktive fügt den CORS-Header für alle Ressourcen im Verzeichnis von jeder Website hinzu.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -68,9 +68,9 @@ Diese Direktive fügt allen Ressourcen im Verzeichnis den CORS-Header für jede
 </IfModule>
 ```
 
-Sofern Sie die Direktive nicht später in der Konfiguration oder in der Konfiguration eines darunter liegenden Verzeichnisses überschreiben, wird jede Anfrage von externen Servern akzeptiert, was vermutlich nicht beabsichtigt ist.
+Sofern Sie die Direktive später in der Konfiguration oder in der Konfiguration eines darunter liegenden Verzeichnisses nicht überschreiben, wird jede Anfrage von externen Servern akzeptiert, was wahrscheinlich nicht das ist, was Sie möchten.
 
-Eine Alternative ist es, explizit anzugeben, welche Domains auf den Inhalt Ihrer Website zugreifen dürfen. Im folgenden Beispiel beschränken wir den Zugriff auf ein Subdomain unserer Hauptseite (example.com). Dies ist sicherer und wahrscheinlich das, was Sie beabsichtigen.
+Eine Alternative besteht darin, explizit anzugeben, welche Domains auf den Inhalt Ihrer Seite zugreifen dürfen. Im folgenden Beispiel beschränken wir den Zugriff auf eine Subdomain unserer Hauptseite (example.com). Dies ist sicherer und wahrscheinlich das, was Sie beabsichtigt haben.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -80,9 +80,9 @@ Eine Alternative ist es, explizit anzugeben, welche Domains auf den Inhalt Ihrer
 
 ### Cross-Origin-Bilder
 
-Wie im [Chromium-Blog](https://blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html) berichtet und in [Erlauben der cross-origin-Nutzung von Bildern und Canvas](/de/docs/Web/HTML/CORS_enabled_image) dokumentiert, können [Fingerabdruck-](fingerprinting-)Angriffe ermöglichen.
+Wie im [Chromium Blog](https://blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html) berichtet und in [Verwendung von Cross-Origin-Bildern und Canvas](/de/docs/Web/HTML/CORS_enabled_image) dokumentiert, kann dies zu {{Glossary("Fingerprinting", "Fingerprinting")}}-Angriffen führen.
 
-Um die Möglichkeit solcher Angriffe zu verringern, sollten Sie das `crossorigin`-Attribut in den Bildern verwenden, die Sie anfordern, und den untenstehenden Codeausschnitt in Ihrer `.htaccess` verwenden, um den CORS-Header vom Server zu setzen.
+Um die Möglichkeit dieser Angriffe zu verringern, sollten Sie das `crossorigin`-Attribut in den Bildern verwenden, die Sie anfordern, und den unten stehenden Code-Snippet in Ihrer `.htaccess` verwenden, um den CORS-Header vom Server zu setzen.
 
 ```apacheconf
 <IfModule mod_setenvif.c>
@@ -95,7 +95,7 @@ Um die Möglichkeit solcher Angriffe zu verringern, sollten Sie das `crossorigin
 </IfModule>
 ```
 
-Das [Google Schriftarten-Troubleshooting-Leitfaden](https://developers.google.com/fonts/docs/troubleshooting) von Google Chrome erklärt, dass, während Google Fonts den CORS-Header mit jeder Antwort senden kann, einige Proxy-Server ihn entfernen können, bevor der Browser ihn verwenden kann, um die Schriftart anzuzeigen.
+In Google Chromes [Fehlerbehebungsleitfaden für Google Fonts](https://developers.google.com/fonts/docs/troubleshooting) wird uns gesagt, dass, obwohl Google Fonts den CORS-Header mit jeder Antwort sendet, einige Proxy-Server diesen entfernen können, bevor der Browser ihn verwenden kann, um die Schriftart zu rendern.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -107,11 +107,11 @@ Das [Google Schriftarten-Troubleshooting-Leitfaden](https://developers.google.co
 
 ### Cross-Origin-Ressourcen-Timing
 
-Die [Resource Timing Level 1](https://www.w3.org/TR/resource-timing/) Spezifikation definiert eine Schnittstelle für Webanwendungen, um vollständige Timing-Informationen für Ressourcen in einem Dokument zu erhalten.
+Die [Resource Timing Level 1](https://www.w3.org/TR/resource-timing/) Spezifikation definiert eine Schnittstelle für Webanwendungen zum Zugriff auf die vollständigen Timing-Informationen für Ressourcen in einem Dokument.
 
-Der [Timing-Allow-Origin](/de/docs/Web/HTTP/Headers/Timing-Allow-Origin) Antwort-Header spezifiziert Ursprünge, die die Werte der über Funktionen der Resource Timing API abgerufenen Attribute sehen dürfen, die sonst aufgrund von Cross-Origin-Beschränkungen als null gemeldet würden.
+Der [Timing-Allow-Origin](/de/docs/Web/HTTP/Headers/Timing-Allow-Origin) Antwortheader gibt Ursprünge an, die die Werte von Attributen einsehen dürfen, die über die Funktionen der Resource Timing API abgerufen wurden und sonst aufgrund von Cross-Origin-Einschränkungen als Null gemeldet würden.
 
-Wenn eine Ressource nicht mit einem `Timing-Allow-Origin` bedient wird oder der Header nicht den Ursprung nach der Durchführung der Anfrage enthält, werden einige Attribute des `PerformanceResourceTiming`-Objekts auf null gesetzt.
+Wenn eine Ressource nicht mit `Timing-Allow-Origin` bereitgestellt wird oder wenn der Header nach der Anforderung nicht den Ursprung enthält, werden einige Attribute des `PerformanceResourceTiming` Objekts auf Null gesetzt.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -119,13 +119,13 @@ Wenn eine Ressource nicht mit einem `Timing-Allow-Origin` bedient wird oder der
 </IfModule>
 ```
 
-## Benutzerdefinierte Fehlerseiten/-nachrichten
+## Benutzerdefinierte Fehlerseiten/nachrichten
 
-Apache ermöglicht es, Benutzern je nach Art des Fehlers, den sie erhalten, benutzerdefinierte Fehlerseiten bereitzustellen.
+Apache ermöglicht es Ihnen, benutzerdefinierte Fehlerseiten für Benutzer bereitzustellen, abhängig von der Art des Fehlers, den sie erhalten.
 
-Die Fehlerseiten werden als URLs angezeigt. Diese URLs können mit einem Schrägstrich (/) für lokale Webpfade (relativ zum DocumentRoot) beginnen oder eine vollständige URL sein, die der Client auflösen kann.
+Die Fehlerseiten werden als URLs präsentiert. Diese URLs können mit einem Schrägstrich (/) für lokale Webpfade (relativ zum DocumentRoot) beginnen oder eine vollständige URL sein, die der Client auflösen kann.
 
-Weitere Informationen finden Sie in der [Direktive ErrorDocument](https://httpd.apache.org/docs/current/mod/core.html#errordocument) in der HTTPD-Dokumentation.
+Siehe die [ErrorDocument-Direktive](https://httpd.apache.org/docs/current/mod/core.html#errordocument) Dokumentation auf der HTTPD-Dokumentationsseite für mehr Informationen.
 
 ```apacheconf
 ErrorDocument 500 /errors/500.html
@@ -136,11 +136,11 @@ ErrorDocument 403 "Sorry, can't allow you access today."
 
 ## Fehlervermeidung
 
-Diese Einstellung beeinflusst, wie MultiViews für das Verzeichnis funktionieren, für das die Konfiguration gilt.
+Diese Einstellung beeinflusst, wie MultiViews für das Verzeichnis arbeiten, auf das die Konfiguration angewendet wird.
 
-Die Wirkung von `MultiViews` ist wie folgt: Wenn der Server eine Anfrage für /some/dir/foo erhält, wenn /some/dir `MultiViews` aktiviert hat und /some/dir/foo nicht existiert, liest der Server das Verzeichnis nach Dateien mit dem Namen foo.\* durchsucht und effektiv eine Typzuordnung erstellt, die alle diese Dateien benennt und ihnen dieselben Medientypen und Inhaltskodierungen zuweist, die sie hätte, wenn der Client nach einer davon namentlich gefragt hätte. Dann wählt er die beste Übereinstimmung mit den Anforderungen des Clients aus.
+Die Wirkung von `MultiViews` ist wie folgt: Wenn der Server eine Anfrage für /some/dir/foo erhält, wenn /some/dir `MultiViews` aktiviert hat und /some/dir/foo nicht existiert, liest der Server das Verzeichnis, um nach Dateien namens foo.\* zu suchen, und simuliert effektiv eine Typenkarte, die alle diese Dateien benennt, und ordnet ihnen die gleichen Medientypen und Inhaltskodierungen zu, die es hätte, wenn der Client eine von ihnen namentlich angefordert hätte. Es wählt dann die beste Übereinstimmung mit den Anforderungen des Clients.
 
-Die Einstellung deaktiviert `MultiViews` für das Verzeichnis, auf das diese Konfiguration angewendet wird, und verhindert, dass Apache einen 404-Fehler als Ergebnis einer Umschreibung zurückgibt, wenn das Verzeichnis mit demselben Namen nicht existiert.
+Die Einstellung deaktiviert `MultiViews` für das Verzeichnis, auf das diese Konfiguration angewendet wird, und verhindert, dass Apache als Ergebnis einer Umschreibung einen 404-Fehler zurückgibt, wenn das Verzeichnis mit demselben Namen nicht existiert.
 
 ```apacheconf
 Options -MultiViews
@@ -148,15 +148,15 @@ Options -MultiViews
 
 ## Medientypen und Zeichenkodierungen
 
-Apache verwendet [mod_mime](https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype), um Inhalts-Metadaten des Inhalts zuzuweisen, der für eine HTTP-Antwort ausgewählt wurde, indem Muster in der URI oder Dateinamen auf die Metadatenwerte gemappt werden.
+Apache verwendet [mod_mime](https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype), um Inhalts-Metadaten den ausgewählten Inhalten für eine HTTP-Antwort zuzuweisen, indem Muster in der URI oder Dateinamen den Metadatenwerten zugeordnet werden.
 
-Zum Beispiel definieren die Dateierweiterungen von Inhaltsdateien häufig den Internet-Medientyp, die Sprache, die Zeichencodierung und die Inhaltskodierung des Inhalts. Diese Informationen werden in HTTP-Nachrichten gesendet, die diesen Inhalt enthalten, und in der Inhaltsverhandlung verwendet, um Alternativen auszuwählen, sodass die Präferenzen des Benutzers berücksichtigt werden, wenn einer von mehreren möglichen Inhalten ausgewählt werden soll.
+Zum Beispiel definieren die Dateinamenerweiterungen von Inhaltsdateien oft den Internet-Medientyp, die Sprache, den Zeichensatz und die Inhaltskodierung des Inhalts. Diese Informationen werden in HTTP-Nachrichten gesendet, die diesen Inhalt enthalten, und in der Inhaltsverhandlung verwendet, wenn Alternativen ausgewählt werden, sodass die Präferenzen des Benutzers respektiert werden, wenn eine von mehreren möglichen Inhalten bereitgestellt wird.
 
-**Änderungen der Metadaten für eine Datei ändern nicht den Wert des Last-Modified-Headers. Daher können zuvor zwischengespeicherte Kopien möglicherweise immer noch von einem Client oder Proxy verwendet werden, mit den vorherigen Headern. Wenn Sie die Metadaten ändern (Sprache, Inhaltstyp, Zeichensatz oder Kodierung), müssen Sie die betroffenen Dateien möglicherweise "anfassen" (Änderung des letzten Änderungsdatums), um sicherzustellen, dass alle Besucher die korrigierten Inhalts-Header erhalten.**
+**Das Ändern der Metadaten einer Datei ändert nicht den Wert des Last-Modified-Headers. Somit können bereits zwischengespeicherte Kopien weiterhin von einem Client oder Proxy verwendet werden, mit den vorherigen Headern. Wenn Sie die Metadaten (Sprache, Inhaltstyp, Zeichensatz oder Kodierung) ändern, müssen Sie eventuell die betroffenen Dateien 'berühren' (das Änderungsdatum aktualisieren), um sicherzustellen, dass alle Besucher die korrigierten Inhaltsheader erhalten.**
 
-### Ressourcen mit den richtigen Medientypen (auch bekannt als MIME-Typen) bereitstellen
+### Ressourcen mit den richtigen Medientypen bereitstellen (auch bekannt als MIME-Typen)
 
-Weist Medientypen einem oder mehreren Erweiterungen zu, um sicherzustellen, dass die Ressourcen ordnungsgemäß bereitgestellt werden.
+Ordnet Medientypen einem oder mehreren Erweiterungen zu, um sicherzustellen, dass die Ressourcen angemessen bereitgestellt werden.
 
 Server sollten `text/javascript` für JavaScript-Ressourcen verwenden, wie in der [HTML-Spezifikation](https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages) angegeben.
 
@@ -220,11 +220,11 @@ Server sollten `text/javascript` für JavaScript-Ressourcen verwenden, wie in de
 </IfModule>
 ```
 
-## Setzen Sie das Standard-Zeichensatzattribut
+## Das Standard-Zeichensatzattribut festlegen
 
-Jedes Stück Inhalt im Web hat einen Zeichensatz. Die meisten, wenn nicht alle, Inhalte sind UTF-8 Unicode.
+Jedes Content-Stück im Web hat einen Zeichensatz. Die meisten, wenn nicht alle, Inhalte sind UTF-8 Unicode.
 
-Verwenden Sie [AddDefaultCharset](https://httpd.apache.org/docs/current/mod/core.html#adddefaultcharset), um alle als `text/html` oder `text/plain` gekennzeichneten Ressourcen mit dem `UTF-8`-Charset zu bedienen.
+Verwenden Sie [AddDefaultCharset](https://httpd.apache.org/docs/current/mod/core.html#adddefaultcharset), um alle als `text/html` oder `text/plain` beschrifteten Ressourcen mit dem Zeichensatz `UTF-8` bereitzustellen.
 
 ```apacheconf
 <IfModule mod_mime.c>
@@ -232,9 +232,9 @@ Verwenden Sie [AddDefaultCharset](https://httpd.apache.org/docs/current/mod/core
 </IfModule>
 ```
 
-## Setzen Sie das Charset für bestimmte Medientypen
+## Zeichensatz für bestimmte Medientypen festlegen
 
-Dienen Sie die folgenden Dateitypen mit dem `charset` Parameter, der auf `UTF-8` gesetzt ist, unter Verwendung der [AddCharset](https://httpd.apache.org/docs/current/mod/mod_mime.html#addcharset) Direktive, die in `mod_mime` verfügbar ist.
+Dienen Sie die folgenden Dateitypen mit dem `charset`-Parameter auf `UTF-8` gesetzt, indem Sie die [AddCharset](https://httpd.apache.org/docs/current/mod/mod_mime.html#addcharset) Direktive verwenden, die in `mod_mime` verfügbar ist.
 
 ```apacheconf
 <IfModule mod_mime.c>
@@ -259,25 +259,25 @@ Dienen Sie die folgenden Dateitypen mit dem `charset` Parameter, der auf `UTF-8`
 </IfModule>
 ```
 
-## `Mod_rewrite` und die `RewriteEngine` Direktiven
+## `Mod_rewrite` und die `RewriteEngine` direktiven
 
-[mod_rewrite](https://httpd.apache.org/docs/current/mod/mod_rewrite.html) bietet eine Möglichkeit, eingehende URL-Anfragen dynamisch basierend auf regulären Ausdrucksregeln zu modifizieren. Dies ermöglicht es Ihnen, beliebige URLs auf Ihre interne URL-Struktur in beliebiger Weise abzubilden.
+[mod_rewrite](https://httpd.apache.org/docs/current/mod/mod_rewrite.html) bietet eine Möglichkeit, eingehende URL-Anfragen dynamisch aufgrund von regulären Ausdrucksregeln zu ändern. Dies ermöglicht es Ihnen, beliebige URLs auf Ihre interne URL-Struktur in jeder gewünschten Weise abzubilden.
 
-Es unterstützt eine unbegrenzte Anzahl von Regeln und eine unbegrenzte Anzahl an angehängten Regelbedingungen für jede Regel, um einen wirklich flexiblen und leistungsfähigen URL-Manipulationsmechanismus bereitzustellen. Die URL-Manipulationen können von verschiedenen Tests abhängen: Servervariablen, Umweltvariablen, HTTP-Header, Zeitstempel, externe Datenbankabfragen und verschiedene andere externe Programme oder Handler können verwendet werden, um eine detaillierte URL-Match-Funktion zu erreichen.
+Es unterstützt eine unbegrenzte Anzahl von Regeln und eine unbegrenzte Anzahl von angehängten Regelbedingungen für jede Regel, um einen wirklich flexiblen und leistungsstarken URL-Manipulationsmechanismus bereitzustellen. Die URL-Manipulationen können von verschiedenen Tests abhängen: Servervariablen, Umgebungsvariablen, HTTP-Header, Zeitstempel, externe Datenbankabfragen und verschiedene andere externe Programme oder Handler können verwendet werden, um eine granulare URL-Übereinstimmung zu erreichen.
 
-### Aktivierung von `mod_rewrite`
+### `mod_rewrite` aktivieren
 
-Das Grundmuster, um `mod_rewrite` zu aktivieren, ist eine Voraussetzung für alle anderen Aufgaben, die es verwenden.
+Das Grundmuster zum Aktivieren von `mod_rewrite` ist eine Voraussetzung für alle anderen Aufgaben, die es verwenden.
 
 Die erforderlichen Schritte sind:
 
-1. Schalten Sie die Rewrite-Engine ein (dies ist notwendig, damit die `RewriteRule`-Direktiven funktionieren), wie in der [RewriteEngine](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#RewriteEngine) Dokumentation beschrieben
-2. Aktivieren Sie die Option `FollowSymLinks`, wenn sie nicht bereits aktiviert ist. Siehe [Core Options](https://httpd.apache.org/docs/current/mod/core.html#options) Dokumentation
-3. Wenn Ihr Webhost die Option `FollowSymlinks` nicht zulässt, müssen Sie sie auskommentieren oder entfernen und anschließend die Zeile `Options +SymLinksIfOwnerMatch` auskommentieren, aber beachten Sie die [Auswirkungen auf die Leistung](https://httpd.apache.org/docs/current/misc/perf-tuning.html#symlinks)
+1. Schalten Sie die Umschreibemaschine ein (dies ist notwendig, damit die `RewriteRule`-Direktiven funktionieren), wie in der [RewriteEngine](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#RewriteEngine) Dokumentation beschrieben.
+2. Aktivieren Sie die Option `FollowSymLinks`, falls sie nicht bereits aktiviert ist. Siehe [Kernoptionen](https://httpd.apache.org/docs/current/mod/core.html#options) Dokumentation.
+3. Wenn Ihr Webhost die Option `FollowSymLinks` nicht erlaubt, müssen Sie sie auskommentieren oder entfernen und dann die Zeile `Options +SymLinksIfOwnerMatch` auskommentieren, aber seien Sie sich der [Leistungsbeeinträchtigung](https://httpd.apache.org/docs/current/misc/perf-tuning.html#symlinks) bewusst.
 
-   - Einige Cloud-Hosting-Dienste erfordern, dass Sie `RewriteBase` festlegen
-   - Siehe [Rackspace FAQ](https://web.archive.org/web/20151223141222/http://www.rackspace.com/knowledge_center/frequently-asked-question/why-is-modrewrite-not-working-on-my-site) und die [HTTPD-Dokumentation](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase)
-   - Je nach Ihrer Serverkonfiguration müssen Sie möglicherweise auch die [`RewriteOptions`](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteoptions) Direktive verwenden, um einige Optionen für die Rewrite-Engine zu aktivieren
+   - Einige Cloud-Hosting-Dienste erfordern, dass Sie `RewriteBase` setzen.
+   - Siehe [Rackspace-FAQ](https://web.archive.org/web/20151223141222/http://www.rackspace.com/knowledge_center/frequently-asked-question/why-is-modrewrite-not-working-on-my-site) und die [HTTPD-Dokumentation](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase).
+   - Abhängig von der Konfiguration Ihres Servers müssen Sie möglicherweise die [`RewriteOptions`](https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteoptions) Direktive verwenden, um einige Optionen für die Umschreibemaschine zu aktivieren.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -289,9 +289,9 @@ Die erforderlichen Schritte sind:
 </IfModule>
 ```
 
-### Erzwingen von HTTPS
+### Erzwungene HTTPS-Verbindungen
 
-Diese Rewrite-Regeln leiten von der unsicheren Version `http://` zur sicheren Version `https://` der URL wie im [Apache HTTPD Wiki](https://cwiki.apache.org/confluence/display/httpd/RewriteHTTPToHTTPS) beschrieben weiter.
+Diese Umschreiberegeln leiten von der `http://` unsicheren Version zur `https://` sicheren Version der URL um, wie im [Apache HTTPD-Wiki](https://cwiki.apache.org/confluence/display/httpd/RewriteHTTPToHTTPS) beschrieben.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -301,7 +301,7 @@ Diese Rewrite-Regeln leiten von der unsicheren Version `http://` zur sicheren Ve
 </IfModule>
 ```
 
-Wenn Sie cPanel AutoSSL oder die Let's Encrypt webroot-Methode verwenden, um Ihre TLS-Zertifikate zu erstellen, schlägt die Zertifikatsvalidierung fehl, wenn Validierungsanfragen zu HTTPS umgeleitet werden. Aktivieren Sie die Bedingungen, die Sie benötigen.
+Wenn Sie cPanel AutoSSL oder die Let's Encrypt-Webroot-Methode zur Erstellung Ihrer TLS-Zertifikate verwenden, wird die Zertifikatsvalidierung fehlschlagen, wenn Validierungsanfragen auf HTTPS umgeleitet werden. Schalten Sie die benötigte(n) Bedingung(en) ein.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -316,11 +316,11 @@ Wenn Sie cPanel AutoSSL oder die Let's Encrypt webroot-Methode verwenden, um Ihr
 
 ### Umleitung von `www.` URLs
 
-Diese Direktiven ermöglichen es, `www.example.com` in `example.com` umzuschreiben.
+Diese Direktiven werden `www.example.com` auf `example.com` umschreiben.
 
-Sie sollten keine Inhalte an mehreren Ursprüngen (mit und ohne www) duplizieren. Dies kann zu SEO-Problemen (doppelter Inhalt) führen, und daher sollten Sie eine der Alternativen wählen und die andere umleiten. Sie sollten auch [kanonische URLs](https://www.semrush.com/blog/canonical-url-guide/) verwenden, um anzugeben, welche URL Suchmaschinen crawlen sollten (wenn sie die Funktion unterstützen).
+Sie sollten Inhalte nicht auf mehreren Ursprüngen (mit und ohne www) duplizieren. Dies kann SEO-Probleme (doppelte Inhalte) verursachen, und daher sollten Sie eine der Alternativen wählen und die andere umleiten. Sie sollten auch [kanonische URLs](https://www.semrush.com/blog/canonical-url-guide/) verwenden, um anzugeben, welche URL Suchmaschinen crawlen sollen (wenn sie die Funktion unterstützen).
 
-Setzen Sie die `%{ENV:PROTO}`-Variable, um Umleitungen automatisch mit dem entsprechenden Schema (`http` oder `https`) durchzuführen.
+Setzen Sie die `%{ENV:PROTO}` Variable, um Umschreibungen automatisch mit dem entsprechenden Schema (`http` oder `https`) umzuleiten.
 
 Die Regel geht standardmäßig davon aus, dass sowohl HTTP- als auch HTTPS-Umgebungen für die Umleitung verfügbar sind.
 
@@ -337,17 +337,17 @@ Die Regel geht standardmäßig davon aus, dass sowohl HTTP- als auch HTTPS-Umgeb
 </IfModule>
 ```
 
-### Hinzufügen von `www.` am Anfang von URLs
+### Einfügen von `www.` am Anfang von URLs
 
-Diese Regeln fügen `www.` am Anfang einer URL hinzu. Es ist wichtig zu beachten, dass Sie niemals denselben Inhalt unter zwei verschiedenen URLs verfügbar machen sollten.
+Diese Regeln werden `www.` am Anfang einer URL einfügen. Es ist wichtig, zu beachten, dass Sie niemals denselben Inhalt unter zwei verschiedenen URLs verfügbar machen sollten.
 
-Dies kann zu SEO-Problemen (doppelter Inhalt) führen, und daher sollten Sie eine der Alternativen wählen und die andere umleiten. Für Suchmaschinen, die dies unterstützen, sollten Sie [kanonische URLs](https://www.semrush.com/blog/canonical-url-guide/) verwenden, um anzugeben, welche URL Suchmaschinen crawlen sollen.
+Dies kann SEO-Probleme (doppelte Inhalte) verursachen, und daher sollten Sie eine der Alternativen wählen und die andere umleiten. Für Suchmaschinen, die sie unterstützen, sollten Sie [kanonische URLs](https://www.semrush.com/blog/canonical-url-guide/) verwenden, um anzugeben, welche URL Suchmaschinen crawlen sollen.
 
-Setzen Sie die `%{ENV:PROTO}`-Variable, um Umleitungen automatisch mit dem entsprechenden Schema (`http` oder `https`) durchzuführen.
+Setzen Sie die `%{ENV:PROTO}` Variable, um Umschreibungen automatisch mit dem entsprechenden Schema (`http` oder `https`) umzuleiten.
 
-Die Regel geht standardmäßig davon aus, dass sowohl HTTP- als auch HTTPS-Umgebungen für die Umleitung verfügbar sind. Wenn Ihr TLS-Zertifikat keine der während der Umleitung verwendeten Domains handhaben kann, sollten Sie die Bedingung aktivieren.
+Die Regel geht standardmäßig davon aus, dass sowohl HTTP- als auch HTTPS-Umgebungen für die Umleitung verfügbar sind. Wenn Ihr TLS-Zertifikat einen der während der Umleitung verwendeten Domains nicht verarbeiten kann, sollten Sie die Bedingung einschalten.
 
-Das Folgende könnte keine gute Idee sein, wenn Sie "echte" Subdomains für bestimmte Teile Ihrer Website verwenden.
+Das Folgende ist möglicherweise keine gute Idee, wenn Sie "echte" Subdomains für bestimmte Teile Ihrer Website verwenden.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -368,13 +368,13 @@ Das Folgende könnte keine gute Idee sein, wenn Sie "echte" Subdomains für best
 
 ## Frame-Optionen
 
-Das folgende Beispiel sendet den `X-Frame-Options` Antwort-Header mit dem Wert DENY und informiert Browser darüber, den Inhalt der Webseite in keinem Frame anzuzeigen, um die Webseite vor {{Glossary("Clickjacking", "Clickjacking")}} zu schützen.
+Das folgende Beispiel sendet den `X-Frame-Options` Antwort-Header mit DENY als Wert und informiert Browser darüber, den Inhalt der Webseite in keinem Frame anzuzeigen, um die Website gegen [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) zu schützen.
 
-Dies könnte nicht die beste Einstellung für jeden sein. Sie sollten sich über [die anderen beiden möglichen Werte für den `X-Frame-Options`-Header](https://datatracker.ietf.org/doc/html/rfc7034#section-2.1) informieren: `SAMEORIGIN` und `ALLOW-FROM`.
+Dies ist möglicherweise nicht die beste Einstellung für jeden. Sie sollten über [die anderen beiden möglichen Werte für den `X-Frame-Options`-Header](https://datatracker.ietf.org/doc/html/rfc7034#section-2.1): `SAMEORIGIN` und `ALLOW-FROM` lesen.
 
-Obwohl Sie den `X-Frame-Options`-Header für alle Seiten Ihrer Webseite senden könnten, hat dies den potenziellen Nachteil, dass selbst das Einrahmen Ihres Inhalts verboten wird (z.B.: wenn Benutzer Ihre Website über eine Google Bildersuche besuchen).
+Während Sie den `X-Frame-Options`-Header für alle Seiten Ihrer Website senden könnten, hat dies den potenziellen Nachteil, dass selbst keine Rahmung Ihres Inhalts erlaubt ist (z. B. wenn Benutzer Ihre Website über eine Google-Bildersuchergebnisseite besuchen).
 
-Trotzdem sollten Sie sicherstellen, dass Sie den `X-Frame-Options`-Header für alle Seiten senden, die einem Benutzer erlauben, einen zustandsändernden Vorgang durchzuführen (z.B. Seiten, die Ein-Klick-Kaufschaltflächen, Checkout- oder Banküberweisungsbestätigungsseiten enthalten, Seiten, die dauerhafte Konfigurationsänderungen vornehmen, usw.).
+Nichtsdestotrotz sollten Sie sicherstellen, dass Sie den `X-Frame-Options`-Header für alle Seiten senden, die es einem Benutzer ermöglichen, eine statusverändernde Operation durchzuführen (z. B. Seiten, die Ein-Klick-Kauf-Links, Checkout- oder Banküberweisungsbestätigungsseiten enthalten, Seiten, die dauerhafte Konfigurationsänderungen vornehmen, usw.).
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -384,11 +384,11 @@ Trotzdem sollten Sie sicherstellen, dass Sie den `X-Frame-Options`-Header für a
 
 ## Content Security Policy (CSP)
 
-[CSP (Content Security Policy)](https://content-security-policy.com/) reduziert das Risiko von Cross-Site-Scripting und anderen Content-Injection-Angriffen, indem eine `Content Security Policy` gesetzt wird, die vertrauenswürdige Quellen von Inhalten für Ihre Website erlaubt.
+[CSP (Content Security Policy)](https://content-security-policy.com/) mindert das Risiko von Cross-Site-Scripting und anderen Content-Injection-Angriffen, indem eine `Content Security Policy` festgelegt wird, die vertrauenswürdige Quellen von Inhalten für Ihre Website zulässt.
 
-Es gibt keine Politik, die für alle Webseiten geeignet ist, das folgende Beispiel ist als Leitlinien gedacht, die Sie für Ihre Webseite anpassen können.
+Es gibt keine Policy, die für alle Websites passt, das folgende Beispiel ist als Richtlinie gedacht, die Sie für Ihre Website anpassen können.
 
-Um Ihre CSP-Implementierung zu erleichtern, können Sie einen Online-[CSP-Header-Generator](https://report-uri.com/home/generate/) verwenden. Sie sollten auch einen [Validator](https://csp-evaluator.withgoogle.com/) benutzen, um sicherzustellen, dass Ihr Header das tut, was Sie beabsichtigen.
+Um Ihre CSP-Implementierung zu erleichtern, können Sie einen Online [CSP-Header-Generator](https://report-uri.com/home/generate/) verwenden. Sie sollten auch einen [Validator](https://csp-evaluator.withgoogle.com/) verwenden, um sicherzustellen, dass Ihr Header das tut, was Sie möchten.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -398,7 +398,7 @@ Um Ihre CSP-Implementierung zu erleichtern, können Sie einen Online-[CSP-Header
 
 ## Verzeichniszugriff
 
-Diese Direktive verhindert den Zugriff auf Verzeichnisse, die keine Indexdatei in dem vom Server konfigurierten Format enthalten, wie z.B. `index.html` oder `index.php`.
+Diese Direktive verhindert den Zugriff auf Verzeichnisse, die keine Indexdatei in welchem Format auch immer der Server konfiguriert ist, wie `index.html` oder `index.php`, enthalten.
 
 ```apacheconf
 <IfModule mod_autoindex.c>
@@ -408,9 +408,9 @@ Diese Direktive verhindert den Zugriff auf Verzeichnisse, die keine Indexdatei i
 
 ## Zugriff auf versteckte Dateien und Verzeichnisse blockieren
 
-In Macintosh- und Linux-Systemen sind Dateien, die mit einem Punkt beginnen, vor der Ansicht verborgen, jedoch nicht vor dem Zugriff, wenn Sie ihren Namen und Standort kennen. Diese Arten von Dateien enthalten normalerweise Benutzereinstellungen oder den gespeicherten Zustand eines Dienstprogramms und können sehr private Orte wie zum Beispiel die `.git` oder `.svn` Verzeichnisse umfassen.
+In Macintosh- und Linux-Systemen sind Dateien, die mit einem Punkt beginnen, von der Ansicht versteckt, aber nicht vom Zugriff, wenn Sie deren Namen und Standort kennen. Diese Arten von Dateien enthalten normalerweise Benutzereinstellungen oder den reservierten Zustand eines Dienstprogramms und können ziemlich private Orte wie zum Beispiel die `.git` oder `.svn` Verzeichnisse enthalten.
 
-Das `.well-known/` Verzeichnis entspricht [dem Standard (RFC 5785)](https://datatracker.ietf.org/doc/html/rfc5785) für "wohlbekannte Orte" (z.B.: `/.well-known/manifest.json`, `/.well-known/keybase.txt`), und daher sollte der Zugriff auf seinen sichtbaren Inhalt nicht blockiert werden.
+Das `.well-known/` Verzeichnis repräsentiert [den Standard (RFC 5785)](https://datatracker.ietf.org/doc/html/rfc5785) Pfad-Präfix für "bekannte Orte" (z. B.: `/.well-known/manifest.json`, `/.well-known/keybase.txt`), daher sollte der Zugang zu seinem sichtbaren Inhalt nicht blockiert werden.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -424,9 +424,9 @@ Das `.well-known/` Verzeichnis entspricht [dem Standard (RFC 5785)](https://data
 
 ## Zugriff auf Dateien mit sensiblen Informationen blockieren
 
-Verhindern Sie den Zugriff auf Backup- und Quelldateien, die von einigen Texteditoren hinterlassen werden können und ein Sicherheitsrisiko darstellen, wenn jeder darauf zugreifen kann.
+Blockierzugang zu Backup- und Quelldateien, die von einigen Texteditoren hinterlassen werden können und ein Sicherheitsrisiko darstellen, wenn jemand Zugang zu ihnen hat.
 
-Aktualisieren Sie das reguläre Ausdrucksmuster `<FilesMatch>` im folgenden Beispiel, um alle Dateien einzuschließen, die möglicherweise auf Ihrem Produktionsserver enden und sensible Informationen über Ihre Webseite preisgeben können. Diese Dateien können Konfigurationsdateien oder Dateien enthalten, die Metadaten über das Projekt enthalten, unter anderem.
+Aktualisieren Sie den `<FilesMatch>` regulären Ausdruck im folgenden Beispiel, um alle Dateien einzuschließen, die möglicherweise auf Ihrem Produktionsserver landen und sensible Informationen über Ihre Website preisgeben können. Diese Dateien können Konfigurationsdateien oder Dateien sein, die Metadaten über das Projekt enthalten, unter anderem.
 
 ```apacheconf
 <IfModule mod_authz_core.c>
@@ -438,11 +438,11 @@ Aktualisieren Sie das reguläre Ausdrucksmuster `<FilesMatch>` im folgenden Beis
 
 ## HTTP Strict Transport Security (HSTS)
 
-Wenn ein Benutzer `example.com` in seinen Browser eingibt, auch wenn der Server ihn zur sicheren Version der Webseite umleitet, bleibt dennoch ein Zeitfenster für einen Angreifer, um die Anfrage herabzustufen oder umzuleiten (die anfängliche HTTP-Verbindung).
+Wenn ein Benutzer `example.com` in seinen Browser eingibt, selbst wenn der Server ihn auf die sichere Version der Website umleitet, bleibt dennoch ein Fenster der Gelegenheit (die anfängliche HTTP-Verbindung), das ein Angreifer nutzen könnte, um die Anforderung herabzustufen oder umzulenken.
 
-Der folgende Header stellt sicher, dass ein Browser nur über HTTPS zu Ihrem Server verbindet, unabhängig davon, was die Benutzer in die Adressleiste des Browsers eingeben.
+Der folgende Header stellt sicher, dass ein Browser nur über HTTPS mit Ihrem Server verbindet, unabhängig davon, was die Benutzer in die Adressleiste des Browsers eingeben.
 
-Seien Sie sich bewusst, dass strikte Transport-Sicherheit nicht widerrufbar ist und dass Sie sicherstellen müssen, dass die Website über HTTPS so lange bedient werden kann, wie Sie es in der `max-age`-Direktive angegeben haben. Wenn Sie keine gültige TLS-Verbindung mehr haben (z.B. durch ein abgelaufenes TLS-Zertifikat), sehen Ihre Besucher eine Fehlermeldung, selbst wenn sie versuchen, über HTTP zu verbinden.
+Seien Sie sich bewusst, dass Strict Transport Security nicht widerrufbar ist, und Sie müssen sicherstellen, dass Sie die Seite so lange über HTTPS anbieten können, wie Sie es im `max-age` Directive angegeben haben. Wenn Sie keine gültige TLS-Verbindung mehr haben (z. B. aufgrund eines abgelaufenen TLS-Zertifikats), sehen Ihre Besucher eine Fehlermeldung, selbst wenn versucht wird, über HTTP zu verbinden.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -454,30 +454,30 @@ Seien Sie sich bewusst, dass strikte Transport-Sicherheit nicht widerrufbar ist
 </IfModule>
 ```
 
-## Verhindern Sie, dass einige Browser die Antwort MIME-abharschen
+## Verhindern, dass einige Browser den MIME-Typ der Antwort raten
 
-1. Beschränkt standardmäßig alle Abrufe auf den Ursprung der aktuellen Webseite, indem der `default-src`-Directive auf `'self'` gesetzt wird, was als Fallback für alle {{Glossary("Fetch_directive", "Fetch-Direktiven")}} fungiert.
+1. Beschränkt alle Abrufe standardmäßig auf den Ursprung der aktuellen Website, indem die `default-src` Direktive auf `'self'` gesetzt wird - was als Fallback für alle {{Glossary("Fetch_directive", "Fetch-Direktiven")}} fungiert.
 
-   - Dies ist praktisch, da Sie nicht alle Fetch-Direktiven angeben müssen, die für Ihre Seite gelten, zum Beispiel: `connect-src 'self'; font-src 'self'; script-src 'self'; style-src 'self'`, usw.
-   - Diese Einschränkung bedeutet auch, dass Sie explizit definieren müssen, von welchen Seiten Ihre Webseite Ressourcen laden darf. Andernfalls wird es auf den gleichen Ursprung wie die Seite beschränkt, die die Anfrage stellt.
+   - Dies ist praktisch, da Sie nicht alle Fetch-Direktiven angeben müssen, die für Ihre Website gelten, zum Beispiel: `connect-src 'self'; font-src 'self'; script-src 'self'; style-src 'self';` usw.
+   - Diese Einschränkung bedeutet auch, dass Sie explizit festlegen müssen, von welcher(n) Seite(n) Ihre Website Ressourcen laden darf. Andernfalls wird es auf denselben Ursprung wie die Seite beschränkt, die die Anforderung macht.
 
-2. Verbietet das `<base>`-Element auf der Webseite. Dies soll verhindern, dass Angreifer die Standorte von Ressourcen ändern, die von relativen URLs geladen werden.
+2. Verbot des `<base>`-Elements auf der Website. Dies ist, um zu verhindern, dass Angreifer die Standorte von Ressourcen ändern, die von relativen URLs geladen werden.
 
-   - Falls Sie das `<base>`-Element verwenden möchten, verwenden Sie stattdessen `base-uri 'self'`.
+   - Wenn Sie das `<base>`-Element verwenden möchten, dann verwenden Sie `base-uri 'self'` stattdessen.
 
-3. Erlaubt nur Formulareinreichungen von dem aktuellen Ursprung mit: `form-action 'self'`.
-4. Verhindert, dass alle Webseiten (einschließlich Ihrer eigenen) Ihre Seiten innerhalb z.B. des `<iframe>` oder `<object>`-Elements einbetten, indem der `frame-ancestors 'none'`-Direktive gesetzt wird.
+3. Erlaubt Formulareinsendungen nur vom aktuellen Ursprung mit: `form-action 'self'`.
+4. Verhindert, dass alle Websites (einschließlich Ihrer eigenen) Ihre Webseiten innerhalb von z.B. dem `<iframe>` oder `<object>` Element einbetten, indem `frame-ancestors 'none'` gesetzt wird.
 
-   - Die Direktive `frame-ancestors` hilft Klickjacking-Angriffe zu vermeiden und ähnelt dem `X-Frame-Options`-Header.
+   - Die `frame-ancestors` Direktive hilft, [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) Angriffe zu vermeiden und ähnelt dem `X-Frame-Options` Header.
    - Browser, die den CSP-Header unterstützen, ignorieren `X-Frame-Options`, wenn `frame-ancestors` ebenfalls spezifiziert ist.
 
-5. Erzwingt, dass der Browser alle Ressourcen, die über HTTP bereitgestellt werden, so behandelt, als wären sie sicher über HTTPS geladen, indem die `upgrade-insecure-requests`-Direktive gesetzt wird.
+5. Zwingt den Browser, alle Ressourcen, die über HTTP bereitgestellt werden, so zu behandeln, als ob sie sicher über HTTPS geladen wurden, indem die `upgrade-insecure-requests` Direktive gesetzt wird.
 
-   - **`upgrade-insecure-requests` stellt keine HTTPS-Verbindung für die Top-Level-Navigation sicher. Wenn Sie erzwingen möchten, dass die Webseite selbst über HTTPS geladen wird, müssen Sie den `Strict-Transport-Security`-Header einfügen.**
+   - **`upgrade-insecure-requests` stellt nicht sicher, dass die Website selbst über HTTPS geladen wird. Wenn Sie die Website zwingen möchten, über HTTPS geladen zu werden, müssen Sie den `Strict-Transport-Security` Header einschließen.**
 
-6. Enthält den `Content-Security-Policy`-Header in allen Antworten, die Skripting ausführen können. Dazu gehören die häufig verwendeten Dateitypen: HTML, XML und PDF-Dokumente. Obwohl JavaScript-Dateien in einem "Browsing-Kontext" keine Skripte ausführen können, sind sie enthalten, um [Webarbeiter](/de/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workers) anzusprechen.
+6. Beinhaltet den `Content-Security-Policy` Header in allen Antworten, die in der Lage sind, Skripte auszuführen. Dies schließt die häufig verwendeten Dateitypen ein: HTML, XML und PDF-Dokumente. Obwohl JavaScript-Dateien keine Skripte in einem "Browsing-Kontext" ausführen können, sind sie eingeschlossen, um [Web-Arbeiter](/de/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workers) anzuzielen.
 
-Einige ältere Browser versuchten, den Inhaltstyp einer Ressource zu erraten, auch wenn er nicht ordnungsgemäß in der Serverkonfiguration festgelegt war. Dies verringert die Anfälligkeit für Drive-by-Download-Angriffe und Cross-Origin-Datenlecks.
+Einige ältere Browser würden versuchen, den Inhaltstyp einer Ressource zu erraten, selbst wenn er nicht richtig auf der Serverkonfiguration eingerichtet ist. Dies reduziert die Gefährdung durch Drive-By-Download-Angriffe und Cross-Origin-Daten-Lecks.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -485,15 +485,15 @@ Einige ältere Browser versuchten, den Inhaltstyp einer Ressource zu erraten, au
 </IfModule>
 ```
 
-## Referrer-Richtlinie
+## Referrer-Policy
 
-Wir fügen den `Referrer-Policy`-Header in Antworten für Ressourcen ein, die andere Ressourcen anfordern (oder darauf zugreifen) können.
+Wir schließen den `Referrer-Policy` Header in Antworten für Ressourcen ein, die in der Lage sind, (oder zu) anderen Ressourcen anzufordern (oder zu navigieren).
 
-Dazu gehören die häufig genutzten Ressourcentypen: HTML, CSS, XML/SVG, PDF-Dokumente, Skripte und Arbeiter.
+Dies schließt häufig verwendete Ressourcentypen ein: HTML, CSS, XML/SVG, PDF-Dokumente, Skripte und Arbeiter.
 
-Um die Referrer-Leckage vollständig zu verhindern, geben Sie den Wert `no-referrer` an. Beachten Sie, dass dies sich negativ auf Analysetools auswirken könnte.
+Um das Referrer-Leck vollständig zu verhindern, geben Sie den `no-referrer` Wert an. Beachten Sie, dass der Effekt sich negativ auf Analysetools auswirken könnte.
 
-Verwenden Sie Dienste wie die unten aufgeführten, um Ihre `Referrer-Policy` zu überprüfen:
+Verwenden Sie Dienste wie die unten stehenden, um Ihre `Referrer-Policy` zu überprüfen:
 
 - [HTTP Observatory](/en-US/observatory)
 - [securityheaders.com](https://securityheaders.com/)
@@ -506,11 +506,11 @@ Verwenden Sie Dienste wie die unten aufgeführten, um Ihre `Referrer-Policy` zu
 
 ## Deaktivieren der `TRACE` HTTP-Methode
 
-Die [TRACE](/de/docs/Web/HTTP/Methods/TRACE) Methode kann in einigen Szenarien erfolgreich genutzt werden, um legitime Benutzerdaten zu stehlen. Siehe [Einen Cross-Site Tracing (XST) Angriff](https://owasp.org/www-community/attacks/Cross_Site_Tracing) und [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods#test-xst-potential)
+Die [TRACE](/de/docs/Web/HTTP/Methods/TRACE) Methode, obwohl scheinbar harmlos, kann in einigen Szenarien erfolgreich genutzt werden, um die Anmeldeinformationen legitimer Benutzer zu stehlen. Siehe [Ein Cross-Site Tracing (XST) Angriff](https://owasp.org/www-community/attacks/Cross_Site_Tracing) und [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods#test-xst-potential).
 
-Moderne Browser verhindern jetzt TRACE-Anfragen, die über JavaScript gestellt werden, jedoch wurden andere Wege entdeckt, TRACE-Anfragen mit Browsern zu senden, z.B. unter Verwendung von Java.
+Moderne Browser verhindern jetzt TRACE-Anfragen über JavaScript, jedoch wurden andere Möglichkeiten entdeckt, TRACE-Anfragen mit Browsern zu senden, z.B. mit Java.
 
-Wenn Sie Zugriff auf die Hauptkonfigurationsdatei des Servers haben, verwenden Sie die [`TraceEnable`](https://httpd.apache.org/docs/current/mod/core.html#traceenable) Direktive stattdessen.
+Wenn Sie Zugriff auf die Hauptserver-Konfigurationsdatei haben, verwenden Sie die [`TraceEnable`](https://httpd.apache.org/docs/current/mod/core.html#traceenable) Direktive stattdessen.
 
 ```apacheconf
 <IfModule mod_rewrite.c>
@@ -520,11 +520,11 @@ Wenn Sie Zugriff auf die Hauptkonfigurationsdatei des Servers haben, verwenden S
 </IfModule>
 ```
 
-## Entfernen Sie den `X-Powered-By` Antwort-Header
+## Entfernen des `X-Powered-By` Antwort-Headers
 
-Einige Frameworks wie PHP und ASP.NET setzen einen `X-Powered-By`-Header, der Informationen über sie enthält (z.B. ihren Namen, Versionsnummer)
+Einige Frameworks wie PHP und ASP.NET setzen einen `X-Powered-By` Header, der Informationen über sie enthält (z. B. ihren Namen, Versionsnummer).
 
-Dieser Header liefert keinen Wert, und in einigen Fällen können die bereitgestellten Informationen Sicherheitslücken offenbaren
+Dieser Header bietet keinen Mehrwert und in einigen Fällen können die Informationen, die er bereitstellt, Schwachstellen preisgeben.
 
 ```apacheconf
 <IfModule mod_headers.c>
@@ -533,23 +533,23 @@ Dieser Header liefert keinen Wert, und in einigen Fällen können die bereitgest
 </IfModule>
 ```
 
-Wenn möglich, sollten Sie den `X-Powered-By`-Header auf Sprachen-/Framework-Ebene deaktivieren (z.B. für PHP können Sie dies tun, indem Sie folgendes in `php.ini` einstellen.
+Wenn Sie können, sollten Sie den `X-Powered-By` Header auf der Sprache/Framework-Ebene deaktivieren (z. B. für PHP können Sie das tun, indem Sie Folgendes in `php.ini` festlegen).
 
 ```ini
 expose_php = off;
 ```
 
-## Entfernen der von Apache generierten Serverinformationen im Footer
+## Entfernen der von Apache generierten Server-Informationen im Footer
 
-Verhindern Sie, dass Apache eine Fußzeile mit Informationen über den Server zu den servergenerierten Dokumenten hinzufügt (z.B. Fehlermeldungen, Verzeichnislistungen usw.). Weitere Informationen darüber, was die Server-Signatur bereitstellt, finden Sie in der Dokumentation zur [`ServerSignature`](https://httpd.apache.org/docs/current/mod/core.html#serversignature) Direktive und zur [`ServerTokens`](https://httpd.apache.org/docs/current/mod/core.html#servertokens) Direktive für Informationen über die Konfiguration der bereitgestellten Informationen in der Signatur.
+Verhindern Sie, dass Apache eine abschließende Fußzeilenzeile enthält, die Informationen über den Server zu servergenerierten Dokumenten hinzufügt (z. B. Fehlermeldungen, Verzeichnislisten, etc.). Siehe die [`ServerSignature`](https://httpd.apache.org/docs/current/mod/core.html#serversignature) Direktive Dokumentation für mehr Informationen darüber, was die Serversignatur liefert und die [`ServerTokens`](https://httpd.apache.org/docs/current/mod/core.html#servertokens) für Informationen zur Konfiguration der in der Signatur bereitgestellten Informationen.
 
 ```apacheconf
 ServerSignature Off
 ```
 
-## Reparieren von fehlerhaften `AcceptEncoding`-Headern
+## Korrigieren von fehlerhaften `AcceptEncoding`-Headern
 
-Manche Proxies und Sicherheitssoftware verändern oder entfernen den HTTP-Header `Accept-Encoding`. Siehe [Pushing Beyond Gzipping](https://calendar.perfplanet.com/2010/pushing-beyond-gzipping/) für eine ausführlichere Erklärung.
+Einige Proxies und Sicherheitssoftware zerlegen oder entfernen den `Accept-Encoding` HTTP-Header. Siehe [Pushing Beyond Gzipping](https://calendar.perfplanet.com/2010/pushing-beyond-gzipping/) für eine detailliertere Erklärung.
 
 ```apacheconf
 <IfModule mod_deflate.c>
@@ -562,9 +562,9 @@ Manche Proxies und Sicherheitssoftware verändern oder entfernen den HTTP-Header
 </IfModule>
 ```
 
-## Medien-Typen komprimieren
+## Medienarten komprimieren
 
-Komprimieren Sie alle als eine der folgenden Medientypen gekennzeichneten Ausgaben mit der [AddOutputFilterByType Direktive](https://httpd.apache.org/docs/current/mod/mod_filter.html#addoutputfilterbytype).
+Komprimieren Sie alle mit einem der folgenden Medientypen gekennzeichneten Ausgaben mit der [AddOutputFilterByType Direktive](https://httpd.apache.org/docs/current/mod/mod_filter.html#addoutputfilterbytype).
 
 ```apacheconf
 <IfModule mod_deflate.c>
@@ -609,9 +609,9 @@ Komprimieren Sie alle als eine der folgenden Medientypen gekennzeichneten Ausgab
 </IfModule>
 ```
 
-## Erweiterungen zu Medientypen zuordnen
+## Erweiterungen auf Medientypen abbilden
 
-Ordnen Sie die folgenden Dateinamenserweiterungen dem angegebenen Codierungstyp mit [AddEncoding](https://httpd.apache.org/docs/current/mod/mod_mime.html#addencoding) zu, damit Apache die Dateitypen mit dem entsprechenden `Content-Encoding` Antwort-Header bereitstellen kann (dies führt NICHT dazu, dass Apache sie komprimiert!). Wenn diese Dateitypen ohne entsprechenden `Content-Encoding` Antwort-Header bereitgestellt wurden, würden Clientanwendungen (z.B. Browser) nicht wissen, dass sie zuerst die Antwort dekomprimieren müssen und daher nicht in der Lage sein, den Inhalt zu verstehen.
+Ordnen Sie die folgenden Dateinamenerweiterungen dem angegebenen Kodierungstyp mit [AddEncoding](https://httpd.apache.org/docs/current/mod/mod_mime.html#addencoding) zu, damit Apache die Dateitypen mit dem entsprechenden `Content-Encoding` Antwort-Header bereitstellen kann (dies wird Apache NICHT dazu bringen, sie zu komprimieren!). Wenn diese Dateitypen ohne einen entsprechenden `Content-Encoding`-Antwort-Header bereitgestellt werden, würden Clientanwendungen (z.B. Browser) nicht wissen, dass sie die Antwort zuerst dekomprimieren müssen und könnten daher die Inhalte nicht verstehen.
 
 ```apacheconf
 <IfModule mod_deflate.c>
@@ -623,7 +623,7 @@ Ordnen Sie die folgenden Dateinamenserweiterungen dem angegebenen Codierungstyp
 
 ## Cache-Ablauf
 
-Stellen Sie Ressourcen mit einem Ablaufdatum in ferner Zukunft mit dem [mod_expires](https://httpd.apache.org/docs/current/mod/mod_expires.html) Modul bereit und verwenden Sie [Cache-Control](/de/docs/Web/HTTP/Headers/Cache-Control) und [Expires](/de/docs/Web/HTTP/Headers/Expires) Header.
+Dienen Sie Ressourcen mit einem weit in der Zukunft liegenden Ablaufdatum unter Verwendung des [mod_expires](https://httpd.apache.org/docs/current/mod/mod_expires.html) Moduls und der [Cache-Control](/de/docs/Web/HTTP/Headers/Cache-Control) und [Expires](/de/docs/Web/HTTP/Headers/Expires) Header.
 
 ```apacheconf
 <IfModule mod_expires.c>
diff --git a/files/de/learn/server-side/django/introduction/index.md b/files/de/learn/server-side/django/introduction/index.md
index bb6c6093e..9d474f855 100644
--- a/files/de/learn/server-side/django/introduction/index.md
+++ b/files/de/learn/server-side/django/introduction/index.md
@@ -1,28 +1,28 @@
 ---
-title: Einführung in Django
+title: Django Einführung
 slug: Learn/Server-side/Django/Introduction
 l10n:
-  sourceCommit: 5f76b99045f87349ed030bbd6a3c2e43badb3c22
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{LearnSidebar}}{{NextMenu("Learn/Server-side/Django/development_environment", "Learn/Server-side/Django")}}
 
 In diesem ersten Django-Artikel beantworten wir die Frage "Was ist Django?" und geben Ihnen einen Überblick darüber, was dieses Web-Framework besonders macht.
 
-Wir skizzieren die Hauptmerkmale, einschließlich einiger fortgeschrittener Funktionen, die wir in diesem Modul nicht im Detail behandeln werden. Wir zeigen Ihnen auch einige der wichtigsten Bausteine einer Django-Anwendung (obwohl Sie zu diesem Zeitpunkt noch keine Entwicklungsumgebung haben werden, um es zu testen).
+Wir skizzieren die Hauptmerkmale, einschließlich einiger fortgeschrittener Funktionen, die wir in diesem Modul nicht im Detail behandeln können. Wir zeigen Ihnen auch einige der Hauptbausteine einer Django-Anwendung (obwohl Sie an diesem Punkt noch keine Entwicklungsumgebung haben werden, um es zu testen).
 
 <table>
   <tbody>
     <tr>
       <th scope="row">Voraussetzungen:</th>
       <td>
-        Ein allgemeines Verständnis der <a href="/de/docs/Learn/Server-side/First_steps">serverseitigen Website-Programmierung</a>, insbesondere der Mechanismen von <a href="/de/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server-Interaktionen in Websites</a>.
+        Ein allgemeines Verständnis der <a href="/de/docs/Learn/Server-side/First_steps">Server-seitigen Website-Programmierung</a> und insbesondere die Mechanismen der <a href="/de/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server-Interaktionen in Websites</a>.
       </td>
     </tr>
     <tr>
-      <th scope="row">Zielsetzung:</th>
+      <th scope="row">Ziel:</th>
       <td>
-        Vertrautheit mit Django, seinen Funktionalitäten und den Hauptbausteinen einer Django-Anwendung zu erlangen.
+        Vertrautheit mit Django zu erlangen, welche Funktionalitäten es bietet und die Hauptbausteine einer Django-Anwendung kennenzulernen.
       </td>
     </tr>
   </tbody>
@@ -30,85 +30,85 @@ Wir skizzieren die Hauptmerkmale, einschließlich einiger fortgeschrittener Funk
 
 ## Was ist Django?
 
-Django ist ein hochrangiges Python-Web-Framework, das eine schnelle Entwicklung sicherer und wartbarer Webseiten ermöglicht. Es wurde von erfahrenen Entwicklern erstellt und nimmt Ihnen viel von der Arbeit der Webentwicklung ab, sodass Sie sich darauf konzentrieren können, Ihre App zu schreiben, ohne das Rad neu erfinden zu müssen. Es ist kostenlos und quelloffen, hat eine florierende und aktive Community, großartige Dokumentation und viele Optionen für kostenlose und kostenpflichtige Unterstützung.
+Django ist ein hochentwickeltes Python-Web-Framework, das die schnelle Entwicklung von sicheren und wartbaren Websites ermöglicht. Entwickelt von erfahrenen Entwicklern, nimmt Django viel von der Mühe der Webentwicklung ab, sodass Sie sich auf das Schreiben Ihrer Anwendung konzentrieren können, ohne das Rad neu erfinden zu müssen. Es ist kostenlos und Open Source, hat eine florierende und aktive Community, ausgezeichnete Dokumentation und viele Optionen für kostenlose und kostenpflichtige Unterstützung.
 
 Django hilft Ihnen, Software zu schreiben, die:
 
-- Komplett ist
-  - : Django folgt der Philosophie "Batterien sind enthalten" und bietet fast alles, was Entwickler „out of the box“ benötigen könnten. Da alles, was Sie brauchen, Teil des einen "Produkts" ist, funktioniert alles nahtlos zusammen, folgt konsistenten Designprinzipien und verfügt über umfangreiche und [aktuelle Dokumentation](https://docs.djangoproject.com/en/stable/).
+- Vollständig ist
+  - : Django folgt der Philosophie "Batterien enthalten" und bietet fast alles, was Entwickler "out of the box" tun möchten. Da alles, was Sie benötigen, Teil des einen "Produkts" ist, funktioniert es nahtlos zusammen, folgt konsistenten Designprinzipien und hat eine umfangreiche und [aktuelle Dokumentation](https://docs.djangoproject.com/en/stable/).
 - Vielseitig
 
-  - : Django kann (und wurde) verwendet, um fast jede Art von Webseite zu erstellen — von Content-Management-Systemen und Wikis bis hin zu sozialen Netzwerken und Nachrichtenseiten. Es kann mit jedem clientseitigen Framework arbeiten und Inhalte in fast jedem Format liefern (einschließlich HTML, RSS-Feeds, JSON und XML).
+  - : Django kann (und wurde) verwendet, um fast jede Art von Website zu erstellen — von Content-Management-Systemen und Wikis über soziale Netzwerke bis hin zu Nachrichten-Websites. Es kann mit jedem clientseitigen Framework arbeiten und Inhalte in fast jedem Format bereitstellen (einschließlich HTML, RSS-Feeds, JSON und XML).
 
-    Intern bietet es zwar Auswahlmöglichkeiten für fast jede Funktionalität, die Sie möglicherweise benötigen (z.B. mehrere beliebte Datenbanken, Template-Engines, usw.), es kann aber auch erweitert werden, um bei Bedarf andere Komponenten zu verwenden.
+    Intern bietet es Möglichkeiten für fast jede Funktionalität, die Sie möglicherweise benötigen (z. B. mehrere beliebte Datenbanken, Template-Engines usw.), kann aber auch erweitert werden, um andere Komponenten zu verwenden, wenn nötig.
 
 - Sicher
 
-  - : Django hilft Entwicklern, viele häufige Sicherheitsfehler zu vermeiden, indem es ein Framework bereitstellt, das entwickelt wurde, um "die richtigen Dinge" zu tun und die Website automatisch zu schützen. Beispielsweise bietet Django eine sichere Möglichkeit, Benutzerkonten und Passwörter zu verwalten, um häufige Fehler wie das Speichern von Sitzungsinformationen in Cookies zu vermeiden, wo sie anfällig sind (stattdessen enthalten Cookies nur einen Schlüssel und die tatsächlichen Daten werden in der Datenbank gespeichert) oder Passwörter direkt zu speichern, statt eines Passwort-Hashes.
+  - : Django hilft Entwicklern, viele häufige Sicherheitsfehler zu vermeiden, indem es ein Framework bereitstellt, das "das Richtige" tut, um die Website automatisch zu schützen. Zum Beispiel bietet Django eine sichere Möglichkeit, Benutzerkonten und Passwörter zu verwalten und vermeidet dabei häufige Fehler wie das Ablegen von Sitzungsinformationen in Cookies, wo sie anfällig sind (stattdessen enthalten Cookies nur einen Schlüssel, und die tatsächlichen Daten werden in der Datenbank gespeichert) oder Passwörter direkt zu speichern, anstatt eines Passwort-Hashes.
 
-    _Ein Passwort-Hash ist ein Wert fester Länge, der erzeugt wird, indem das Passwort durch eine [kryptografische Hash-Funktion](https://en.wikipedia.org/wiki/Cryptographic_hash_function) gesendet wird. Django kann prüfen, ob ein eingegebenes Passwort korrekt ist, indem es es durch die Hash-Funktion laufen lässt und das Ergebnis mit dem gespeicherten Hash-Wert vergleicht. Aufgrund der „Einweg“-Natur der Funktion ist es jedoch selbst bei kompromittiertem Hash-Wert schwierig für einen Angreifer, das ursprüngliche Passwort herauszufinden._
+    _Ein Passwort-Hash ist ein festlängiges Wert, das durch das Senden des Passworts durch eine [kryptographische Hash-Funktion](https://en.wikipedia.org/wiki/Cryptographic_hash_function) generiert wird. Django kann überprüfen, ob ein eingegebenes Passwort korrekt ist, indem es durch die Hash-Funktion läuft und die Ausgabe mit dem gespeicherten Hash-Wert vergleicht. Aufgrund der "Einweg"-Natur der Funktion ist es jedoch selbst dann schwierig für einen Angreifer, das ursprüngliche Passwort herauszufinden, wenn ein gespeicherter Hash-Wert kompromittiert wurde._
 
-    Django ermöglicht den Schutz vor vielen Schwachstellen standardmäßig, darunter SQL-Injection, Cross-Site Scripting, Cross-Site Request Forgery und {{Glossary("Clickjacking", "Clickjacking")}} (siehe [Website-Sicherheit](/de/docs/Learn/Server-side/First_steps/Website_security) für weitere Details zu solchen Angriffen).
+    Django ermöglicht den Schutz vor vielen Schwachstellen standardmäßig, einschließlich SQL-Injection, Cross-Site-Scripting, Cross-Site-Request-Forgery und [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) (siehe [Website-Sicherheit](/de/docs/Learn/Server-side/First_steps/Website_security) für weitere Details zu solchen Angriffen).
 
 - Skalierbar
-  - : Django verwendet eine komponentenbasierte "[Shared-Nothing](https://en.wikipedia.org/wiki/Shared_nothing_architecture)"-Architektur (jeder Teil der Architektur ist unabhängig von den anderen und kann daher bei Bedarf ersetzt oder geändert werden). Eine klare Trennung zwischen den verschiedenen Teilen bedeutet, dass es für erhöhten Datenverkehr skalieren kann, indem Hardware auf jeder Ebene hinzugefügt wird: Caching-Server, Datenbank-Server oder Anwendungs-Server. Einige der meistbesuchten Websites haben Django erfolgreich skaliert, um ihren Anforderungen gerecht zu werden (z.B. Instagram und Disqus, um nur zwei zu nennen).
+  - : Django verwendet eine komponentenbasierte "[Shared-nothing](https://de.wikipedia.org/wiki/Shared-nothing-Architektur)" Architektur (jeder Teil der Architektur ist unabhängig von den anderen und kann daher bei Bedarf ersetzt oder geändert werden). Eine klare Trennung zwischen den verschiedenen Teilen bedeutet, dass es sich für erhöhten Verkehr skalieren lässt, indem Hardware auf jeder Ebene hinzugefügt wird: Caching-Server, Datenbank-Server oder Anwendungsserver. Einige der verkehrsreichsten Websites haben Django erfolgreich skaliert, um ihre Anforderungen zu erfüllen (z. B. Instagram und Disqus, um nur zwei zu nennen).
 - Wartbar
-  - : Django-Code wird nach Designprinzipien und Mustern geschrieben, die dazu ermutigen, wartbaren und wiederverwendbaren Code zu erstellen. Insbesondere nutzt es das Don't Repeat Yourself (DRY)-Prinzip, um unnötige Duplizierungen zu vermeiden und die Menge des Codes zu reduzieren. Django fördert auch die Gruppierung verwandter Funktionalitäten in wiederverwendbaren "Anwendungen" und gruppiert auf niedrigerer Ebene verwandten Code in Modulen (nach dem {{Glossary("MVC", "Model View Controller (MVC)")}}-Muster).
+  - : Django-Code wird unter Anwendung von Designprinzipien und Mustern geschrieben, die die Erstellung von wartbarem und wiederverwendbarem Code fördern. Insbesondere nutzt es das Don't Repeat Yourself (DRY)-Prinzip, um unnötige Duplikationen zu vermeiden und die Menge an Code zu reduzieren. Django fördert auch die Gruppierung verwandter Funktionalitäten in wiederverwendbare "Anwendungen" und auf einer niedrigeren Ebene die Gruppierung verwandten Codes in Module (ähnlich dem {{Glossary("MVC", "Model View Controller (MVC)")}}-Muster).
 - Portabel
-  - : Django ist in Python geschrieben, das auf vielen Plattformen läuft. Das bedeutet, dass Sie nicht an eine bestimmte Serverplattform gebunden sind und Ihre Anwendungen auf vielen Varianten von Linux, Windows und macOS ausführen können. Darüber hinaus wird Django von vielen Webhosting-Anbietern gut unterstützt, die häufig spezifische Infrastrukturen und Dokumentationen für das Hosting von Django-Sites bereitstellen.
+  - : Django ist in Python geschrieben, das auf vielen Plattformen läuft. Das bedeutet, dass Sie an keine bestimmte Serverplattform gebunden sind und Ihre Anwendungen auf vielen Varianten von Linux, Windows und macOS betreiben können. Darüber hinaus wird Django von vielen Web-Hosting-Anbietern gut unterstützt, die oft spezifische Infrastruktur und Dokumentation für das Hosting von Django-Seiten bereitstellen.
 
-## Woher kommt Django?
+## Woher kommt es?
 
-Django wurde ursprünglich zwischen 2003 und 2005 von einem Webteam entwickelt, das für die Erstellung und Wartung von Zeitungswebsites verantwortlich war. Nachdem sie eine Vielzahl von Seiten erstellt hatten, begann das Team, gemeinsamen Code und Designmuster auszufiltern und wiederzuverwenden. Dieser gemeinsame Code entwickelte sich zu einem generischen Webentwicklungs-Framework, das im Juli 2005 als "Django"-Projekt als Open Source veröffentlicht wurde.
+Django wurde ursprünglich zwischen 2003 und 2005 von einem Web-Team entwickelt, das verantwortlich war für die Erstellung und Wartung von Zeitungswebsites. Nachdem eine Reihe von Websites erstellt worden waren, begann das Team, viel des gemeinsamen Codes und der Designmuster zu extrahieren und wiederzuverwenden. Dieser gemeinsame Code entwickelte sich zu einem generischen Web-Entwicklungs-Framework, das im Juli 2005 als "Django" Projekt open-sourced wurde.
 
-Django hat sich kontinuierlich weiterentwickelt und verbessert, von seiner ersten Meilensteinveröffentlichung (1.0) im September 2008 bis zur Version 5.0 Ende 2023. Jede Veröffentlichung hat neue Funktionalitäten und Fehlerbehebungen hinzugefügt, von der Unterstützung neuer Datenbanktypen, Template-Engines und Caching bis hin zur Hinzufügung von "generischen" Ansichts-Funktionen und Klassen (die die Menge des Codes reduzieren, den Entwickler für eine Reihe von Programmieraufgaben schreiben müssen).
+Django ist weiterhin gewachsen und hat sich verbessert, von der ersten Meilenstein-Veröffentlichung (1.0) im September 2008 bis hin zu Version 5.0 Ende 2023. Jede Veröffentlichung hat neue Funktionalitäten und Fehlerbehebungen hinzugefügt, von der Unterstützung neuer Datenbanktypen, Template-Engines und Caching bis hin zur Ergänzung von "generischen" View-Funktionen und -Klassen (die die Menge an Code reduzieren, den Entwickler für eine Reihe von Programmieraufgaben schreiben müssen).
 
 > [!NOTE]
-> Sehen Sie sich die [Versionshinweise](https://docs.djangoproject.com/en/stable/releases/) auf der Django-Website an, um zu sehen, was sich in den letzten Versionen geändert hat und wie viel Arbeit in die Verbesserung von Django investiert wird.
+> Schauen Sie sich die [Versionshinweise](https://docs.djangoproject.com/en/stable/releases/) auf der Django-Website an, um zu sehen, was sich in den neuesten Versionen geändert hat und wie viel Arbeit in die Verbesserung von Django gesteckt wird.
 
-Django ist jetzt ein blühendes, kollaboratives Open-Source-Projekt mit vielen Tausenden von Nutzern und Mitwirkenden. Obwohl es immer noch einige Funktionen hat, die seinen Ursprung widerspiegeln, hat sich Django zu einem vielseitigen Framework entwickelt, das in der Lage ist, jede Art von Website zu entwickeln.
+Django ist mittlerweile ein florierendes, kollaboratives Open-Source-Projekt mit vielen tausend Nutzern und Mitwirkenden. Obwohl es immer noch einige Merkmale hat, die seine Ursprünge widerspiegeln, hat sich Django zu einem vielseitigen Framework entwickelt, das in der Lage ist, jede Art von Website zu entwickeln.
 
 ## Wie populär ist Django?
 
-Es gibt keine unmittelbar verfügbare und endgültige Messung der Beliebtheit von serverseitigen Frameworks (obwohl Sie die Beliebtheit durch Mechanismen wie das Zählen der GitHub-Projekte und Stack Overflow-Fragen für jede Plattform abschätzen können). Eine bessere Frage ist, ob Django "beliebt genug" ist, um Probleme unpopulärer Plattformen zu vermeiden. Entwickelt es sich weiter? Kann man Hilfe bekommen, wenn man sie braucht? Gibt es eine Möglichkeit, bezahlte Arbeit zu finden, wenn man Django lernt?
+Es gibt keine sofort verfügbar und eindeutige Messung der Beliebtheit von serverseitigen Frameworks (obwohl Sie die Beliebtheit anhand von Mechanismen wie der Zählung der Anzahl von GitHub-Projekten und Stack-Overflow-Fragen für jede Plattform schätzen können). Eine bessere Frage ist, ob Django „beliebt genug“ ist, um die Probleme unbeliebter Plattformen zu vermeiden. Entwickelt es sich weiter? Können Sie Hilfe bekommen, wenn Sie sie brauchen? Gibt es eine Möglichkeit, bezahlte Arbeit zu bekommen, wenn Sie Django lernen?
 
-Basierend auf der Anzahl der hochkarätigen Websites, die Django nutzen, der Anzahl der Personen, die zum Code beitragen, und der Anzahl der Personen, die sowohl kostenlose als auch kostenpflichtige Unterstützung bieten, ist Django ein beliebtes Framework!
+Basierend auf der Anzahl hochrangiger Websites, die Django verwenden, der Anzahl von Personen, die zum Codebase beitragen, und der Anzahl von Personen, die sowohl kostenlose als auch kostenpflichtige Unterstützung bieten, ist Django ein beliebtes Framework!
 
-Hochkarätige Sites, die Django verwenden, umfassen: Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest und Open Stack (Quelle: [Django-Übersichtsseite](https://www.djangoproject.com/start/overview/)).
+Hochprofilierte Seiten, die Django verwenden, umfassen: Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest und Open Stack (Quelle: [Django Übersichtsseite](https://www.djangoproject.com/start/overview/)).
 
 ## Ist Django meinungsstark?
 
-Web-Frameworks bezeichnen sich oft als "meinungsstark" oder "unmeinungsstark".
+Web-Frameworks bezeichnen sich oft als "meinungsstark" oder "nicht meinungsstark".
 
-Meinungsstarke Frameworks sind solche mit Meinungen darüber, wie eine bestimmte Aufgabe zu handhaben ist. Sie unterstützen häufig die schnelle Entwicklung _in einem bestimmten Bereich_ (Lösung von Problemen einer bestimmten Art), weil der richtige Weg, um etwas zu tun, normalerweise gut verstanden und gut dokumentiert ist. Sie können jedoch weniger flexibel sein, um Probleme außerhalb ihres Hauptbereichs zu lösen, und tendieren dazu, weniger Auswahlmöglichkeiten für die verwendeten Komponenten und Ansätze zu bieten.
+Meinungsstarke Frameworks sind diejenigen mit Meinungen darüber, wie man eine bestimmte Aufgabe "richtig" erledigt. Sie unterstützen oft eine schnelle Entwicklung _in einem bestimmten Bereich_ (Lösen von Problemen eines bestimmten Typs), weil der richtige Weg, etwas zu tun, normalerweise gut verstanden und dokumentiert ist. Sie können jedoch weniger flexibel beim Lösen von Problemen außerhalb ihres Hauptbereichs sein und bieten tendenziell weniger Auswahlmöglichkeiten bei den Komponenten und Ansätzen, die sie verwenden können.
 
-Unmeinungsstarke Frameworks hingegen haben weit weniger Einschränkungen bezüglich der besten Art und Weise, Komponenten zusammenzufügen, um ein Ziel zu erreichen, oder welche Komponenten verwendet werden sollten. Sie erleichtern es Entwicklern, die geeignetsten Werkzeuge zu verwenden, um eine bestimmte Aufgabe zu erledigen, wenn auch auf Kosten der Tatsache, dass Sie diese Komponenten selbst finden müssen.
+Nicht meinungsstarke Frameworks hingegen haben weitaus weniger Einschränkungen bei der besten Art und Weise, Komponenten zusammenzufügen, um ein Ziel zu erreichen, oder selbst, welche Komponenten verwendet werden sollen. Sie erleichtern es Entwicklern, die geeignetsten Werkzeuge zu verwenden, um eine bestimmte Aufgabe abzuschließen, allerdings auf Kosten, dass Sie diese Komponenten selbst finden müssen.
 
-Django ist "etwas meinungsstark" und bietet daher das "beste aus beiden Welten". Es bietet eine Reihe von Komponenten, um die meisten Aufgaben der Webentwicklung zu bewältigen, und eine (oder zwei) bevorzugte Wege, sie zu verwenden. Aufgrund der entkoppelten Architektur von Django können Sie in der Regel aus einer Reihe verschiedener Optionen auswählen oder Unterstützung für völlig neue hinzufügen, wenn gewünscht.
+Django ist "etwas meinungsstark" und liefert daher das "Beste aus beiden Welten". Es bietet eine Reihe von Komponenten, um die meisten Web-Entwicklungsaufgaben zu erledigen, und eine (oder zwei) bevorzugte Art, sie zu verwenden. Die entkoppelte Architektur von Django bedeutet jedoch, dass Sie in der Regel aus einer Reihe unterschiedlicher Optionen wählen und neue unterstützen können, wenn gewünscht.
 
 ## Wie sieht Django-Code aus?
 
-In einer traditionellen datengetriebenen Website wartet eine Webanwendung auf HTTP-Anfragen vom Webbrowser (oder anderen Clients). Bei Empfang einer Anfrage ermittelt die Anwendung, was basierend auf der URL und möglicherweise Informationen in `POST`-Daten oder `GET`-Daten benötigt wird. Abhängig davon, was erforderlich ist, kann sie dann Informationen aus einer Datenbank lesen oder schreiben oder andere Aufgaben ausführen, die erforderlich sind, um die Anfrage zu erfüllen. Die Anwendung kehrt dann mit einer Antwort zum Webbrowser zurück und erstellt oft dynamisch eine HTML-Seite für den Browser, indem die abgerufenen Daten in Platzhalter in einer HTML-Vorlage eingefügt werden.
+In einer traditionellen datengesteuerten Website wartet eine Webanwendung auf HTTP-Anfragen des Webbrowsers (oder eines anderen Clients). Wenn eine Anfrage empfangen wird, arbeitet die Anwendung heraus, was benötigt wird, basierend auf der URL und möglicherweise Informationen in `POST`-Daten oder `GET`-Daten. Je nachdem, was erforderlich ist, kann es dann Informationen aus einer Datenbank lesen oder schreiben oder andere Aufgaben ausführen, die erforderlich sind, um die Anfrage zu erfüllen. Die Anwendung gibt dann eine Antwort an den Webbrowser zurück, indem sie oft eine HTML-Seite dynamisch erstellt, indem die abgerufenen Daten in Platzhalter in einer HTML-Vorlage eingefügt werden.
 
-Django-Webanwendungen gruppieren den Code, der jeden dieser Schritte behandelt, typischerweise in separate Dateien:
+Django-Webanwendungen gruppieren typischerweise den Code, der jeden dieser Schritte verarbeitet, in separate Dateien:
 
-![Django - Dateien für Ansichten, Modell, URLs, Vorlage](basic-django.png)
+![Django - Dateien für Ansichten, Modell, URLs, Template](basic-django.png)
 
-- **URLs:** Es ist zwar möglich, Anfragen von jeder einzelnen URL über eine einzige Funktion zu verarbeiten, aber es ist viel wartbarer, eine separate Ansichtsfunktion zu schreiben, um jede Ressource zu handhaben. Ein URL-Mapper wird verwendet, um HTTP-Anfragen basierend auf der Anfrage-URL an die entsprechende Ansicht weiterzuleiten. Der URL-Mapper kann auch bestimmte Muster von Zeichenfolgen oder Ziffern, die in einer URL erscheinen, erkennen und diese als Daten an eine Ansichtsfunktion übergeben.
-- **Ansicht:** Eine Ansicht ist eine Anfragehandler-Funktion, die HTTP-Anfragen empfängt und HTTP-Antworten zurückgibt. Ansichten greifen auf die Daten zu, die zur Erfüllung von Anfragen benötigt werden, _durch Modelle_ und delegieren das Formatieren der Antwort an _Vorlagen_.
-- **Modelle:** Modelle sind Python-Objekte, die die Struktur der Daten einer Anwendung definieren und Mechanismen bereitstellen, um Datensätze in der Datenbank zu verwalten (hinzufügen, ändern, löschen) und abzufragen.
-- **Vorlagen:** Eine Vorlage ist eine Textdatei, die die Struktur oder das Layout einer Datei definiert (wie eine HTML-Seite) und Platzhalter verwendet, um den tatsächlichen Inhalt darzustellen. Eine _Ansicht_ kann eine HTML-Seite dynamisch unter Verwendung einer HTML-Vorlage erstellen, die mit Daten aus einem _Modell_ gefüllt ist. Eine Vorlage kann verwendet werden, um die Struktur jeder Art von Datei zu definieren; sie muss nicht HTML sein!
+- **URLs:** Obwohl es möglich ist, Anfragen von jeder einzelnen URL über eine einzige Funktion zu verarbeiten, ist es viel wartbarer, eine separate View-Funktion zu schreiben, um jede Ressource zu verwalten. Ein URL-Mapper wird verwendet, um HTTP-Anfragen basierend auf der Anforderungs-URL an die entsprechende Ansicht umzuleiten. Der URL-Mapper kann auch bestimmte Muster von Zeichenfolgen oder Ziffern erkennen, die in einer URL erscheinen, und diese als Daten an eine View-Funktion übergeben.
+- **View:** Eine View ist eine Anforderungsverarbeitungsfunktion, die HTTP-Anfragen empfängt und HTTP-Antworten zurückgibt. Views greifen auf die Daten zu, die benötigt werden, um Anfragen über _Modelle_ zu erfüllen, und delegieren die Formatierung der Antwort an _Templates_.
+- **Modelle:** Modelle sind Python-Objekte, die die Struktur der Daten einer Anwendung definieren und Mechanismen zum Verwalten (hinzufügen, ändern, löschen) und Abfragen von Datensätzen in der Datenbank bereitstellen.
+- **Templates:** Ein Template ist eine Textdatei, die die Struktur oder das Layout einer Datei (wie einer HTML-Seite) definiert, mit Platzhaltern zum Darstellen des tatsächlichen Inhalts. Eine _View_ kann eine HTML-Seite dynamisch mit Hilfe eines HTML-Templates erzeugen und mit Daten aus einem _Modell_ füllen. Ein Template kann verwendet werden, um die Struktur von Dateien jeder Art zu definieren; es muss nicht HTML sein!
 
 > [!NOTE]
-> Django bezeichnet diese Organisation als "Model View Template (MVT)"-Architektur. Sie hat viele Ähnlichkeiten mit der bekannteren {{Glossary("MVC", "Model View Controller")}}-Architektur.
+> Django bezeichnet diese Organisation als "Model View Template (MVT)" Architektur. Es hat viele Ähnlichkeiten mit der bekannteren [Model View Controller](/de/docs/Glossar/MVC)-Architektur.
 
-Die folgenden Abschnitte geben Ihnen eine Vorstellung davon, wie diese Hauptteile einer Django-App aussehen (wir werden später im Kurs, wenn wir eine Entwicklungsumgebung eingerichtet haben, mehr ins Detail gehen).
+Die folgenden Abschnitte geben Ihnen eine Vorstellung davon, wie diese Hauptteile einer Django-App aussehen (wir werden später im Kurs genauer darauf eingehen, sobald wir eine Entwicklungsumgebung eingerichtet haben).
 
-### Die Anfrage an die richtige Ansicht senden (urls.py)
+### Die Anforderung an die richtige Ansicht senden (urls.py)
 
 Ein URL-Mapper wird typischerweise in einer Datei namens **urls.py** gespeichert.
-Im unten stehenden Beispiel definiert der Mapper (`urlpatterns`) eine Liste von Zuordnungen zwischen _Routen_ (spezifische URL-_Muster_) und entsprechenden Ansichtsfunktionen.
-Wenn eine HTTP-Anfrage empfangen wird, die eine URL enthält, die einem bestimmten Muster entspricht, dann wird die zugehörige Ansichtsfunktion aufgerufen und die Anfrage übergeben.
+Im unten stehenden Beispiel definiert der Mapper (`urlpatterns`) eine Liste von Zuordnungen zwischen _Routen_ (spezifischen URL-_Mustern)_ und entsprechenden View-Funktionen.
+Wenn eine HTTP-Anfrage mit einer URL empfangen wird, die einem bestimmten Muster entspricht, wird die zugehörige View-Funktion aufgerufen und erhält die Anfrage.
 
 ```python
 urlpatterns = [
@@ -119,17 +119,17 @@ urlpatterns = [
 ]
 ```
 
-Das `urlpatterns`-Objekt ist eine Liste von `path()` und/oder `re_path()`-Funktionen (Python-Listen werden mit eckigen Klammern definiert, wobei Elemente durch Kommas getrennt sind und ein [optionales abschließendes Komma](https://docs.python.org/3/faq/design.html#why-does-python-allow-commas-at-the-end-of-lists-and-tuples) haben können. Zum Beispiel: `[item1, item2, item3,]`).
+Das `urlpatterns`-Objekt ist eine Liste von `path()`- und/oder `re_path()`-Funktionen (Python-Listen werden mit eckigen Klammern definiert, bei denen die Elemente durch Kommas getrennt sind und ein [optional abschließendes Komma](https://docs.python.org/3/faq/design.html#why-does-python-allow-commas-at-the-end-of-lists-and-tuples) haben können. Zum Beispiel: `[item1, item2, item3,]`).
 
-Das erste Argument beider Methoden ist eine Route (Muster), die abgeglichen wird. Die `path()`-Methode verwendet spitze Klammern, um Teile einer URL zu definieren, die erfasst und als benannte Argumente an die Ansichtsfunktion übergeben werden. Die `re_path()`-Funktion verwendet einen flexiblen Methodenansatz namens Reguläre Ausdrücke. Wir werden später in einem weiteren Artikel darüber sprechen!
+Das erste Argument beider Methoden ist eine Route (Muster), die abgeglichen wird. Die `path()`-Methode verwendet spitze Klammern, um Teile einer URL zu definieren, die erfasst und als benannte Argumente an die View-Funktion übergeben werden. Die `re_path()`-Funktion verwendet einen flexiblen Musterabgleichsansatz, der als regulärer Ausdruck bekannt ist. Darüber werden wir in einem späteren Artikel sprechen!
 
-Das zweite Argument ist eine weitere Funktion, die aufgerufen wird, wenn das Muster übereinstimmt. Die Notation `views.book_detail` zeigt an, dass die Funktion `book_detail()` genannt wird und sich in einem Modul namens `views` befindet (d.h. in einer Datei namens `views.py`).
+Das zweite Argument ist eine andere Funktion, die aufgerufen wird, wenn das Muster übereinstimmt. Die Notation `views.book_detail` gibt an, dass die Funktion `book_detail()` genannt wird und in einem Modul namens `views` zu finden ist (d. h. in einer Datei namens `views.py`).
 
-### Die Anfrage bearbeiten (views.py)
+### Die Anforderung verarbeiten (views.py)
 
-Ansichten sind das Herzstück der Webanwendung, sie erhalten HTTP-Anfragen von Webclients und geben HTTP-Antworten zurück. Dazwischen verwenden sie die anderen Ressourcen des Frameworks, um auf Datenbanken zuzugreifen, Vorlagen zu rendern usw.
+Ansichten sind das Herzstück der Webanwendung, empfangen HTTP-Anforderungen von Webclients und geben HTTP-Antworten zurück. Dazwischen bündeln sie die anderen Ressourcen des Frameworks, um Datenbanken zuzugreifen, Templates zu rendern usw.
 
-Das folgende Beispiel zeigt eine minimale Ansichtsfunktion `index()`, die von unserem URL-Mapper im vorherigen Abschnitt aufgerufen werden könnte. Wie alle Ansichtsfunktionen erhält sie ein `HttpRequest`-Objekt als Parameter (`request`) und gibt ein `HttpResponse`-Objekt zurück. In diesem Fall machen wir nichts mit der Anfrage, und unsere Antwort gibt einen fest codierten String zurück. Wir zeigen Ihnen später eine Anfrage, die etwas Interessanteres macht.
+Das folgende Beispiel zeigt eine minimale View-Funktion `index()`, die von unserem URL-Mapper im vorherigen Abschnitt aufgerufen worden sein könnte. Wie alle View-Funktionen empfängt es ein `HttpRequest`-Objekt als Parameter (`request`) und gibt ein `HttpResponse`-Objekt zurück. In diesem Fall tun wir nichts mit der Anforderung, und unsere Antwort gibt einen festcodierten String zurück. Wir zeigen Ihnen in einem späteren Abschnitt eine Anfrage, die etwas Interessanteres macht.
 
 ```python
 # filename: views.py (Django view functions)
@@ -144,18 +144,18 @@ def index(request):
 ```
 
 > [!NOTE]
-> Ein wenig Python:
+> Ein bisschen Python:
 >
-> - [Python-Module](https://docs.python.org/3/tutorial/modules.html) sind "Bibliotheken" von Funktionen, die in separaten Dateien gespeichert sind, die wir in unserem Code verwenden möchten. Hier importieren wir nur das `HttpResponse`-Objekt aus dem `django.http`-Modul, damit wir es in unserer Ansicht verwenden können: `from django.http import HttpResponse`. Es gibt andere Möglichkeiten, einige oder alle Objekte aus einem Modul zu importieren.
-> - Funktionen werden mit dem Schlüsselwort `def` deklariert, wie oben gezeigt, wobei benannte Parameter in Klammern nach dem Funktionsnamen aufgelistet sind; die gesamte Zeile endet mit einem Doppelpunkt. Beachten Sie, wie die nächsten Zeilen alle **eingezogen** sind. Die Einrückung ist wichtig, da sie angibt, dass die Codezeilen in diesem bestimmten Block stehen (obligatorische Einrückung ist ein wesentliches Merkmal von Python und ein Grund dafür, dass Python-Code so leicht zu lesen ist).
+> - [Python-Module](https://docs.python.org/3/tutorial/modules.html) sind "Bibliotheken" von Funktionen, die in separaten Dateien gespeichert sind und die wir in unserem Code verwenden möchten. Hier importieren wir nur das `HttpResponse`-Objekt aus dem `django.http`-Modul, sodass wir es in unserer Ansicht verwenden können: `from django.http import HttpResponse`. Es gibt andere Methoden, um einige oder alle Objekte aus einem Modul zu importieren.
+> - Funktionen werden mit dem Schlüsselwort `def` deklariert, wie oben gezeigt, mit benannten Parametern, die in Klammern nach dem Namen der Funktion aufgelistet sind; die ganze Zeile endet mit einem Doppelpunkt. Beachten Sie, wie die nächsten Zeilen alle **eingerückt** sind. Die Einrückung ist wichtig, da sie angibt, dass die Codezeilen zu diesem bestimmten Block gehören (die obligatorische Einrückung ist ein wichtiges Merkmal von Python und ein Grund, warum Python-Code so lesbar ist).
 
 Ansichten werden normalerweise in einer Datei namens **views.py** gespeichert.
 
 ### Datenmodelle definieren (models.py)
 
-Django-Webanwendungen verwalten und fragen Daten durch Python-Objekte ab, die als Modelle bezeichnet werden. Modelle definieren die Struktur der gespeicherten Daten, einschließlich der Feldtypen und möglicherweise auch ihrer maximalen Größe, Standardwerte, Auswahlmöglichkeiten, Hilfetext für die Dokumentation, Beschriftungstext für Formulare usw. Die Definition des Modells ist unabhängig von der zugrunde liegenden Datenbank — Sie können eine von mehreren als Teil Ihrer Projekteinstellungen wählen. Wenn Sie ausgewählt haben, welche Datenbank Sie verwenden möchten, müssen Sie nicht direkt mit ihr sprechen — Sie schreiben einfach Ihre Modellstruktur und anderen Code, und Django übernimmt die gesamte "Drecksarbeit" der Kommunikation mit der Datenbank für Sie.
+Django-Webanwendungen verwalten und fragen Daten über Python-Objekte ab, die als Modelle bezeichnet werden. Modelle definieren die Struktur der gespeicherten Daten, einschließlich der Feldtypen und möglicherweise auch ihrer maximalen Größe, Standardwerte, Auswahlmöglichkeiten aus Listen, Hilfetext für Dokumentation, Beschriftungstext für Formulare usw. Die Definition des Modells ist unabhängig von der zugrunde liegenden Datenbank — Sie können eine von mehreren als Teil Ihrer Projekteinstellungen wählen. Sobald Sie ausgewählt haben, welche Datenbank Sie verwenden möchten, müssen Sie überhaupt nicht direkt mit ihr sprechen — Sie schreiben einfach Ihre Modellstruktur und anderen Code, und Django erledigt die ganze "schmutzige Arbeit" der Kommunikation mit der Datenbank für Sie.
 
-Der Codeausschnitt unten zeigt ein sehr einfaches Django-Modell für ein `Team`-Objekt. Die `Team`-Klasse ist von der Django-Klasse `models.Model` abgeleitet. Es definiert den Teamnamen und die Teamstufe als Zeichenfelder und gibt eine maximale Anzahl von Zeichen an, die für jeden Datensatz gespeichert werden sollen. Die `team_level` kann einer von mehreren Werten sein, daher definieren wir sie als Auswahlfeld und bieten eine Zuordnung zwischen anzuzeigenden Auswahlmöglichkeiten und zu speichernden Daten, zusammen mit einem Standardwert.
+Der unten stehende Codeausschnitt zeigt ein sehr einfaches Django-Modell für ein `Team`-Objekt. Die `Team`-Klasse leitet sich von der Django-Klasse `models.Model` ab. Es definiert den Teamnamen und das Teamlevel als Zeichenfelder und gibt eine maximale Anzahl von Zeichen an, die für jeden Datensatz gespeichert werden sollen. Das `team_level` kann einen von mehreren Werten haben, daher definieren wir es als Auswahlfeld und stellen eine Zuordnung zwischen anzuzeigenden Auswahlmöglichkeiten und zu speichernden Daten bereit, zusammen mit einem Standardwert.
 
 ```python
 # filename: models.py
@@ -176,17 +176,17 @@ class Team(models.Model):
 ```
 
 > [!NOTE]
-> Ein wenig Python:
+> Ein bisschen Python:
 >
-> Python unterstützt "objektorientierte Programmierung", einen Programmierstil, bei dem wir unseren Code in Objekte organisieren, die verwandte Daten und Funktionen zum Arbeiten an diesen Daten enthalten. Objekte können auch von anderen Objekten erben/erweitert/abgeleitet werden, sodass gemeinsames Verhalten zwischen verwandten Objekten geteilt werden kann. In Python verwenden wir das Schlüsselwort `class`, um den "Bauplan" für ein Objekt zu definieren. Wir können mehrere spezifische _Instanzen_ der Art von Objekt basierend auf dem Modell in der Klasse erstellen.
+> Python unterstützt "objektorientierte Programmierung", einen Programmierstil, bei dem wir unseren Code in Objekte organisieren, die verwandte Daten und Funktionen für den Betrieb dieser Daten enthalten. Objekte können auch von anderen Objekten erben/erweitern/abgeleitet werden, sodass gemeinsames Verhalten zwischen verwandten Objekten geteilt werden kann. In Python verwenden wir das Schlüsselwort `class`, um den "Bauplan" für ein Objekt zu definieren. Wir können mehrere spezifische _Instanzen_ des für den Typ von Objekt basierend auf dem Modell in der Klasse erstellen.
 >
-> So haben wir hier zum Beispiel eine `Team`-Klasse, die von der `Model`-Klasse abgeleitet ist. Das bedeutet, dass sie ein Modell ist und alle Methoden eines Modells enthält, aber wir können ihr auch eigene spezialisierte Funktionen geben. In unserem Modell definieren wir die Felder, die unsere Datenbank benötigt, um unsere Daten zu speichern, wobei wir ihnen spezifische Namen geben. Django verwendet diese Definitionen, einschließlich der Feldnamen, um die zugrunde liegende Datenbank zu erstellen.
+> So haben wir hier zum Beispiel eine `Team`-Klasse, die sich von der `Model`-Klasse ableitet. Dies bedeutet, dass es sich um ein Modell handelt und dass es alle Methoden eines Modells enthalten wird, jedoch können wir ihm auch spezialisierte Funktionen eigener Art geben. In unserem Modell definieren wir die Felder, die unsere Datenbank benötigt, um unsere Daten zu speichern, und geben ihnen spezifische Namen. Django verwendet diese Definitionen, einschließlich der Feldnamen, um die zugrunde liegende Datenbank zu erstellen.
 
 ### Daten abfragen (views.py)
 
-Das Django-Modell bietet eine einfache Abfrage-API zur Durchsuchung der zugehörigen Datenbank. Dies kann gegen eine Vielzahl von Feldern gleichzeitig abgeglichen werden, indem verschiedene Kriterien verwendet werden (z. B. exakt, groß-/kleinschreibungsunabhängig, größer als usw.), und kann komplexe Anweisungen unterstützen (zum Beispiel können Sie eine Suche nach U11-Teams angeben, die einen Teamnamen haben, der mit "Fr" beginnt oder mit "al" endet).
+Das Django-Modell bietet eine einfache Abfrage-API zum Suchen in der zugehörigen Datenbank. Dies kann mit mehreren Feldern gleichzeitig unter Verwendung unterschiedlicher Kriterien (z. B. exakt, nicht groß-/kleinschreibungsempfindlich, größer als usw.) übereinstimmen und komplexe Anweisungen unterstützen (zum Beispiel können Sie eine Suche nach U11-Teams spezifizieren, die einen Teamnamen haben, der mit "Fr" beginnt oder mit "al" endet).
 
-Der Codeausschnitt zeigt eine Ansichtsfunktion (Ressourcenhandler) zum Anzeigen aller unserer U09-Teams. Die Zeile `list_teams = Team.objects.filter(team_level__exact="U09")` zeigt, wie wir die Modellabfrage-API verwenden können, um alle Datensätze zu filtern, bei denen das `team_level`-Feld genau den Text `U09` enthält (beachten Sie, wie dieses Kriterium der `filter()`-Funktion als Argument übergeben wird, wobei der Feldname und der Abgleichstyp durch einen doppelten Unterstrich getrennt sind: **`team_level__exact`**).
+Der Codeausschnitt zeigt eine View-Funktion (Ressourcenverwalter) zum Anzeigen aller unserer U09-Teams. Die Zeile `list_teams = Team.objects.filter(team_level__exact="U09")` zeigt, wie wir die Modellabfrage-API verwenden können, um alle Datensätze zu filtern, bei denen das `team_level`-Feld genau den Text `U09` hat (beachten Sie, wie dieses Kriterium als Argument an die `filter()`-Funktion übergeben wird, wobei der Feldname und der Abgleichstyp durch einen doppelten Unterstrich getrennt sind: **`team_level__exact`**).
 
 ```python
 ## filename: views.py
@@ -200,13 +200,13 @@ def index(request):
     return render(request, '/best/index.html', context)
 ```
 
-Diese Funktion verwendet die `render()`-Funktion, um die `HttpResponse` zu erstellen, die an den Browser zurückgesendet wird. Diese Funktion ist eine _Abkürzung_; sie erstellt eine HTML-Datei, indem sie eine bestimmte HTML-Vorlage mit einigen einzufügenden Daten kombiniert (bereitgestellt in der Variablen mit dem Namen `context`). Im nächsten Abschnitt zeigen wir, wie die Vorlage mit den Daten gefüllt wird, um das HTML zu erstellen.
+Diese Funktion verwendet die `render()`-Funktion, um die `HttpResponse` zu erstellen, die an den Browser zurückgesendet wird. Diese Funktion ist eine _Verknüpfung_; sie erstellt eine HTML-Datei, indem sie eine bestimmte HTML-Vorlage und einige einzufügende Daten in die Vorlage (bereitgestellt in der Variablen `context`) kombiniert. Im nächsten Abschnitt zeigen wir, wie die Daten eingefügt werden, um die HTML zu erstellen.
 
-### Daten rendern (HTML-Vorlagen)
+### Daten rendern (HTML-Templates)
 
-Templatesysteme ermöglichen es Ihnen, die Struktur eines Ausgabedokuments anzugeben, indem Sie Platzhalter für Daten verwenden, die gefüllt werden, wenn eine Seite generiert wird. Vorlagen werden oft zur Erstellung von HTML verwendet, können aber auch andere Arten von Dokumenten erstellen. Django unterstützt sowohl sein eigenes Templating-System als auch eine andere beliebte Python-Bibliothek namens Jinja2 von Haus aus (es kann auch so angepasst werden, dass andere Systeme bei Bedarf unterstützt werden).
+Templatesysteme ermöglichen Ihnen, die Struktur eines Ausgabedokuments anzugeben, indem Sie Platzhalter für Daten verwenden, die eingefügt werden, wenn eine Seite generiert wird. Templates werden oft verwendet, um HTML zu erstellen, können aber auch andere Dokumenttypen erzeugen. Django unterstützt sowohl sein natives Templatesystem als auch eine andere beliebte Python-Bibliothek namens Jinja2 von Haus aus (es kann bei Bedarf auch andere Systeme unterstützen).
 
-Der Codeausschnitt zeigt, wie die HTML-Vorlage aussieht, die von der `render()`-Funktion im vorherigen Abschnitt aufgerufen wird. Diese Vorlage wurde unter der Annahme geschrieben, dass sie beim Rendering Zugriff auf eine Listenvariable namens `youngest_teams` hat (diese befindet sich in der `context`-Variablen innerhalb der `render()`-Funktion oben). In das HTML-Gerüst haben wir einen Ausdruck, der zuerst prüft, ob die `youngest_teams`-Variable existiert, und sie dann in einer `for`-Schleife durchläuft. Bei jeder Iteration zeigt die Vorlage den `team_name`-Wert jedes Teams in einem `<li>`-Element an.
+Der Codeausschnitt zeigt, wie das HTML-Template aussieht, das von der `render()`-Funktion im vorherigen Abschnitt aufgerufen wurde. Dieses Template wurde unter der Annahme geschrieben, dass es beim Rendern Zugriff auf eine Listenvariable namens `youngest_teams` hat (diese ist in der `context`-Variablen innerhalb der `render()`-Funktion oben enthalten). Innerhalb des HTML-Skeletts haben wir einen Ausdruck, der zuerst überprüft, ob die `youngest_teams`-Variable existiert, und dann in einer `for`-Schleife iteriert. Dabei zeigt das Template den `team_name`-Wert jedes Teams in einem `<li>`-Element an.
 
 ```django
 ## filename: best/templates/best/index.html
@@ -233,18 +233,18 @@ Der Codeausschnitt zeigt, wie die HTML-Vorlage aussieht, die von der `render()`-
 
 ## Was können Sie noch tun?
 
-Die vorangegangenen Abschnitte zeigen die Hauptmerkmale, die Sie in fast jeder Webanwendung verwenden werden: URL-Zuordnung, Ansichten, Modelle und Vorlagen. Nur einige der anderen Dinge, die Django bietet, sind:
+Die vorhergehenden Abschnitte zeigen die Hauptmerkmale, die Sie in fast jeder Webanwendung verwenden: URL-Mapping, Views, Modelle und Templates. Nur einige der anderen von Django bereitgestellten Funktionen umfassen:
 
-- **Formulare**: HTML-Formulare werden verwendet, um Benutzerdaten zur Verarbeitung auf dem Server zu sammeln. Django vereinfacht die Formularkreation, -validierung und -verarbeitung.
-- **Benutzerauthentifizierung und Berechtigungen**: Django enthält ein robustes System zur Benutzerauthentifizierung und Berechtigungen, das mit Blick auf Sicherheit entwickelt wurde.
-- **Caching**: Das dynamische Erstellen von Inhalten ist viel rechenintensiver (und langsamer) als das Bereitstellen statischer Inhalte. Django bietet flexibles Caching, sodass Sie ganze oder Teile einer gerenderten Seite speichern können, damit sie nur bei Bedarf neu gerendert wird.
-- **Administrationsseite**: Die Django-Administrationsseite ist standardmäßig enthalten, wenn Sie eine App mit dem Basisskelett erstellen. Es macht es trivial einfach, eine Administrationsseite für Site-Administratoren bereitzustellen, um alle Datenmodelle auf Ihrer Site zu erstellen, zu bearbeiten und anzuzeigen.
-- **Daten serialisieren**: Django macht es einfach, Ihre Daten als XML oder JSON zu serialisieren und bereitzustellen. Dies kann nützlich sein, wenn Sie einen Webdienst erstellen (eine Website, die rein als Datenbereitsteller für andere Anwendungen oder Seiten dient und selbst nichts anzeigt) oder wenn Sie eine Website erstellen, auf der der klientseitige Code alle Datenrenders erledigt.
+- **Formulare**: HTML-Formulare werden verwendet, um Benutzerdaten zur Verarbeitung auf dem Server zu sammeln. Django vereinfacht die Formulierung, Validierung und Verarbeitung von Formularen.
+- **Benutzerauthentifizierung und Berechtigungen**: Django enthält ein robustes Benutzerauthentifizierungs- und Berechtigungssystem, das mit dem Gedanken an Sicherheit entwickelt wurde.
+- **Caching**: Dynamisches Erstellen von Inhalten ist viel rechenintensiver (und langsamer) als das Bereitstellen statischer Inhalte. Django bietet flexibles Caching, sodass Sie alle oder Teile einer gerenderten Seite speichern können, damit sie nur bei Bedarf neu gerendert wird.
+- **Verwaltungsseite**: Die Django-Verwaltungsseite ist standardmäßig enthalten, wenn Sie eine App mit dem Basisskelett erstellen. Sie macht es einfach, eine Verwaltungsseite für die Administratoren der Website bereitzustellen, um beliebige Datenmodelle in Ihrer Site zu erstellen, zu bearbeiten und anzuzeigen.
+- **Daten serialisieren**: Django macht es einfach, Ihre Daten als XML oder JSON zu serialisieren und bereitzustellen. Das kann nützlich sein, wenn Sie einen Webservice erstellen (eine Website, die ausschließlich Daten liefert, die von anderen Anwendungen oder Websites konsumiert werden, und selbst nichts anzeigt), oder wenn Sie eine Website erstellen, bei der der clientseitige Code alle Datenrendering übernimmt.
 
 ## Zusammenfassung
 
-Herzlichen Glückwunsch, Sie haben den ersten Schritt Ihrer Django-Reise erfolgreich abgeschlossen! Sie sollten nun die Hauptvorteile von Django verstehen, ein wenig über seine Geschichte wissen und ungefähr wissen, wie die einzelnen Hauptteile einer Django-App aussehen könnten. Sie sollten auch einige Dinge über die Python-Programmiersprache gelernt haben, einschließlich der Syntax für Listen, Funktionen und Klassen.
+Herzlichen Glückwunsch, Sie haben den ersten Schritt in Ihrer Django-Reise abgeschlossen! Sie sollten nun die Hauptvorteile von Django verstehen, ein wenig über seine Geschichte erfahren und ungefähr wissen, wie jeder der Hauptteile einer Django-App aussehen könnte. Sie sollten auch einige Dinge über die Python-Programmiersprache gelernt haben, einschließlich der Syntax für Listen, Funktionen und Klassen.
 
-Sie haben bereits oben einige echte Django-Codes gesehen, aber im Gegensatz zu Client-seitigem Code müssen Sie eine Entwicklungsumgebung einrichten, um ihn auszuführen. Das ist unser nächster Schritt.
+Sie haben oben bereits einige echte Django-Codes gesehen, aber im Gegensatz zu clientseitigem Code müssen Sie eine Entwicklungsumgebung einrichten, um ihn auszuführen. Das ist unser nächster Schritt.
 
 {{NextMenu("Learn/Server-side/Django/development_environment", "Learn/Server-side/Django")}}
diff --git a/files/de/learn/server-side/django/web_application_security/index.md b/files/de/learn/server-side/django/web_application_security/index.md
index dc565b215..70cef7873 100644
--- a/files/de/learn/server-side/django/web_application_security/index.md
+++ b/files/de/learn/server-side/django/web_application_security/index.md
@@ -1,27 +1,27 @@
 ---
-title: Django-Webanwendungssicherheit
+title: Sicherheit von Django-Webanwendungen
 slug: Learn/Server-side/Django/web_application_security
 l10n:
-  sourceCommit: d4c050c653bb05faa1052ecc102b0419cb0a97ce
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{LearnSidebar}}{{PreviousMenuNext("Learn/Server-side/Django/Deployment", "Learn/Server-side/Django/django_assessment_blog", "Learn/Server-side/Django")}}
 
-Der Schutz von Benutzerdaten ist ein wesentlicher Bestandteil jedes Website-Designs. Wir haben in dem Artikel [Web-Sicherheit](/de/docs/Web/Security) einige der gängigsten Sicherheitsbedrohungen erklärt — dieser Artikel bietet eine praktische Demonstration, wie die integrierten Schutzfunktionen von Django solche Bedrohungen handhaben.
+Der Schutz von Benutzerdaten ist ein wesentlicher Bestandteil jedes Webseitendesigns. In dem Artikel [Web-Sicherheit](/de/docs/Web/Security) haben wir bereits einige der häufigeren Sicherheitsbedrohungen erklärt — dieser Artikel bietet eine praktische Darstellung, wie die integrierten Schutzmechanismen von Django solche Bedrohungen handhaben.
 
 <table>
   <tbody>
     <tr>
       <th scope="row">Voraussetzungen:</th>
       <td>
-        Lesen Sie das Thema „<a href="/de/docs/Learn/Server-side/First_steps/Website_security">Websicherheit</a>“ zur serverseitigen Programmierung.
-        Schließen Sie die Django-Tutorial-Themen bis (und inklusive) mindestens <a href="/de/docs/Learn/Server-side/Django/Forms">Django-Tutorial Teil 9: Arbeiten mit Formularen</a> ab.
+        Lesen Sie das Thema „<a href="/de/docs/Learn/Server-side/First_steps/Website_security">Webseitensicherheit</a>“ in der serverseitigen Programmierung.
+        Schließen Sie die Django-Tutorial-Themen mindestens bis (einschließlich) <a href="/de/docs/Learn/Server-side/Django/Forms">Django-Tutorial Teil 9: Arbeiten mit Formularen</a> ab.
       </td>
     </tr>
     <tr>
       <th scope="row">Ziel:</th>
       <td>
-        Die Hauptmaßnahmen zu verstehen, die Sie ergreifen müssen (oder nicht ergreifen dürfen), um Ihre Django-Webanwendung zu sichern.
+        Zu verstehen, welche wesentlichen Maßnahmen Sie ergreifen (oder nicht ergreifen) sollten, um Ihre Django-Webanwendung zu sichern.
       </td>
     </tr>
   </tbody>
@@ -29,38 +29,38 @@ Der Schutz von Benutzerdaten ist ein wesentlicher Bestandteil jedes Website-Desi
 
 ## Übersicht
 
-Das Thema [Web-Sicherheit](/de/docs/Web/Security) bietet einen Überblick darüber, was Websicherheit für serverseitiges Design bedeutet und einige der häufigsten Bedrohungen, gegen die Sie sich schützen sollten. Eine der wichtigsten Botschaften in diesem Artikel ist, dass fast alle Angriffe erfolgreich sind, wenn die Webanwendung den Daten des Browsers vertraut.
+Das Thema [Webseitensicherheit](/de/docs/Web/Security) gibt einen Überblick darüber, was Sicherheit im Web seitens der serverseitigen Gestaltung bedeutet, und über einige der häufigeren Bedrohungen, gegen die Sie sich schützen sollten. Eine der Hauptaussagen in diesem Artikel ist, dass fast alle Angriffe erfolgreich sind, wenn die Webanwendung den Daten des Browsers vertraut.
 
 > [!WARNING]
-> Die wichtigste Lektion, die Sie über die Websicherheit lernen können, ist, **niemals den Daten des Browsers zu vertrauen**. Dies beinhaltet `GET`-Anfragedaten in URL-Parametern, `POST`-Daten, HTTP-Header und Cookies, vom Benutzer hochgeladene Dateien usw. Überprüfen und bereinigen Sie immer alle eingehenden Daten. Gehen Sie immer vom Schlimmsten aus.
+> Die wichtigste Lektion, die Sie zur Websicherheit lernen können, ist, **niemals den Daten des Browsers zu vertrauen**. Dies umfasst `GET`-Anfragedaten in URL-Parametern, `POST`-Daten, HTTP-Header und Cookies, vom Benutzer hochgeladene Dateien usw. Überprüfen und bereinigen Sie immer alle eingehenden Daten. Gehen Sie immer vom Schlimmsten aus.
 
-Die gute Nachricht für Django-Nutzer ist, dass viele der häufigeren Bedrohungen durch das Framework behandelt werden! Der Artikel [Sicherheit in Django](https://docs.djangoproject.com/en/5.0/topics/security/) (Django-Dokumentation) erklärt Djangos Sicherheitsfunktionen und wie man eine von Django betriebene Website sichert.
+Die gute Nachricht für Django-Benutzer ist, dass viele der häufigeren Bedrohungen vom Framework gehandhabt werden! Der Artikel [Sicherheit in Django](https://docs.djangoproject.com/en/5.0/topics/security/) (Django-Dokumentation) erklärt die Sicherheitsmerkmale von Django und wie Sie eine von Django unterstützte Website sichern können.
 
 ## Häufige Bedrohungen/Schutzmaßnahmen
 
-Anstatt die Django-Dokumentation hier zu duplizieren, werden wir in diesem Artikel nur einige der Sicherheitsfunktionen im Kontext unseres Django-[LocalLibrary](/de/docs/Learn/Server-side/Django/Tutorial_local_library_website)-Tutorials demonstrieren.
+Anstatt die Django-Dokumentation hier zu duplizieren, demonstrieren wir in diesem Artikel nur einige der Sicherheitsfunktionen im Kontext unseres Django [LocalLibrary](/de/docs/Learn/Server-side/Django/Tutorial_local_library_website)-Tutorials.
 
-### Cross-Site-Scripting (XSS)
+### Cross-Site Scripting (XSS)
 
-XSS ist ein Begriff zur Beschreibung einer Klasse von Angriffen, die es einem Angreifer ermöglichen, clientseitige Skripte _durch_ die Website in die Browser anderer Benutzer einzuspeisen. Dies wird normalerweise erreicht, indem bösartige Skripte in der Datenbank gespeichert werden, wo sie abgerufen und anderen Benutzern angezeigt werden können, oder indem Benutzer dazu gebracht werden, auf einen Link zu klicken, der dazu führt, dass das JavaScript des Angreifers vom Browser des Benutzers ausgeführt wird.
+XSS ist ein Begriff, der eine Klasse von Angriffen beschreibt, die es einem Angreifer ermöglichen, clientseitige Skripte _über_ die Website in die Browser anderer Benutzer einzuschleusen. Dies wird in der Regel erreicht, indem bösartige Skripte in der Datenbank gespeichert werden, von der aus sie abgerufen und anderen Benutzern angezeigt werden können, oder indem Benutzer dazu gebracht werden, auf einen Link zu klicken, der das JavaScript des Angreifers im Browser des Benutzers ausführt.
 
-Djangos Templatesystem schützt Sie gegen die Mehrheit der XSS-Angriffe, indem es [spezifische Zeichen](https://docs.djangoproject.com/en/5.0/ref/templates/language/#automatic-html-escaping) verhindert, die im HTML "gefährlich" sind. Wir können dies demonstrieren, indem wir versuchen, etwas JavaScript in unsere LocalLibrary-Website einzuspeisen, indem wir das Formular zum Erstellen von Autoren verwenden, das wir im [Django-Tutorial Teil 9: Arbeiten mit Formularen](/de/docs/Learn/Server-side/Django/Forms) eingerichtet haben.
+Das Templatesystem von Django schützt Sie vor den meisten XSS-Angriffen, indem es [bestimmte Zeichen ausblendet](https://docs.djangoproject.com/en/5.0/ref/templates/language/#automatic-html-escaping), die in HTML "gefährlich" sind. Wir können dies demonstrieren, indem wir versuchen, etwas JavaScript in unsere LocalLibrary-Website mithilfe des Formulars zum Erstellen eines Autors einzuschleusen, das wir in [Django-Tutorial Teil 9: Arbeiten mit Formularen](/de/docs/Learn/Server-side/Django/Forms) eingerichtet haben.
 
 1. Starten Sie die Website mit dem Entwicklungsserver (`python3 manage.py runserver`).
-2. Öffnen Sie die Seite in Ihrem lokalen Browser und loggen Sie sich in Ihr Superuser-Konto ein.
-3. Navigieren Sie zur Autorenerstellungsseite (die sich unter der URL befinden sollte: `http://127.0.0.1:8000/catalog/author/create/`).
-4. Geben Sie Namen und Datumsangaben für einen neuen Benutzer ein und fügen Sie dann den folgenden Text dem Feld Nachname hinzu:
+2. Öffnen Sie die Seite in Ihrem lokalen Browser und melden Sie sich mit Ihrem Superuser-Konto an.
+3. Navigieren Sie zur Autorenerstellungsseite (die sich unter der URL `http://127.0.0.1:8000/catalog/author/create/` befinden sollte).
+4. Geben Sie Namen und Datumsangaben für einen neuen Benutzer ein und fügen Sie dann den folgenden Text am Ende des Feldes für den Nachnamen hinzu:
    `<script>alert('Test alert');</script>`.
-   ![Autorenformular XSS Test](author_create_form_alert_xss.png)
+   ![Author Form XSS test](author_create_form_alert_xss.png)
 
    > [!NOTE]
-   > Dies ist ein harmloses Skript, das, wenn es ausgeführt wird, ein Warnfenster in Ihrem Browser anzeigt. Wenn die Warnung beim Absenden des Datensatzes angezeigt wird, ist die Seite anfällig für XSS-Bedrohungen.
+   > Dies ist ein harmloses Skript, das, falls ausgeführt, ein Alarmfeld in Ihrem Browser anzeigt. Wenn der Alarm beim Einreichen des Datensatzes angezeigt wird, ist die Seite anfällig für XSS-Bedrohungen.
 
 5. Drücken Sie **Senden**, um den Datensatz zu speichern.
-6. Wenn Sie den Autor speichern, wird er wie unten angezeigt. Aufgrund der XSS-Schutzeinrichtungen sollte das `alert()` nicht ausgeführt werden. Stattdessen wird das Skript als Klartext angezeigt.
-   ![Autoren-Detailansicht XSS Test](author_detail_alert_xss.png)
+6. Wenn Sie den Autor speichern, wird er wie unten dargestellt angezeigt. Aufgrund der XSS-Schutzmaßnahmen sollte das `alert()` nicht ausgeführt werden. Stattdessen wird das Skript als Klartext angezeigt.
+   ![Author detail view XSS test](author_detail_alert_xss.png)
 
-Wenn Sie den HTML-Quellcode der Seite anzeigen, können Sie sehen, dass die gefährlichen Zeichen für die Skript-Tags in ihre harmlosen Escape-Code-Äquivalente umgewandelt wurden (zum Beispiel ist `>` jetzt `&gt;`).
+Wenn Sie den HTML-Quellcode der Seite ansehen, können Sie sehen, dass die gefährlichen Zeichen für die Skripttags in ihre harmlosen Escape-Code-Äquivalente umgewandelt wurden (zum Beispiel wird `>` zu `&gt;`).
 
 ```html
 <h1>
@@ -69,19 +69,19 @@ Wenn Sie den HTML-Quellcode der Seite anzeigen, können Sie sehen, dass die gef
 </h1>
 ```
 
-Die Verwendung von Django-Templates schützt Sie vor den meisten XSS-Angriffen. Es ist jedoch möglich, diesen Schutz zu deaktivieren, und der Schutz wird nicht automatisch auf alle Tags angewendet, die normalerweise nicht von Benutzereingaben gefüllt werden (zum Beispiel wird der `help_text` in einem Formularfeld normalerweise nicht vom Benutzer geliefert, sodass Django diese Werte nicht maskiert).
+Die Verwendung von Django-Templates schützt Sie vor der Mehrheit der XSS-Angriffe. Es ist jedoch möglich, diesen Schutz zu deaktivieren, und der Schutz wird nicht automatisch auf alle Tags angewendet, die normalerweise nicht mit Benutzereingaben gefüllt werden (zum Beispiel wird der `help_text` in einem Formularfeld normalerweise nicht durch Benutzereingaben bereitgestellt, daher entzieht Django diese Werte nicht der Escape-Funktion).
 
-Es ist auch möglich, dass XSS-Angriffe von anderen nicht vertrauenswürdigen Datenquellen ausgehen, wie Cookies, Webdiensten oder hochgeladenen Dateien (wann immer die Daten nicht ausreichend bereinigt sind, bevor sie auf einer Seite eingeschlossen werden). Wenn Sie Daten aus diesen Quellen anzeigen, müssen Sie möglicherweise Ihren eigenen Bereinigungscode hinzufügen.
+Es ist auch möglich, dass XSS-Angriffe aus anderen nicht vertrauenswürdigen Datenquellen stammen, wie Cookies, Webdiensten oder hochgeladenen Dateien (wenn die Daten nicht ausreichend bereinigt werden, bevor sie in eine Seite aufgenommen werden). Wenn Sie Daten aus diesen Quellen anzeigen, müssen Sie möglicherweise Ihren eigenen Bereinigungscode hinzufügen.
 
-### Schutz vor Cross-Site-Request-Forgery (CSRF)
+### Cross-Site Request Forgery (CSRF)-Schutz
 
-CSRF-Angriffe ermöglichen es einem böswilligen Benutzer, Aktionen unter Verwendung der Anmeldeinformationen eines anderen Benutzers ohne dessen Wissen oder Zustimmung auszuführen. Betrachten Sie zum Beispiel den Fall, in dem wir einen Hacker haben, der zusätzliche Autoren für unsere LocalLibrary erstellen möchte.
+CSRF-Angriffe ermöglichen es einem bösartigen Benutzer, Aktionen mithilfe der Anmeldedaten eines anderen Benutzers auszuführen, ohne das Wissen oder die Zustimmung dieses Benutzers. Betrachten Sie beispielsweise den Fall, in dem wir einen Hacker haben, der zusätzliche Autoren für unsere LocalLibrary erstellen möchte.
 
 > [!NOTE]
-> Offensichtlich ist unser Hacker nicht wegen des Geldes dabei! Ein ambitionierterer Hacker könnte den gleichen Ansatz auf anderen Seiten verwenden, um viel schädlichere Aufgaben auszuführen (wie z.B. das Überweisen von Geld auf ihre eigenen Konten usw.).
+> Offensichtlich ist unser Hacker nicht auf Geld aus! Ein ehrgeizigerer Hacker könnte denselben Ansatz auf anderen Seiten nutzen, um viel schädlichere Aufgaben auszuführen (wie z. B. Geld auf seine eigenen Konten zu übertragen usw.).
 
-Um dies zu erreichen, könnte er eine HTML-Datei wie die unten stehende erstellen, die ein Autorenformular (wie das, das wir im vorherigen Abschnitt verwendet haben) enthält, das gesendet wird, sobald die Datei geladen wird.
-Er würde die Datei dann an alle Bibliothekare senden und vorschlagen, dass sie die Datei öffnen (sie enthält einige harmlose Informationen, ehrlich!). Wenn die Datei von einem angemeldeten Bibliothekar geöffnet wird, würde das Formular mit seinen Anmeldeinformationen gesendet und ein neuer Autor würde erstellt.
+Um dies zu tun, könnte er eine HTML-Datei wie die untenstehende erstellen, die ein Autorenerstellungs-Formular enthält (ähnlich dem, das wir im vorherigen Abschnitt verwendet haben), das sofort abgesendet wird, wenn die Datei geladen wird.
+Er würde die Datei dann an alle Bibliothekare senden und vorschlagen, dass sie die Datei öffnen (sie enthält einige harmlose Informationen, ehrlich!). Wenn die Datei von einem angemeldeten Bibliothekar geöffnet wird, wird das Formular mit deren Anmeldedaten abgesendet, und ein neuer Autor wird erstellt.
 
 ```html
 <html lang="en">
@@ -138,9 +138,9 @@ Er würde die Datei dann an alle Bibliothekare senden und vorschlagen, dass sie
 </html>
 ```
 
-Führen Sie den Entwicklungswebserver aus und loggen Sie sich mit Ihrem Superuser-Konto ein. Kopieren Sie den obigen Text in eine Datei und öffnen Sie sie im Browser. Sie sollten einen CSRF-Fehler erhalten, da Django einen Schutz gegen diese Art von Angriff hat!
+Führen Sie den Entwicklungs-Webserver aus, und melden Sie sich mit Ihrem Superuser-Konto an. Kopieren Sie den obigen Text in eine Datei und öffnen Sie ihn dann im Browser. Sie sollten einen CSRF-Fehler erhalten, da Django einen Schutz dagegen bietet!
 
-Der Schutz wird aktiviert, indem Sie das `{% csrf_token %}` Template-Tag in Ihre Formular-Definition aufnehmen. Dieses Token wird dann in Ihrem HTML wie unten gezeigt dargestellt, mit einem Wert, der spezifisch für den Benutzer im aktuellen Browser ist.
+Wie der Schutz aktiviert ist, erfolgt dadurch, dass Sie das Template-Tag `{% csrf_token %}` in Ihre Formulardefinition einfügen. Dieses Token wird dann in Ihrem HTML wie unten gezeigt gerendert, mit einem für den Benutzer im aktuellen Browser spezifischen Wert.
 
 ```html
 <input
@@ -149,43 +149,43 @@ Der Schutz wird aktiviert, indem Sie das `{% csrf_token %}` Template-Tag in Ihre
   value="0QRWHnYVg776y2l66mcvZqp8alrv4lb8S8lZ4ZJUWGZFA5VHrVfL2mpH29YZ39PW" />
 ```
 
-Django generiert einen nutzer-/browser-spezifischen Schlüssel und lehnt Formulare ab, die das Feld nicht enthalten oder die für den Nutzer/Browser einen falschen Feldwert enthalten.
+Django generiert einen für Benutzer/Browser spezifischen Schlüssel und lehnt Formulare ab, die das Feld nicht enthalten oder die ein inkorrektes Feld für den Benutzer/Browser enthalten.
 
-Um diese Art von Angriff zu verwenden, muss der Hacker nun den CSRF-Schlüssel für den spezifischen Zielbenutzer entdecken und einbeziehen. Zudem kann er nicht die „Streuangriffs“-Methode verwenden, indem er eine bösartige Datei an alle Bibliothekare sendet und darauf hofft, dass einer von ihnen sie öffnet, da der CSRF-Schlüssel browserspezifisch ist.
+Um diese Art von Angriff zu nutzen, muss der Hacker nun den CSRF-Schlüssel für den spezifischen Zielbenutzer entdecken und einfügen. Er kann auch nicht mehr die „Streuschuss“-Methode anwenden, bei der er eine bösartige Datei an alle Bibliothekare sendet und hofft, dass sie von einem von ihnen geöffnet wird, da der CSRF-Schlüssel browserspezifisch ist.
 
-Djangos CSRF-Schutz ist standardmäßig aktiviert. Sie sollten immer das `{% csrf_token %}` Template-Tag in Ihren Formularen verwenden und `POST` für Anfragen verwenden, die Daten in der Datenbank ändern oder hinzufügen könnten.
+Der CSRF-Schutz von Django ist standardmäßig aktiviert. Sie sollten immer das Template-Tag `{% csrf_token %}` in Ihren Formularen verwenden und `POST` für Anfragen nutzen, die Daten in die Datenbank ändern oder hinzufügen könnten.
 
-### Andere Schutzmaßnahmen
+### Weitere Schutzmaßnahmen
 
-Django bietet auch andere Formen des Schutzes (die meisten wären schwer oder nicht besonders nützlich zu demonstrieren):
+Django bietet auch andere Formen des Schutzes (die meisten davon wären schwer oder nicht besonders nützlich zu demonstrieren):
 
 - Schutz vor SQL-Injection
-  - : SQL-Injection-Schwachstellen ermöglichen es böswilligen Benutzern, beliebigen SQL-Code auf einer Datenbank auszuführen und so Daten unabhängig von den Benutzerberechtigungen zuzugreifen, zu ändern oder zu löschen. Fast in jedem Fall werden Sie auf die Datenbank mit Hilfe von Djangos Querysets/Modellen zugreifen, sodass das resultierende SQL vom zugrunde liegenden Datenbanktreiber korrekt maskiert wird. Wenn Sie rohe Abfragen oder benutzerdefiniertes SQL schreiben müssen, müssen Sie explizit über die Verhinderung von SQL-Injection nachdenken.
+  - : SQL-Injection-Schwachstellen ermöglichen es bösartigen Benutzern, beliebigen SQL-Code auf einer Datenbank auszuführen, wodurch Daten unabhängig von den Berechtigungen des Benutzers abgerufen, geändert oder gelöscht werden können. In fast jedem Fall greifen Sie auf die Datenbank mit den Abfrage-Sets/Modellen von Django zu, sodass der resultierende SQL-Code vom zugrunde liegenden Datenbanktreiber korrekt bereinigt wird. Wenn Sie rohe Abfragen oder benutzerdefinierte SQL schreiben müssen, sollten Sie ausdrücklich über den Schutz vor SQL-Injections nachdenken.
 - Schutz vor Clickjacking
-  - : Bei diesem Angriff entführt ein böswilliger Benutzer Klicks, die für eine sichtbare Top-Level-Site bestimmt sind und leitet sie auf eine darunter liegende, versteckte Seite um. Diese Technik könnte verwendet werden, um beispielsweise eine legitime Bank-Website anzuzeigen, jedoch die Anmeldedaten in einem unsichtbaren [`<iframe>`](/de/docs/Web/HTML/Element/iframe), das vom Angreifer kontrolliert wird, zu erfassen. Django enthält {{Glossary("Clickjacking", "Clickjacking")}}-Schutz in Form der [`X-Frame-Options` Middleware](https://docs.djangoproject.com/en/4.0/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware), die in einem unterstützenden Browser verhindern kann, dass eine Site in einem Frame gerendert wird.
-- Durchsetzung von TLS/HTTPS
-  - : TLS/HTTPS kann auf dem Webserver aktiviert werden, um den gesamten Verkehr zwischen der Seite und dem Browser zu verschlüsseln, einschließlich Authentifizierungsdaten, die andernfalls im Klartext gesendet würden (die Aktivierung von HTTPS wird dringend empfohlen). Wenn HTTPS aktiviert ist, bietet Django eine Reihe von weiteren Schutzmöglichkeiten:
-    - [`SECURE_PROXY_SSL_HEADER`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER) kann verwendet werden, um zu überprüfen, ob der Inhalt sicher ist, selbst wenn er von einem nicht-HTTP-Proxy stammt.
+  - : Bei diesem Angriff kapert ein bösartiger Benutzer Klicks, die für eine sichtbare oberste Webseite bestimmt sind, und leitet sie auf eine versteckte Seite darunter weiter. Diese Technik könnte zum Beispiel verwendet werden, um eine legitime Bankseite anzuzeigen, aber die Anmeldedaten in einem unsichtbaren [`<iframe>`](/de/docs/Web/HTML/Element/iframe) zu erfassen, das vom Angreifer kontrolliert wird. Django enthält [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking)-Schutz in Form des [`X-Frame-Options` Mittelware](https://docs.djangoproject.com/en/4.0/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware), die in einem unterstützenden Browser verhindern kann, dass eine Seite innerhalb eines Rahmens gerendert wird.
+- Erzwingen von TLS/HTTPS
+  - : TLS/HTTPS kann auf dem Webserver aktiviert werden, um den gesamten Datenverkehr zwischen der Seite und dem Browser zu verschlüsseln, einschließlich der Authentifizierungs-Credentials, die ansonsten im Klartext gesendet würden (die Aktivierung von HTTPS wird dringend empfohlen). Wenn HTTPS aktiviert ist, bietet Django eine Reihe weiterer Schutzmaßnahmen, die Sie nutzen können:
+    - [`SECURE_PROXY_SSL_HEADER`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER) kann verwendet werden, um zu überprüfen, ob der Inhalt sicher ist, selbst wenn er von einem nicht HTTP-Proxy kommt.
     - [`SECURE_SSL_REDIRECT`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_SSL_REDIRECT) wird verwendet, um alle HTTP-Anfragen auf HTTPS umzuleiten.
-    - Verwendung von [HTTP Strict Transport Security](https://docs.djangoproject.com/en/5.0/ref/middleware/#http-strict-transport-security) (HSTS). Dies ist ein HTTP-Header, der einen Browser darüber informiert, dass alle zukünftigen Verbindungen zu einer bestimmten Site immer HTTPS verwenden sollten. In Kombination mit der Umleitung von HTTP-Anfragen auf HTTPS stellt diese Einstellung sicher, dass nach einer erfolgreichen Verbindung stets HTTPS verwendet wird. HSTS kann entweder mit [`SECURE_HSTS_SECONDS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_HSTS_SECONDS) und [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) oder auf dem Webserver konfiguriert werden.
-    - Verwendung „sicherer“ Cookies durch Setzen der Einstellungen [`SESSION_COOKIE_SECURE`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SESSION_COOKIE_SECURE) und [`CSRF_COOKIE_SECURE`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-CSRF_COOKIE_SECURE) auf `True`. Dies stellt sicher, dass Cookies nur über HTTPS gesendet werden.
-- Host-Header-Validierung
-  - : Verwendung von [`ALLOWED_HOSTS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-ALLOWED_HOSTS), um nur Anfragen von vertrauenswürdigen Hosts zu akzeptieren.
+    - Verwenden Sie [HTTP Strict Transport Security](https://docs.djangoproject.com/en/5.0/ref/middleware/#http-strict-transport-security) (HSTS). Dies ist ein HTTP-Header, der einen Browser darauf hinweist, dass alle zukünftigen Verbindungen zu einer bestimmten Seite immer HTTPS verwenden sollten. In Kombination mit der Umleitung von HTTP-Anfragen zu HTTPS stellt diese Einstellung sicher, dass immer HTTPS verwendet wird, nachdem eine erfolgreiche Verbindung erfolgt ist. HSTS kann entweder mit [`SECURE_HSTS_SECONDS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_HSTS_SECONDS) und [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) oder auf dem Webserver konfiguriert werden.
+    - Verwenden Sie 'sichere' Cookies, indem Sie [`SESSION_COOKIE_SECURE`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SESSION_COOKIE_SECURE) und [`CSRF_COOKIE_SECURE`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-CSRF_COOKIE_SECURE) auf `True` setzen. Dies stellt sicher, dass Cookies nur über HTTPS gesendet werden.
+- Validierung von Host-Headern
+  - : Verwenden Sie [`ALLOWED_HOSTS`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-ALLOWED_HOSTS), um nur Anfragen von vertrauenswürdigen Hosts zu akzeptieren.
 
-Es gibt viele weitere Schutzmaßnahmen und Vorbehalte bei der Verwendung der oben genannten Mechanismen. Obwohl wir hoffen, dass dies Ihnen einen Überblick über das bietet, was Django bietet, sollten Sie dennoch die Django-Sicherheitsdokumentation lesen.
+Es gibt viele weitere Schutzmaßnahmen und Einschränkungen bei der Verwendung der oben genannten Mechanismen. Obwohl wir hoffen, dass dies Ihnen einen Überblick darüber gibt, was Django bietet, sollten Sie dennoch die Django-Sicherheitsdokumentation lesen.
 
 ## Zusammenfassung
 
-Django bietet effektive Schutzmaßnahmen gegen eine Reihe häufiger Bedrohungen, einschließlich XSS- und CSRF-Angriffen. In diesem Artikel haben wir demonstriert, wie diese speziellen Bedrohungen von Django in unserer _LocalLibrary_-Website gehandhabt werden. Wir haben auch einen kurzen Überblick über einige der anderen Schutzmaßnahmen gegeben.
+Django bietet effektive Schutzmechanismen gegen eine Reihe von häufigen Bedrohungen, einschließlich XSS- und CSRF-Angriffen. In diesem Artikel haben wir demonstriert, wie diese besonderen Bedrohungen von Django in unserer _LocalLibrary_ Website behandelt werden. Wir haben auch einen kurzen Überblick über einige der anderen Schutzmechanismen gegeben.
 
-Dies war ein sehr kurzer Ausflug in die Web-Sicherheit. Wir empfehlen dringend, dass Sie [Sicherheit in Django](https://docs.djangoproject.com/en/5.0/topics/security/) lesen, um ein tieferes Verständnis zu erlangen.
+Dies war ein sehr kurzer Ausflug in die Websicherheit. Wir empfehlen dringend, [Sicherheit in Django](https://docs.djangoproject.com/en/5.0/topics/security/) zu lesen, um ein tieferes Verständnis zu erlangen.
 
 Der nächste und letzte Schritt in diesem Modul über Django ist die Durchführung der [Bewertungsaufgabe](/de/docs/Learn/Server-side/Django/django_assessment_blog).
 
 ## Siehe auch
 
 - [Sicherheit im Web](/de/docs/Web/Security)
-- [Praktische Leitfäden zur Sicherheitsimplementierung](/de/docs/Web/Security/Practical_implementation_guides)
+- [Praktische Implementierungsleitfäden zur Sicherheit](/de/docs/Web/Security/Practical_implementation_guides)
 - [Sicherheit in Django](https://docs.djangoproject.com/en/5.0/topics/security/) (Django-Dokumentation)
 
 {{PreviousMenuNext("Learn/Server-side/Django/Deployment", "Learn/Server-side/Django/django_assessment_blog", "Learn/Server-side/Django")}}
diff --git a/files/de/learn/server-side/first_steps/website_security/index.md b/files/de/learn/server-side/first_steps/website_security/index.md
index fe8c55262..2d2552122 100644
--- a/files/de/learn/server-side/first_steps/website_security/index.md
+++ b/files/de/learn/server-side/first_steps/website_security/index.md
@@ -2,12 +2,12 @@
 title: Website-Sicherheit
 slug: Learn/Server-side/First_steps/Website_security
 l10n:
-  sourceCommit: 8c36614793c9feadf8fea07fd10b6372be4fd179
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{LearnSidebar}}{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}
 
-Website-Sicherheit erfordert Wachsamkeit in allen Aspekten des Webdesigns und der Nutzung. Dieser einführende Artikel macht Sie zwar nicht zu einem Website-Sicherheitsguru, aber er hilft Ihnen zu verstehen, woher Bedrohungen kommen und was Sie tun können, um Ihre Webanwendung gegen die häufigsten Angriffe zu schützen.
+Website-Sicherheit erfordert Wachsamkeit in allen Aspekten der Website-Gestaltung und -Nutzung. Dieser einführende Artikel wird Sie nicht zu einem Experten für Website-Sicherheit machen, aber er wird Ihnen helfen zu verstehen, woher Bedrohungen kommen und was Sie tun können, um Ihre Webanwendung gegen die gängigsten Angriffe zu schützen.
 
 <table>
   <tbody>
@@ -18,8 +18,8 @@ Website-Sicherheit erfordert Wachsamkeit in allen Aspekten des Webdesigns und de
     <tr>
       <th scope="row">Ziel:</th>
       <td>
-        Die häufigsten Bedrohungen für die Sicherheit von Webanwendungen zu verstehen und
-        was Sie tun können, um das Risiko eines Angriffs auf Ihre Seite zu verringern.
+        Das Verständnis der häufigsten Bedrohungen für die Sicherheit von Webanwendungen und
+        was Sie tun können, um das Risiko eines Hacking-Angriffs auf Ihre Website zu verringern.
       </td>
     </tr>
   </tbody>
@@ -27,131 +27,131 @@ Website-Sicherheit erfordert Wachsamkeit in allen Aspekten des Webdesigns und de
 
 ## Was ist Website-Sicherheit?
 
-Das Internet ist ein gefährlicher Ort! Mit großer Regelmäßigkeit hören wir von Websites, die aufgrund von Denial-of-Service-Angriffen nicht verfügbar sind oder veränderte (und oft schädliche) Informationen auf ihren Startseiten anzeigen. In anderen prominenten Fällen wurden Millionen von Passwörtern, E-Mail-Adressen und Kreditkartendaten in die Öffentlichkeit geleakt, was die Benutzer von Websites sowohl persönlichem Unbehagen als auch finanziellem Risiko aussetzt.
+Das Internet ist ein gefährlicher Ort! Mit großer Regelmäßigkeit hören wir davon, dass Websites aufgrund von Denial-of-Service-Angriffen nicht verfügbar werden oder modifizierte (und oft schädliche) Informationen auf ihren Startseiten anzeigen. In anderen aufsehenerregenden Fällen wurden Millionen von Passwörtern, E-Mail-Adressen und Kreditkartendaten in der Öffentlichkeit bekannt, wodurch Website-Nutzer sowohl persönlicher Verlegenheit als auch finanziellem Risiko ausgesetzt sind.
 
-Zweck der Website-Sicherheit ist es, diese (oder jegliche) Arten von Angriffen zu verhindern. Die formellere Definition von Website-Sicherheit _ist die Praxis des Schutzes von Websites vor unautorisiertem Zugriff, Nutzung, Änderung, Zerstörung oder Störung_.
+Zweck der Website-Sicherheit ist es, diese (oder ähnliche) Arten von Angriffen zu verhindern. Die formellere Definition von Website-Sicherheit _ist der Akt/die Praxis, Websites vor unbefugtem Zugriff, Nutzung, Modifikation, Zerstörung oder Störung zu schützen_.
 
-Effektive Website-Sicherheit erfordert Designaufwand über die gesamte Website: in Ihrer Webanwendung, der Konfiguration des Webservers, Ihren Richtlinien zur Erstellung und Erneuerung von Passwörtern sowie im clientseitigen Code. Auch wenn all das sehr bedrohlich klingt, ist die gute Nachricht, dass Sie bei Verwendung eines serverseitigen Web-Frameworks fast immer robusten und gut durchdachten Abwehrmechanismen gegen eine Reihe der häufigsten Angriffe „standardmäßig“ haben werden. Andere Angriffe können durch die Konfiguration Ihres Webservers abgeschwächt werden, zum Beispiel durch die Aktivierung von HTTPS. Schließlich gibt es öffentlich verfügbare Schwachstellen-Scanner-Tools, die Ihnen helfen können herauszufinden, ob Sie offensichtliche Fehler gemacht haben.
+Effektive Website-Sicherheit erfordert Designaufwand über die gesamte Website hinweg: in Ihrer Webanwendung, der Konfiguration des Webservers, Ihren Richtlinien zur Erstellung und Erneuerung von Passwörtern und dem Client-seitigen Code. Während all das sehr bedrohlich klingt, ist die gute Nachricht, dass, wenn Sie ein serverseitiges Web-Framework verwenden, es fast mit Sicherheit "standardmäßig" robuste und durchdachte Abwehrmechanismen gegen eine Reihe der häufigsten Angriffe bereitstellen wird. Andere Angriffe können durch Ihre Webserver-Konfiguration abgeschwächt werden, beispielsweise durch die Aktivierung von HTTPS. Schließlich gibt es öffentlich zugängliche Tools zur Verwundbarkeitsscanner, die Ihnen helfen können festzustellen, ob Sie offensichtliche Fehler gemacht haben.
 
-Der Rest dieses Artikels gibt Ihnen weitere Details über einige häufige Bedrohungen und einige einfache Schritte, die Sie zum Schutz Ihrer Seite unternehmen können.
+Der Rest dieses Artikels gibt Ihnen mehr Details über einige der häufigsten Bedrohungen und einige der einfachen Schritte, die Sie unternehmen können, um Ihre Website zu schützen.
 
 > [!NOTE]
-> Dies ist ein Einführungsthema, das Ihnen helfen soll, über Website-Sicherheit nachzudenken, aber es ist nicht erschöpfend.
+> Dies ist ein einführendes Thema, das Ihnen helfen soll, über Website-Sicherheit nachzudenken, jedoch ist es nicht erschöpfend.
 
-## Bedrohungen für die Website-Sicherheit
+## Website-Sicherheitsbedrohungen
 
-In diesem Abschnitt werden einige der häufigsten Website-Bedrohungen und deren Abwehr aufgelistet. Beachten Sie beim Lesen, dass Bedrohungen am erfolgreichsten sind, wenn die Webanwendung entweder dem vom Browser kommenden Daten vertraut oder _nicht paranoid genug_ ist.
+Dieser Abschnitt listet nur einige der häufigsten Website-Bedrohungen und deren Abmilderung auf. Beachten Sie beim Lesen, wie Bedrohungen am erfolgreichsten sind, wenn die Webanwendung entweder dem Datenstrom aus dem Browser vertraut oder _nicht paranoid genug_ gegenüber diesen Daten ist.
 
 ### Cross-Site Scripting (XSS)
 
-XSS ist ein Begriff, der eine Klasse von Angriffen beschreibt, die es einem Angreifer ermöglichen, clientseitige Skripte _über_ die Website in die Browser anderer Benutzer zu injizieren. Da der injizierte Code vom Browser als vertrauenswürdig angesehen wird, kann der Code Dinge wie das Senden des Autorisierungs-Cookies des Benutzers an den Angreifer ausführen. Wenn der Angreifer das Cookie hat, kann er sich auf der Seite anmelden, als wäre er der Benutzer, und alles tun, was der Benutzer tun kann, wie den Zugriff auf seine Kreditkartendetails zu erhalten, Kontaktdaten einzusehen oder Passwörter zu ändern.
+XSS ist ein Begriff, der eine Klasse von Angriffen beschreibt, die es einem Angreifer ermöglichen, clientseitige Skripte _über_ die Website in die Browser anderer Nutzer einzuschleusen. Da der eingeschleuste Code vom Browser von der Website kommt, wird der Code _vertraut_ und kann Dinge tun, wie das Autorisierungscookie des Nutzers an den Angreifer senden. Hat der Angreifer das Cookie, kann er sich in eine Website einloggen, als wäre er der Nutzer, und alles tun, was der Nutzer tun kann, wie z.B. Zugriff auf deren Kreditkartendetails, Kontaktdaten einsehen oder Passwörter ändern.
 
 > [!NOTE]
-> XSS-Schwachstellen waren historisch gesehen häufiger als jede andere Art von Sicherheitsbedrohung.
+> XSS-Sicherheitslücken sind historisch häufiger als jede andere Art von Sicherheitsbedrohung aufgetreten.
 
-Die XSS-Schwachstellen werden in _reflektiert_ und _persistent_ unterteilt, basierend darauf, wie die Website die injizierten Skripte an einen Browser zurückgibt.
+Die XSS-Schwachstellen werden in _reflektiert_ und _persistent_ unterteilt, basierend darauf, wie die Website die eingefügten Skripte an den Browser zurückgibt.
 
-- Eine _reflektierte_ XSS-Schwachstelle tritt auf, wenn vom Nutzer übergebener Inhalt, der an den Server gesendet wird, _sofort_ und _unverändert_ zur Anzeige im Browser zurückgegeben wird. Alle Skripte im ursprünglichen Nutzerinhalt werden beim Laden der neuen Seite ausgeführt.
-  Stellen Sie sich beispielsweise eine Suche auf einer Website vor, bei der die Suchbegriffe als URL-Parameter codiert sind und diese Begriffe zusammen mit den Ergebnissen angezeigt werden. Ein Angreifer kann einen Suchlink konstruieren, der ein bösartiges Skript als Parameter enthält (z. B. `https://developer.mozilla.org?q=bier<script%20src="http://example.com/tricky.js"></script>`) und ihn an einen anderen Benutzer senden. Wenn der Zielbenutzer auf diesen „interessanten Link“ klickt, wird das Skript ausgeführt, wenn die Suchergebnisse angezeigt werden. Wie bereits besprochen, gibt dies dem Angreifer alle Informationen, die er benötigt, um sich als Zielbenutzer auf der Website anzumelden, möglicherweise Käufe im Namen des Benutzers zu tätigen oder dessen Kontaktinformationen zu teilen.
-- Eine _persistente_ XSS-Schwachstelle tritt auf, wenn das bösartige Skript auf der Website _gespeichert_ wird und dann später unverändert für andere Benutzer wiedergegeben wird, die es unwissentlich ausführen.
-  Stellen Sie sich beispielsweise ein Diskussionsforum vor, das Kommentare akzeptiert, die unverändertes HTML enthalten können, und wo ein bösartiges Skript von einem Angreifer gespeichert werden könnte. Wenn die Kommentare angezeigt werden, wird das Skript ausgeführt und kann dem Angreifer die Informationen senden, die erforderlich sind, um auf das Benutzerkonto zuzugreifen. Diese Art von Angriff ist extrem populär und mächtig, da der Angreifer möglicherweise überhaupt keinen direkten Kontakt mit den Opfern hat.
+- Eine _reflektierte_ XSS-Schwachstelle tritt auf, wenn vom Nutzer bereitgestellte Inhalte, die an den Server gesendet werden, _sofort_ und _unverändert_ zur Anzeige im Browser zurückgegeben werden. Alle Skripte in den ursprünglichen Nutzerinhalten werden ausgeführt, sobald die neue Seite geladen wird.
+  Betrachten Sie beispielsweise eine Websitesuchfunktion, bei der die Suchbegriffe als URL-Parameter kodiert sind und diese Begriffe zusammen mit den Ergebnissen angezeigt werden. Ein Angreifer kann einen Suchlink konstruieren, der ein bösartiges Skript als Parameter enthält (z.B. `https://developer.mozilla.org?q=beer<script%20src="http://example.com/tricky.js"></script>`) und diesen an einen anderen Nutzer senden. Wenn der Zielnutzer auf diesen "interessanten Link" klickt, wird das Skript ausgeführt, sobald die Suchergebnisse angezeigt werden. Wie bereits erwähnt, gibt dies dem Angreifer alle Informationen, die er benötigt, um sich als Zielnutzer auf der Website anzumelden, möglicherweise Käufe als der Nutzer zu tätigen oder seine Kontaktdaten zu teilen.
+- Eine _persistente_ XSS-Schwachstelle tritt auf, wenn das bösartige Skript auf der Website _gespeichert_ wird und später unverändert erneut angezeigt wird, sodass andere Nutzer es ungewollt ausführen.
+  Beispielsweise könnte ein Diskussionsforum, das Kommentare akzeptiert, die nicht modifizierte HTML enthalten, ein bösartiges Skript von einem Angreifer speichern. Wenn die Kommentare angezeigt werden, wird das Skript ausgeführt und kann dem Angreifer die erforderlichen Informationen senden, um auf das Benutzerkonto zuzugreifen. Diese Art von Angriff ist äußerst populär und mächtig, da der Angreifer möglicherweise nicht einmal direkten Kontakt mit den Opfern hat.
 
-Während die Daten aus `POST`- oder `GET`-Anfragen die häufigste Quelle für XSS-Schwachstellen sind, sind alle vom Browser kommenden Daten potenziell anfällig, wie z.B. Cookie-Daten, die vom Browser angezeigt werden, oder vom Benutzer hochgeladene und angezeigte Dateien.
+Obwohl die Daten aus `POST`- oder `GET`-Anfragen die häufigste Quelle für XSS-Schwachstellen sind, sind alle vom Browser kommenden Daten potenziell anfällig, wie z.B. Cookiedaten, die vom Browser gerendert werden, oder vom Nutzer hochgeladene und angezeigte Dateien.
 
-Die beste Verteidigung gegen XSS-Schwachstellen besteht darin, jegliche Markups zu entfernen oder zu deaktivieren, die potenziell Anweisungen zur Code-Ausführung enthalten können. Für HTML umfasst dies Elemente wie `<script>`, `<object>`, `<embed>` und `<link>`.
+Die beste Verteidigung gegen XSS-Schwachstellen besteht darin, jede Markierung zu entfernen oder zu deaktivieren, die potenziell Anweisungen enthält, Code auszuführen. Für HTML umfasst dies Elemente wie `<script>`, `<object>`, `<embed>` und `<link>`.
 
-Der Prozess der Änderung von Benutzerdaten, damit sie nicht zur Ausführung von Skripten oder zur Beeinflussung der Ausführung von Servercode genutzt werden können, wird als Eingabe-Sanitisierung bezeichnet. Viele Web-Frameworks sanitisieren standardmäßig Benutzereingaben aus HTML-Formularen.
+Der Prozess, Nutzerdaten so zu modifizieren, dass sie nicht zur Ausführung von Skripten oder zur Beeinflussung der Ausführung von Servercode verwendet werden können, wird als Eingabesäuberung (input sanitization) bezeichnet. Viele Web-Frameworks bereinigen standardmäßig Nutzereingaben aus HTML-Formularen automatisch.
 
 ### SQL-Injection
 
-SQL-Injection-Lücken ermöglichen es böswilligen Benutzern, willkürlichen SQL-Code auf einer Datenbank auszuführen, sodass Daten unabhängig von den Berechtigungen des Benutzers abgerufen, geändert oder gelöscht werden können. Ein erfolgreicher Injektionsangriff kann Identitäten vortäuschen, neue Identitäten mit Administratorrechten erstellen, auf alle Daten auf dem Server zugreifen oder die Daten zerstören/ändern, sodass sie unbrauchbar werden.
+SQL-Injection-Schwachstellen ermöglichen es bösartigen Nutzern, beliebigen SQL-Code auf einer Datenbank auszuführen, wobei sie erlauben, auf Daten zuzugreifen, diese zu ändern oder zu löschen, unabhängig von den Nutzerberechtigungen. Ein erfolgreicher Injection-Angriff könnte Identitäten vortäuschen, neue Identitäten mit Administrationsrechten erstellen, auf alle Daten auf dem Server zugreifen oder die Daten zerstören/verändern, um sie unbrauchbar zu machen.
 
-SQL-Injection-Arten umfassen Fehler-basierte SQL-Injections, SQL-Injections basierend auf booleschen Fehlern und zeitbasierte SQL-Injections.
+SQL-Injection-Typen umfassen Error-basierte SQL-Injection, auf booleschen Fehlern basierende SQL-Injection und zeitbasierte SQL-Injection.
 
-Diese Schwachstelle ist vorhanden, wenn Benutzereingaben, die an eine zugrunde liegende SQL-Anweisung übermittelt werden, die Bedeutung der Anweisung ändern können. Zum Beispiel ist der folgende Code dazu gedacht, alle Benutzer mit einem bestimmten Namen (`userName`) aufzulisten, der aus einem HTML-Formular bereitgestellt wurde:
+Diese Schwachstelle liegt vor, wenn Nutzereingaben, die an eine zugrunde liegende SQL-Anweisung übergeben werden, die Bedeutung der Anweisung ändern können. Zum Beispiel ist der folgende Code dazu gedacht, alle Nutzer mit einem bestimmten Namen (`userName`), der aus einem HTML-Formular angegeben wurde, aufzulisten:
 
 ```sql
 statement = "SELECT * FROM users WHERE name = '" + userName + "';"
 ```
 
-Wenn der Benutzer einen echten Namen angibt, funktioniert die Anweisung wie beabsichtigt. Ein böswilliger Benutzer könnte jedoch das Verhalten dieser SQL-Anweisung vollständig ändern, zu der neuen Anweisung im folgenden Beispiel, indem er `a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't` für den `userName` angibt.
+Wenn der Nutzer einen realen Namen angibt, wird die Anweisung wie beabsichtigt funktionieren. Ein bösartiger Nutzer könnte jedoch das Verhalten dieser SQL-Anweisung vollständig in die neue Anweisung im folgenden Beispiel ändern, indem er `a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't` für den `userName` angibt.
 
 ```sql
 SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
 ```
 
-Die modifizierte Anweisung erstellt eine gültige SQL-Anweisung, die die Tabelle `users` löscht und alle Daten aus der Tabelle `userinfo` auswählt (was die Informationen jedes Benutzers preisgibt). Dies funktioniert, weil der erste Teil des injizierten Textes (`a';`) die ursprüngliche Anweisung abschließt.
+Die modifizierte Anweisung erstellt eine gültige SQL-Anweisung, die die `users`-Tabelle löscht und alle Daten aus der `userinfo`-Tabelle auswählt (die die Informationen jedes Nutzers offenlegt). Dies funktioniert, weil der erste Teil des eingeschleusten Textes (`a';`) die ursprüngliche Anweisung vervollständigt.
 
-Um eine solche Art von Angriff zu vermeiden, müssen Sie sicherstellen, dass Benutzerdaten, die an eine SQL-Abfrage übergeben werden, die Natur der Abfrage nicht ändern können. Eine Möglichkeit dies zu tun, besteht darin, alle Zeichen in der Benutzereingabe zu [maskieren](https://en.wikipedia.org/wiki/Escape_character), die eine spezielle Bedeutung in SQL haben.
+Um diese Art von Angriff zu vermeiden, müssen Sie sicherstellen, dass Nutzerdaten, die an eine SQL-Abfrage weitergegeben werden, die Natur der Abfrage nicht ändern können. Eine Möglichkeit ist es, alle Zeichen in den Nutzereingaben zu [escapieren](https://en.wikipedia.org/wiki/Escape_character), die eine besondere Bedeutung in SQL haben.
 
 > [!NOTE]
-> Die SQL-Anweisung behandelt das Zeichen **'** als Anfang und Ende eines Zeichenfolgenliterals. Indem wir diesem Zeichen einen Backslash voranstellen (**\\'**), maskieren wir das Symbol und teilen SQL mit, es als Zeichen zu behandeln (nur als Teil der Zeichenfolge).
+> Die SQL-Anweisung behandelt das **'** Zeichen als Anfang und Ende eines Zeichenfolgen-Literals. Indem man dieses Zeichen mit einem Rückwärtsschrägstrich davor (**\\'**) versieht, escapieren wir das Symbol und teilen SQL mit, es stattdessen als Zeichen (nur als Teil der Zeichenkette) zu behandeln.
 
-In der folgenden Anweisung maskieren wir das Zeichen **'**. Die SQL wird nun den Namen als die gesamte fettgedruckte Zeichenfolge interpretieren (was zwar ein sehr seltsamer Name ist, aber nicht schädlich).
+In der folgenden Anweisung wird das **'** Zeichen escapiert. Das SQL wird nun den Namen als die ganze Zeichenkette in Fettdruck interpretieren (was in der Tat ein sehr eigenartiger Name ist, aber nicht schädlich).
 
 ```sql
 SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';
 ```
 
-Webframeworks übernehmen oft das Maskieren der Zeichen für Sie. Django zum Beispiel stellt sicher, dass alle Benutzerdaten, die an Abfragen (Modelabfragen) übergeben werden, maskiert werden.
+Web-Frameworks übernehmen oft das Escapieren der Zeichen für Sie. Django zum Beispiel stellt sicher, dass alle Nutzerdaten, die an Querysets (Modellanfragen) weitergegeben werden, escapiert werden.
 
 > [!NOTE]
-> Dieser Abschnitt basiert stark auf den Informationen in [Wikipedia hier](https://en.wikipedia.org/wiki/SQL_injection).
+> Dieser Abschnitt stützt sich stark auf die Informationen in [Wikipedia hier](https://en.wikipedia.org/wiki/SQL_injection).
 
 ### Cross-Site Request Forgery (CSRF)
 
-CSRF-Angriffe ermöglichen es einem böswilligen Benutzer, Aktionen mithilfe der Anmeldedaten eines anderen Benutzers auszuführen, ohne dass dieser davon weiß oder zustimmt.
+CSRF-Angriffe ermöglichen es einem bösartigen Nutzer, Aktionen mit den Anmeldedaten eines anderen Nutzers auszuführen, ohne dessen Wissen oder Zustimmung.
 
-Diese Art von Angriff wird am besten durch ein Beispiel erklärt. Josh ist ein böswilliger Benutzer, der weiß, dass eine bestimmte Website angemeldeten Nutzern erlaubt, Geld an ein angegebenes Konto zu senden, indem eine HTTP-`POST`-Anfrage gesendet wird, die den Kontonamen und einen Geldbetrag enthält. Josh erstellt ein Formular, das seine Bankdetails und einen Geldbetrag als versteckte Felder enthält, und sendet es per E-Mail an andere Benutzer der Website (mit einem _Absenden_-Button, der als Link zu einer „schnell reich werden“-Seite getarnt ist).
+Dieser Angriffstyp wird am besten durch ein Beispiel erklärt. Josh ist ein bösartiger Nutzer, der weiß, dass eine bestimmte Website eingeloggt Nutzern erlaubt, Geld per HTTP `POST`-Anfrage an ein bestimmtes Konto zu senden, das den Kontonamen und einen Geldbetrag enthält. Josh erstellt ein Formular, das seine Bankdaten und einen Geldbetrag als versteckte Felder enthält, und sendet es per E-Mail an andere Nutzer der Website (mit dem _Absenden_ Button in Form eines Links zu einer "schnell reich werden"-Website getarnt).
 
-Wenn ein Benutzer auf den Absenden-Button klickt, wird eine HTTP-`POST`-Anfrage an den Server mit den Transaktionsdetails und allen clientseitigen Cookies, die der Browser mit der Website verknüpft, gesendet (die Hinzufügung zugehöriger Site-Cookies zu Anfragen ist normales Browserverhalten). Der Server überprüft die Cookies und verwendet sie, um festzustellen, ob der Benutzer angemeldet ist und die Berechtigung für die Transaktion hat.
+Wenn ein Nutzer den Absenden-Button klickt, wird eine HTTP `POST`-Anfrage an den Server gesendet, die die Transaktionsdetails und alle Client-seitigen Cookies enthält, die der Browser mit der Website assoziiert (das Hinzufügen von zugehörigen Website-Cookies zu Anfragen ist normales Browserverhalten). Der Server überprüft die Cookies und nutzt sie, um festzustellen, ob der Nutzer eingeloggt ist und die Berechtigung hat, die Transaktion durchzuführen.
 
-Das Ergebnis ist, dass jeder Benutzer, der auf den _Absenden_-Button klickt, während er im Handelssystem der Website eingeloggt ist, die Transaktion ausführt. Josh wird reich.
+Das Ergebnis ist, dass jeder Nutzer, der auf den _Absenden_ Button klickt, während er bei der Handelsseite eingeloggt ist, die Transaktion durchführt. Josh wird reich.
 
 > [!NOTE]
-> Der Trick hier ist, dass Josh keinen Zugriff auf die Cookies des Benutzers (oder Zugangsdaten) benötigt. Der Browser des Benutzers speichert diese Informationen und fügt sie automatisch in alle Anfragen an den zugehörigen Server ein.
+> Der Trick besteht hier darin, dass Josh keinen Zugriff auf die Cookies (oder Zugangsdaten) des Nutzers benötigt. Der Browser des Nutzers speichert diese Informationen und fügt sie automatisch in alle Anfragen an den zugehörigen Server ein.
 
-Eine Möglichkeit, diese Art von Angriff zu verhindern, besteht darin, dass der Server verlangt, dass `POST`-Anfragen ein benutzerspezifisches, von der Website generiertes Geheimnis enthalten. Das Geheimnis würde vom Server bereitgestellt, wenn das Webformular zum Übertragen von Geldern gesendet wird. Dieser Ansatz verhindert, dass Josh sein eigenes Formular erstellt, da er das Geheimnis kennen müsste, das der Server dem Benutzer bereitstellt. Selbst wenn er das Geheimnis herausfinden und ein Formular für einen bestimmten Benutzer erstellen würde, könnte er dasselbe Formular nicht länger verwenden, um jeden Benutzer anzugreifen.
+Eine Möglichkeit, diese Art von Angriff zu verhindern, ist, dass der Server verlangt, dass `POST`-Anfragen ein vom Nutzer erzeugtes serverseitiges Geheimnis enthalten. Das Geheimnis würde vom Server bereitgestellt werden, wenn das Webformular zum Übertragen von Geldbeträgen gesendet wird. Dieser Ansatz hindert Josh daran, sein eigenes Formular zu erstellen, da er das Geheimnis kennen müsste, das der Server für den Nutzer bereitstellt. Selbst wenn er das Geheimnis herausfindet und ein Formular für einen bestimmten Nutzer erstellt, wäre er nicht mehr in der Lage, dasselbe Formular zu verwenden, um alle Nutzer anzugreifen.
 
-Web-Frameworks beinhalten oft solche CSRF-Präventionsmechanismen.
+Web-Frameworks enthalten oft solche CSRF-Präventionsmechanismen.
 
-### Andere Bedrohungen
+### Weitere Bedrohungen
 
 Andere häufige Angriffe/Schwachstellen umfassen:
 
-- {{Glossary("Clickjacking", "Clickjacking")}}. Bei diesem Angriff kapert ein bösartiger Benutzer Klicks, die für eine sichtbare Top-Level-Website bestimmt sind, und leitet sie auf eine versteckte Seite darunter um. Diese Technik könnte beispielsweise dazu verwendet werden, um eine legitime Bankwebsite anzuzeigen, aber die Anmeldedaten in ein unsichtbares {{htmlelement("iframe")}} zu kopieren, das vom Angreifer kontrolliert wird. Clickjacking könnte auch verwendet werden, um den Benutzer dazu zu bringen, einen Button auf einer sichtbaren Website zu klicken, was jedoch dazu führt, dass unwissentlich ein völlig anderer Button geklickt wird. Zu verteidigungszwecken kann Ihre Website das Einbetten in ein iframe einer anderen Website verhindern, indem die entsprechenden HTTP-Header gesetzt werden.
-- {{Glossary("Distributed_Denial_of_Service", "Denial of Service")}} (DoS). DoS wird normalerweise erreicht, indem eine Zielwebsite mit gefälschten Anfragen überflutet wird, sodass der Zugang zu einer Website für legitime Benutzer gestört wird. Die Anfragen können zahlreich sein, oder sie verbrauchen einzeln große Mengen an Ressourcen (z.B. langsame Lesevorgänge oder das Hochladen großer Dateien). DoS-Verteidigungen arbeiten normalerweise, indem sie „schlechten“ Verkehr identifizieren und blockieren, während legitime Nachrichten durchgelassen werden. Diese Verteidigungen befinden sich typischerweise vor oder im Webserver (sie sind nicht Teil der Webanwendung selbst).
-- [Directory Traversal](https://en.wikipedia.org/wiki/Directory_traversal_attack) (Datei- und Offenlegung). Bei diesem Angriff versucht ein bösartiger Benutzer, auf Teile des Dateisystems des Webservers zuzugreifen, auf die er keinen Zugriff haben sollte. Diese Schwachstelle tritt auf, wenn der Benutzer Dateinamen übermitteln kann, die Navigationszeichen des Dateisystems enthalten (z.B. `../../`). Die Lösung besteht darin, Eingaben vor der Verwendung zu sanitisieren.
-- [Datei-Einbindung](https://en.wikipedia.org/wiki/File_inclusion_vulnerability). Bei diesem Angriff kann ein Benutzer eine „unbeabsichtigte“ Datei zur Anzeige oder Ausführung in Daten angeben, die an den Server gesendet werden. Wenn die Datei geladen wird, könnte sie auf dem Webserver oder clientseitig ausgeführt werden (was zu einem XSS-Angriff führen kann). Die Lösung besteht darin, Eingaben vor der Verwendung zu sanitisieren.
-- [Befehlsinjektion](https://owasp.org/www-community/attacks/Command_Injection). Befehlsinjektionsangriffe ermöglichen es einem bösartigen Benutzer, beliebige Systembefehle auf dem Host-Betriebssystem auszuführen. Die Lösung besteht darin, Benutzereingaben zu sanitisieren, bevor sie möglicherweise in Systemaufrufen verwendet werden.
+- [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking). Bei diesem Angriff kapert ein bösartiger Nutzer Klicks, die für eine sichtbare oberste Ebene der Website bestimmt sind, und leitet sie auf eine versteckte Seite darunter um. Diese Technik könnte beispielsweise verwendet werden, um eine legitime Bank-Website anzuzeigen, aber die Anmeldedaten in einem unsichtbaren {{htmlelement("iframe")}} zu erfassen, der vom Angreifer kontrolliert wird. Clickjacking könnte auch verwendet werden, um den Nutzer dazu zu bringen, auf einen Button auf einer sichtbaren Website zu klicken, wobei er tatsächlich unwissentlich einen völlig anderen Button klickt. Um sich dagegen zu schützen, kann Ihre Website verhindern, dass sie in einem iframe in einer anderen Website eingebettet wird, indem sie die entsprechenden HTTP-Header setzt.
+- {{Glossary("Distributed_Denial_of_Service", "Denial of Service")}} (DoS). DoS wird in der Regel erreicht, indem eine Zielwebsite mit falschen Anfragen überflutet wird, sodass der Zugriff auf die Website für legitime Nutzer gestört wird. Die Anfragen können zahlreich sein oder einzeln große Ressourcen verbrauchen (z.B. langsame Lesevorgänge oder das Hochladen großer Dateien). DoS-Verteidigungen arbeiten in der Regel, indem sie "schlechten" Datenverkehr identifizieren und blockieren, während legitime Nachrichten durchgelassen werden. Diese Verteidigungen befinden sich typischerweise vor oder im Webserver (sie sind nicht Teil der Webanwendung selbst).
+- [Directory Traversal](https://en.wikipedia.org/wiki/Directory_traversal_attack) (Datei- und Offenlegung). Bei diesem Angriff versuchte ein bösartiger Nutzer auf Teile des Dateisystems des Webservers zuzugreifen, auf die er keinen Zugriff haben sollte. Diese Schwachstelle entsteht, wenn der Nutzer Dateinamen übergeben kann, die Dateisystem-Navigationszeichen enthalten (beispielsweise `../../`). Die Lösung besteht darin, die Eingabe zu bereinigen, bevor sie verwendet wird.
+- [File Inclusion](https://en.wikipedia.org/wiki/File_inclusion_vulnerability). Bei diesem Angriff kann ein Nutzer eine "ungewollte" Datei zur Anzeige oder Ausführung in Daten spezifizieren, die an den Server übergeben werden. Wenn diese Datei geladen wird, könnte sie auf dem Webserver oder clientseitig (was zu einem XSS-Angriff führt) ausgeführt werden. Die Lösung besteht darin, die Eingabe zu bereinigen, bevor sie verwendet wird.
+- [Command Injection](https://owasp.org/www-community/attacks/Command_Injection). Command-Injection-Angriffe ermöglichen es einem bösartigen Nutzer, beliebige Systembefehle auf dem Host-Betriebssystem auszuführen. Die Lösung besteht darin, die Nutzereingaben zu bereinigen, bevor sie in Systemaufrufen verwendet werden können.
 
-Eine umfassende Auflistung von Bedrohungen der Website-Sicherheit finden Sie unter [Kategorie: Web security exploits](https://en.wikipedia.org/wiki/Category:Web_security_exploits) (Wikipedia) und [Kategorie: Attack](https://owasp.org/www-community/attacks/) (Open Web Application Security Project).
+Eine umfassende Liste von Website-Sicherheitsbedrohungen finden Sie unter [Kategorie: Web-Sicherheitsausbeutungen](https://en.wikipedia.org/wiki/Category:Web_security_exploits) (Wikipedia) und [Kategorie: Angriff](https://owasp.org/www-community/attacks/) (Open Web Application Security Project).
 
-## Einige wichtige Nachrichten
+## Einige wichtige Botschaften
 
-Fast alle Sicherheitslücken in den vorhergehenden Abschnitten sind erfolgreich, wenn die Webanwendung den vom Browser kommenden Daten vertraut. Was auch immer Sie tun, um die Sicherheit Ihrer Website zu verbessern, Sie sollten alle benutzerstammenden Daten sanitisieren, bevor sie im Browser angezeigt, in SQL-Abfragen verwendet oder an Betriebssystem- oder Dateisystemaufrufe übergeben werden.
+Fast alle Sicherheitsausbeutungen in den vorherigen Abschnitten sind erfolgreich, wenn die Webanwendung Daten aus dem Browser vertraut. Was auch immer Sie sonst tun, um die Sicherheit Ihrer Website zu verbessern, Sie sollten alle von Nutzern stammenden Daten bereinigen, bevor sie im Browser angezeigt werden, in SQL-Abfragen verwendet oder an einen Betriebssystem- oder Dateisystemaufruf übergeben werden.
 
 > [!WARNING]
-> Die wichtigste Lektion, die Sie über die Sicherheit von Websites lernen können, ist, **niemals Daten aus dem Browser zu vertrauen**. Dies umfasst, aber ist nicht beschränkt auf Daten in URL-Parametern von `GET`-Anfragen, `POST`-Anfragen, HTTP-Headern und -Cookies sowie benutzerhochgeladenen Dateien. Überprüfen und sanitisieren Sie immer alle eingehenden Daten. Gehen Sie immer vom Schlimmsten aus.
+> Die wichtigste Lektion, die Sie über Website-Sicherheit lernen können, ist, **niemals Daten aus dem Browser zu vertrauen**. Dies umfasst, ist aber nicht beschränkt auf Daten in URL-Parametern von `GET`-Anfragen, `POST`-Anfragen, HTTP-Headern und Cookies sowie vom Nutzer hochgeladene Dateien. Überprüfen und bereinigen Sie stets alle eingehenden Daten. Gehen Sie immer vom Schlimmsten aus.
 
 Einige weitere konkrete Schritte, die Sie unternehmen können, sind:
 
-- Verwenden Sie effektivere Passwortverwaltung. Fördern Sie starke Passwörter. Erwägen Sie eine Zwei-Faktor-Authentifizierung für Ihre Website, sodass der Benutzer zusätzlich zu einem Passwort einen weiteren Authentifizierungscode eingeben muss (in der Regel einen, der über ein physisches Hardware-Gerät geliefert wird, das nur der Benutzer hat, z. B. ein Code in einer SMS an sein Telefon).
-- Konfigurieren Sie Ihren Webserver, um {{Glossary("HTTPS", "HTTPS")}} und [HTTP Strict Transport Security](/de/docs/Web/HTTP/Headers/Strict-Transport-Security) (HSTS) zu verwenden. HTTPS verschlüsselt Daten, die zwischen Ihrem Client und dem Server gesendet werden. Dies gewährleistet, dass Anmeldedaten, Cookies, `POST`-Anfragedaten und Header-Informationen für Angreifer nicht leicht zugänglich sind.
-- Behalten Sie die beliebtesten Bedrohungen im Auge (die [aktuelle OWASP-Liste ist hier](https://owasp.org/www-project-top-ten/)) und adressieren Sie die häufigsten Schwachstellen zuerst.
-- Verwenden Sie [Vulnerability Scanning Tools](https://owasp.org/www-community/Vulnerability_Scanning_Tools) für automatisierte Sicherheitstests auf Ihrer Website. Später kann Ihre sehr erfolgreiche Website möglicherweise auch Fehler finden, indem sie ein Bug-Bounty-Programm [wie Mozilla es hier tut](https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/) anbietet.
-- Speichern und zeigen Sie nur die Daten an, die Sie benötigen. Wenn Ihre Benutzer beispielsweise sensible Informationen wie Kreditkartendaten speichern müssen, zeigen Sie nur genügend der Kartennummer an, damit der Benutzer sie identifizieren kann, und nicht genug, damit ein Angreifer sie kopieren und auf einer anderen Seite verwenden kann. Das derzeit häufigste Muster besteht darin, nur die letzten 4 Ziffern einer Kreditkartennummer anzuzeigen.
+- Verwenden Sie effektivere Passwortverwaltungsmaßnahmen. Ermutigen Sie zu starken Passwörtern. Erwägen Sie eine Zwei-Faktor-Authentifizierung für Ihre Website, sodass zusätzlich zu einem Passwort der Nutzer einen weiteren Authentifizierungscode eingeben muss (normalerweise einen, der über irgendeine physische Hardware bereitgestellt wird, die nur der Nutzer hat, z.B. einen Code in einer SMS, die auf sein Telefon gesendet wird).
+- Konfigurieren Sie Ihren Webserver so, dass er {{Glossary("HTTPS", "HTTPS")}} und [HTTP Strict Transport Security](/de/docs/Web/HTTP/Headers/Strict-Transport-Security) (HSTS) verwendet. HTTPS verschlüsselt die zwischen Ihrem Client und Server gesendeten Daten. Dies stellt sicher, dass Anmeldeinformationen, Cookies, `POST`-Anfragen-Daten und Header-Informationen Angreifern nicht leicht zugänglich sind.
+- Verfolgen Sie die beliebtesten Bedrohungen (die [aktuelle OWASP-Liste ist hier](https://owasp.org/www-project-top-ten/)) und beheben Sie die häufigsten Schwachstellen zuerst.
+- Verwenden Sie [Tools zur Verwundbarkeitsscanner](https://owasp.org/www-community/Vulnerability_Scanning_Tools), um automatisierte Sicherheitstests auf Ihrer Website durchzuführen. Später, wenn Ihre sehr erfolgreiche Website, möglicherweise auch Fehler durch die Bereitstellung von Kopfgeldern für Fehler findet [wie Mozilla es hier tut](https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/).
+- Speichern und anzeigen Sie nur die Daten, die Sie benötigen. Wenn Ihre Nutzer beispielsweise sensible Informationen wie Kreditkartendetails speichern müssen, zeigen Sie nur so viel von der Kartennummer an, dass sie vom Nutzer identifiziert werden kann, und nicht genug, dass sie von einem Angreifer kopiert und auf einer anderen Website verwendet werden kann. Das häufigste Muster zu dieser Zeit ist, nur die letzten 4 Ziffern einer Kreditkartennummer anzuzeigen.
 - Halten Sie Software auf dem neuesten Stand.
-  Die meisten Server haben regelmäßige Sicherheitsupdates, die bekannte Schwachstellen beheben oder mildern.
-  Planen Sie, wenn möglich, regelmäßige automatisierte Updates ein und idealerweise Updates während Zeiten, in denen Ihre Website das geringste Verkehrsaufkommen hat.
-  Es ist am besten, Ihre Daten vor dem Update zu sichern und neue Softwareversionen zu testen, um sicherzustellen, dass keine Kompatibilitätsprobleme auf Ihrem Server auftreten.
+  Die meisten Server haben regelmäßige Sicherheitsupdates, die bekannte Schwachstellen beheben oder abschwächen.
+  Wenn möglich, planen Sie regelmäßige automatische Updates ein und idealerweise Updates während Zeiten, in denen Ihre Website den geringsten Verkehr hat.
+  Es ist am besten, Ihre Daten vor dem Aktualisieren zu sichern und neue Softwareversionen zu testen, um sicherzustellen, dass es keine Kompatibilitätsprobleme auf Ihrem Server gibt.
 
-Webframeworks können viele der häufigeren Schwachstellen abmildern.
+Web-Frameworks können helfen, viele der häufigeren Schwachstellen zu mindern.
 
 ## Zusammenfassung
 
-Dieser Artikel hat das Konzept der Websicherheit und einige der häufigeren Bedrohungen erklärt, gegen die Ihre Website zu schützen versuchen sollte. Am wichtigsten ist, dass Sie verstehen sollten, dass eine Webanwendung keine Daten aus dem Webbrowser vertrauen kann. Alle Benutzerdaten sollten saniert werden, bevor sie angezeigt oder in SQL-Abfragen und Dateisystemaufrufen verwendet werden.
+Dieser Artikel hat das Konzept der Websicherheit und einige der häufigeren Bedrohungen erklärt, gegen die Ihre Website schützen sollte. Am wichtigsten ist, dass Sie verstehen sollten, dass eine Webanwendung keinen Browserdaten vertrauen kann. Alle Benutzerdaten sollten bereinigt werden, bevor sie angezeigt oder in SQL-Abfragen und Dateisystemaufrufen verwendet werden.
 
-Mit diesem Artikel sind Sie am Ende [dieses Moduls](/de/docs/Learn/Server-side/First_steps) angelangt, das Ihre ersten Schritte in die serverseitige Webprogrammierung behandelt. Wir hoffen, dass Sie diese grundlegenden Konzepte gerne gelernt haben und nun bereit sind, ein Webframework auszuwählen und mit der Programmierung zu beginnen.
+Mit diesem Artikel sind Sie am Ende [dieses Moduls](/de/docs/Learn/Server-side/First_steps) angelangt, das Ihre ersten Schritte in der serverseitigen Website-Programmierung abdeckt. Wir hoffen, Sie haben es genossen, diese grundlegenden Konzepte zu lernen, und Sie sind jetzt bereit, ein Web-Framework auszuwählen und mit der Programmierung zu beginnen.
 
 {{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}
diff --git a/files/de/web/api/document/requeststorageaccess/index.md b/files/de/web/api/document/requeststorageaccess/index.md
index 3ca71dfac..c7ae53670 100644
--- a/files/de/web/api/document/requeststorageaccess/index.md
+++ b/files/de/web/api/document/requeststorageaccess/index.md
@@ -1,19 +1,19 @@
 ---
-title: "Document: requestStorageAccess()-Methode"
+title: "Dokumentation: Methode requestStorageAccess()"
 short-title: requestStorageAccess()
 slug: Web/API/Document/requestStorageAccess
 l10n:
-  sourceCommit: be8f7f155a48e11b30c240f8731afb1845f85378
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{APIRef("Storage Access API")}}
 
-Die **`requestStorageAccess()`**-Methode des [`Document`](/de/docs/Web/API/Document)-Interfaces ermöglicht es Inhalten, die in einem Drittanbieter-Kontext geladen sind (d. h. eingebettet in einem {{htmlelement("iframe")}}), Zugriff auf [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und [nicht partitionierten Zustand](/de/docs/Web/Privacy/State_Partitioning#state_partitioning) anzufordern. Dies ist relevant für User Agents, die standardmäßig den Zugriff auf Drittanbieter- und [nicht partitionierte](/de/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) Cookies blockieren, um die Privatsphäre zu verbessern (z. B. um Tracking zu verhindern), und ist Teil der [Storage Access API](/de/docs/Web/API/Storage_Access_API).
+Die **`requestStorageAccess()`**-Methode des [`Document`](/de/docs/Web/API/Document)-Interfaces ermöglicht es, in einem Drittanbieter-Kontext geladene Inhalte (d. h. eingebettet in einem {{htmlelement("iframe")}}) den Zugriff auf [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und [unpartitionierten Status](/de/docs/Web/Privacy/State_Partitioning#state_partitioning) anzufordern. Dies ist relevant für Benutzeragenten, die standardmäßig den Zugriff auf Drittanbieter-[unpartitionierte](/de/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) Cookies zur Verbesserung der Privatsphäre blockieren (z. B. um Tracking zu verhindern), und ist Teil der [Storage Access API](/de/docs/Web/API/Storage_Access_API).
 
-Um zu überprüfen, ob die Berechtigung zum Zugriff auf Drittanbieter-Cookies bereits gewährt wurde, können Sie [`Permissions.query()`](/de/docs/Web/API/Permissions/query) aufrufen und den Funktionsnamen `"storage-access"` angeben.
+Um zu prüfen, ob bereits die Berechtigung zum Zugriff auf Drittanbieter-Cookies gewährt wurde, kann [`Permissions.query()`](/de/docs/Web/API/Permissions/query) mit dem Feature-Namen `"storage-access"` aufgerufen werden.
 
 > [!NOTE]
-> Die Nutzung dieser Funktion kann durch eine auf Ihrem Server gesetzte {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Berechtigungsrichtlinie](/de/docs/Web/HTTP/Permissions_Policy) blockiert werden. Darüber hinaus muss das Dokument zusätzliche browserspezifische Überprüfungen bestehen, wie z. B. Positivlisten, Negativlisten, ON-Device-Klassifizierungen, Benutzereinstellungen, Anti-{{Glossary("Clickjacking", "Clickjacking")}}-Heuristiken oder das Anfordern einer expliziten Erlaubnis vom Benutzer.
+> Die Nutzung dieses Features kann durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Berechtigungsrichtlinie](/de/docs/Web/HTTP/Permissions_Policy), die auf Ihrem Server festgelegt ist, blockiert werden. Zusätzlich muss das Dokument weitere, browserspezifische Prüfungen bestehen, wie z.B. Whitelists, Blacklists, Klassifikationen auf dem Gerät, Benutzereinstellungen, Anti-[Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking)-Heuristiken oder die Aufforderung an den Benutzer, eine explizite Berechtigung zu erteilen.
 
 ## Syntax
 
@@ -26,43 +26,43 @@ requestStorageAccess(types)
 
 - `types` {{optional_inline}}
 
-  - : Ein Objekt, das Eigenschaften enthält, die steuern, welcher nicht partitionierte Zustand zugänglich gemacht wird. Wenn nicht angegeben, ist der Standardwert der Eigenschaft `false`. Verfügbare Eigenschaften sind:
+  - : Ein Objekt, das Eigenschaften enthält, die regulieren, welcher unpartitionierte Zustand zugänglich gemacht wird. Wenn nicht angegeben, lautet der Standardwert der Eigenschaft `false`. Die verfügbaren Eigenschaften sind wie folgt:
 
     - `all`
-      - : Ein Boolean, der angibt, dass alle möglichen nicht partitionierten Zustände zugänglich gemacht werden sollten.
+      - : Ein boolean, der angibt, dass alle möglichen unpartitionierten Zustände zugänglich gemacht werden sollen.
     - `cookies`
-      - : Ein Boolean, der angibt, dass Drittanbieter-Cookies zugänglich gemacht werden sollten.
+      - : Ein boolean, der angibt, dass Drittanbieter-Cookies zugänglich gemacht werden sollen.
     - `sessionStorage`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.sessionStorage`](/de/docs/Web/API/StorageAccessHandle/sessionStorage) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.sessionStorage`](/de/docs/Web/API/StorageAccessHandle/sessionStorage) zugänglich gemacht werden soll.
     - `localStorage`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.localStorage`](/de/docs/Web/API/StorageAccessHandle/localStorage) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.localStorage`](/de/docs/Web/API/StorageAccessHandle/localStorage) zugänglich gemacht werden soll.
     - `indexedDB`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.indexedDB`](/de/docs/Web/API/StorageAccessHandle/indexedDB) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.indexedDB`](/de/docs/Web/API/StorageAccessHandle/indexedDB) zugänglich gemacht werden soll.
     - `locks`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.locks`](/de/docs/Web/API/StorageAccessHandle/locks) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.locks`](/de/docs/Web/API/StorageAccessHandle/locks) zugänglich gemacht werden soll.
     - `caches`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.caches`](/de/docs/Web/API/StorageAccessHandle/caches) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.caches`](/de/docs/Web/API/StorageAccessHandle/caches) zugänglich gemacht werden soll.
     - `getDirectory`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.getDirectory()`](/de/docs/Web/API/StorageAccessHandle/getDirectory) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.getDirectory()`](/de/docs/Web/API/StorageAccessHandle/getDirectory) zugänglich gemacht werden soll.
     - `estimate`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.estimate()`](/de/docs/Web/API/StorageAccessHandle/estimate) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.estimate()`](/de/docs/Web/API/StorageAccessHandle/estimate) zugänglich gemacht werden soll.
     - `createObjectURL`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.createObjectURL()`](/de/docs/Web/API/StorageAccessHandle/createObjectURL) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.createObjectURL()`](/de/docs/Web/API/StorageAccessHandle/createObjectURL) zugänglich gemacht werden soll.
     - `revokeObjectURL`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.revokeObjectURL()`](/de/docs/Web/API/StorageAccessHandle/revokeObjectURL) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.revokeObjectURL()`](/de/docs/Web/API/StorageAccessHandle/revokeObjectURL) zugänglich gemacht werden soll.
     - `BroadcastChannel`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.BroadcastChannel()`](/de/docs/Web/API/StorageAccessHandle/BroadcastChannel) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.BroadcastChannel()`](/de/docs/Web/API/StorageAccessHandle/BroadcastChannel) zugänglich gemacht werden soll.
     - `SharedWorker`
-      - : Ein Boolean, der angibt, dass [`StorageAccessHandle.SharedWorker()`](/de/docs/Web/API/StorageAccessHandle/SharedWorker) zugänglich gemacht werden sollte.
+      - : Ein boolean, der angibt, dass [`StorageAccessHandle.SharedWorker()`](/de/docs/Web/API/StorageAccessHandle/SharedWorker) zugänglich gemacht werden soll.
 
 ### Rückgabewert
 
-Ein {{jsxref("Promise")}}, das mit `undefined` erfüllt wird, wenn der Zugriff auf Drittanbieter-Cookies gewährt wurde und kein `types`-Parameter bereitgestellt wurde, oder mit [`StorageAccessHandle`](/de/docs/Web/API/StorageAccessHandle) erfüllt wird, wenn der Zugriff auf nicht partitionierten Zustand, der durch den `types`-Parameter angefordert wurde, gewährt wurde, und das verworfen wird, wenn der Zugriff abgelehnt wurde.
+Ein {{jsxref("Promise")}}, das mit `undefined` erfüllt wird, wenn der Zugriff auf Drittanbieter-Cookies gewährt wurde und kein `types`-Parameter bereitgestellt wurde, erfüllt mit [`StorageAccessHandle`](/de/docs/Web/API/StorageAccessHandle), wenn der Zugriff auf den durch den `types`-Parameter angeforderten unpartitionierten Zustand gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
 
-`requestStorageAccess()`-Anfragen werden automatisch abgelehnt, es sei denn, der eingebettete Inhalt verarbeitet aktuell eine Benutzeraktion wie ein Tippen oder Klicken ({{Glossary("transient_activation", "transiente Aktivierung")}}), oder die Erlaubnis wurde bereits zuvor gewährt. Wenn die Erlaubnis nicht zuvor gewährt wurde, müssen sie innerhalb eines benutzergestengestützten Ereignis-Handlers ausgeführt werden. Das Verhalten der Benutzeraktion hängt vom Status des Promises ab:
+`requestStorageAccess()`-Anfragen werden automatisch abgelehnt, es sei denn, der eingebettete Inhalt verarbeitet derzeit eine Benutzerinteraktion wie einen Tipp oder Klick ({{Glossary("transient_activation", "transiente Aktivierung")}}), oder die Erlaubnis wurde bereits zuvor erteilt. Falls die Erlaubnis zuvor nicht erteilt wurde, müssen sie innerhalb eines benutzergesteuerten Ereignis-Handlers ausgeführt werden. Das Verhalten des Benutzer-Gesten hängt vom Zustand des Promise ab:
 
-- Wenn das Promise aufgelöst wird (d. h. wenn die Erlaubnis erteilt wurde), wird die Benutzeraktion nicht verbraucht, sodass das Skript anschließend APIs aufrufen kann, die eine Benutzeraktion erfordern.
-- Wenn das Promise abgelehnt wird (d. h. die Erlaubnis wurde nicht erteilt), wird die Benutzeraktion verbraucht, sodass das Skript nichts machen kann, was eine Aktion erfordert. Dies ist ein beabsichtigter Schutz gegen Missbrauch – es verhindert, dass Skripte `requestStorageAccess()` in einer Schleife aufrufen, bis der Benutzer die Aufforderung akzeptiert.
+- Wenn das Promise erfüllt wird (d. h. wenn die Berechtigung erteilt wurde), wurde die Benutzer-Geste nicht verbraucht, sodass das Skript anschließend APIs aufrufen kann, die eine Benutzer-Geste erfordern.
+- Wenn das Promise abgelehnt wird (d. h. die Berechtigung wurde nicht erteilt), wurde die Benutzer-Geste verbraucht, sodass das Skript nichts tun kann, das eine Geste erfordert. Dies ist ein absichtlicher Schutz gegen Missbrauch — es verhindert, dass Skripte `requestStorageAccess()` in einer Schleife aufrufen, bis der Benutzer das Prompt akzeptiert.
 
 ### Ausnahmen
 
@@ -75,8 +75,8 @@ Ein {{jsxref("Promise")}}, das mit `undefined` erfüllt wird, wenn der Zugriff a
     - Das Fenster des Dokuments kein [sicherer Kontext](/de/docs/Web/Security/Secure_Contexts) ist.
     - Die Nutzung durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Berechtigungsrichtlinie](/de/docs/Web/HTTP/Permissions_Policy) blockiert wird.
     - Das Dokument oder das oberste Dokument einen `null`-Ursprung hat.
-    - Das einbettende {{htmlelement("iframe")}} im Sandbox-Modus ist und das `allow-storage-access-by-user-activation`-Token nicht gesetzt ist.
-    - Die Nutzung durch die Erlaubnisanforderung des Benutzeragents zur Nutzung der API abgelehnt wird.
+    - Das einbettende {{htmlelement("iframe")}} gesandboxed ist und das `allow-storage-access-by-user-activation`-Token nicht gesetzt ist.
+    - Die Nutzung durch die Erlaubnisanfrage des Benutzeragenten zur Nutzung der API verweigert wird.
 
 ## Beispiele
 
@@ -116,4 +116,4 @@ document.requestStorageAccess({ localStorage: true }).then(
 
 - [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess), [`Document.hasUnpartitionedCookieAccess()`](/de/docs/Web/API/Document/hasUnpartitionedCookieAccess), [`Document.requestStorageAccessFor()`](/de/docs/Web/API/Document/requestStorageAccessFor)
 - [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using)
-- [Einführung in die Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit Blog)
+- [Einführung der Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit Blog)
diff --git a/files/de/web/api/document/requeststorageaccessfor/index.md b/files/de/web/api/document/requeststorageaccessfor/index.md
index d27b9ef99..d8af82e40 100644
--- a/files/de/web/api/document/requeststorageaccessfor/index.md
+++ b/files/de/web/api/document/requeststorageaccessfor/index.md
@@ -1,14 +1,14 @@
 ---
-title: "Document: Methode requestStorageAccessFor()"
+title: "Dokumentation: `requestStorageAccessFor()` Methode"
 short-title: requestStorageAccessFor()
 slug: Web/API/Document/requestStorageAccessFor
 l10n:
-  sourceCommit: be8f7f155a48e11b30c240f8731afb1845f85378
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{APIRef("Storage Access API")}}{{SeeCompatTable}}
 
-Die **`requestStorageAccessFor()`**-Methode des [`Document`](/de/docs/Web/API/Document)-Interfaces ermöglicht es obersten Websites, Drittanbieter-Cookie-Zugriff für eingebettete Inhalte zu beantragen, die von einer anderen Website im selben [verwandten Website-Set](/de/docs/Web/API/Storage_Access_API/Related_website_sets) stammen. Sie gibt ein {{jsxref("Promise")}} zurück, das aufgelöst wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
+Die **`requestStorageAccessFor()`** Methode der [`Document`](/de/docs/Web/API/Document) Schnittstelle erlaubt es Top-Level-Seiten, im Namen von eingebettetem Inhalt, der von einer anderen Seite desselben [related website set](/de/docs/Web/API/Storage_Access_API/Related_website_sets) stammt, Zugriff auf Drittanbieter-Cookies anzufordern. Sie gibt ein {{jsxref("Promise")}} zurück, das gelöst wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
 
 ## Syntax
 
@@ -19,16 +19,16 @@ requestStorageAccessFor(requestedOrigin)
 ### Parameter
 
 - `requestedOrigin`
-  - : Ein String, der die URL des Ursprungs darstellt, für den Sie Drittanbieter-Cookie-Zugriff anfordern.
+  - : Ein String, der die URL des Ursprungs darstellt, für den Sie Zugriff auf Drittanbieter-Cookies anfordern.
 
 ### Rückgabewert
 
 Ein {{jsxref("Promise")}}, das mit `undefined` erfüllt wird, wenn der Zugriff auf Drittanbieter-Cookies gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
 
-`requestStorageAccessFor()`-Anfragen werden automatisch abgelehnt, es sei denn, der oberste Inhalt verarbeitet derzeit eine Benutzeraktion wie einen Tap oder Klick ({{Glossary("transient_activation", "transiente Aktivierung")}}) oder die Erlaubnis wurde bereits zuvor gewährt. Wenn die Erlaubnis nicht zuvor gewährt wurde, müssen sie in einem benutzergestengesteuerten Ereignishandler ausgeführt werden. Das Verhalten der Benutzeraktion hängt vom Stand des Versprechens ab:
+Anforderungen von `requestStorageAccessFor()` werden automatisch abgelehnt, es sei denn, der Top-Level-Inhalt verarbeitet gerade eine Benutzerinteraktion wie beispielsweise ein Tippen oder Klicken ({{Glossary("transient_activation", "transient activation")}}), oder die Berechtigung wurde bereits zuvor erteilt. Wenn die Berechtigung nicht zuvor gewährt wurde, müssen sie innerhalb eines auf Benutzerinteraktionen basierenden Ereignishandlers ablaufen. Das Verhalten der Benutzerinteraktion hängt vom Zustand des Promise ab:
 
-- Wenn das Versprechen aufgelöst wird (d.h. die Erlaubnis wurde erteilt), wurde die Benutzeraktion nicht verbraucht, sodass das Skript anschließend APIs aufrufen kann, die eine Benutzeraktion erfordern.
-- Wenn das Versprechen abgelehnt wird (d.h. die Erlaubnis wurde nicht erteilt), wurde die Benutzeraktion verbraucht, sodass das Skript nichts tun kann, was eine Aktion erfordert. Dies verhindert, dass Skripte `requestStorageAccessFor()` erneut aufrufen, wenn die Erlaubnis verweigert wurde.
+- Wenn das Promise erfüllt wird (d.h. die Berechtigung wurde erteilt), wurde die Benutzerinteraktion nicht verbraucht, sodass das Skript anschließend APIs aufrufen kann, die eine Benutzerinteraktion erfordern.
+- Wenn das Promise abgelehnt wird (d.h. die Berechtigung wurde nicht erteilt), wurde die Benutzerinteraktion verbraucht, sodass das Skript nichts tun kann, was eine Interaktion erfordert. Dies verhindert, dass Skripte `requestStorageAccessFor()` erneut aufrufen, wenn die Berechtigung verweigert wird.
 
 ### Ausnahmen
 
@@ -37,25 +37,25 @@ Ein {{jsxref("Promise")}}, das mit `undefined` erfüllt wird, wenn der Zugriff a
 - `NotAllowedError` [`DOMException`](/de/docs/Web/API/DOMException)
   - : Wird ausgelöst, wenn:
     - Das Fenster des Dokuments kein [sicherer Kontext](/de/docs/Web/Security/Secure_Contexts) ist.
-    - Das Dokument nicht das oberste Dokument ist.
-    - Das Dokument einen `null`-Ursprung hat.
-    - Der angegebene `requestedOrigin` [opake](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque) ist.
-    - Die obersten und eingebetteten Websites nicht im selben [verwandten Website-Set](/de/docs/Web/API/Storage_Access_API/Related_website_sets) sind.
-    - Das einbettende {{htmlelement("iframe")}} sandboxed ist und das `allow-storage-access-by-user-activation`-Token nicht gesetzt ist.
-    - Die Nutzung durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Berechtigungsrichtlinie](/de/docs/Web/HTTP/Permissions_Policy) blockiert wird.
-    - Die Nutzung durch die Berechtigungsanfrage des Benutzeragents zur Nutzung der API verweigert wird.
+    - Das Dokument nicht das Top-Level-Dokument ist.
+    - Das Dokument einen `null` Ursprung hat.
+    - Der angegebene `requestedOrigin` [undurchsichtig](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque) ist.
+    - Die Top-Level und eingebetteten Seiten nicht im selben [related website set](/de/docs/Web/API/Storage_Access_API/Related_website_sets) sind.
+    - Das einbettende {{htmlelement("iframe")}} ist sandboxed, und das `allow-storage-access-by-user-activation` Token ist nicht gesetzt.
+    - Die Nutzung durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/de/docs/Web/HTTP/Permissions_Policy) blockiert wird.
+    - Die Nutzung durch die Berechtigungsanfrage des Benutzeragenten zur Nutzung der API verweigert wird.
 - `TypeError`
   - : Wird ausgelöst, wenn `requestedOrigin` keine gültige URL ist.
 
 ## Beschreibung
 
-Die Methode `requestStorageAccessFor()` adressiert Herausforderungen bei der Einführung der Storage Access API auf obersten Websites, die plattformübergreifende Bilder oder Skripte verwenden, die Cookies benötigen. Sie ist für Benutzeragenten relevant, die standardmäßig den Zugriff auf [Drittanbieter-](/de/docs/Web/Privacy/Third-party_cookies), [unpartitionierte](/de/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) Cookies blockieren, um die Privatsphäre zu verbessern (z.B. um Tracking zu verhindern), und ist eine vorgeschlagene Erweiterung der [Storage Access API](/de/docs/Web/API/Storage_Access_API).
+Die `requestStorageAccessFor()` Methode adressiert Herausforderungen bei der Einführung der Storage Access API auf Top-Level-Seiten, die cross-site Bilder oder Skripte verwenden, die Cookies benötigen. Es ist relevant für Benutzeragenten, die standardmäßig den Zugriff auf [Drittanbieter](/de/docs/Web/Privacy/Third-party_cookies), [unpartitionierte](/de/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) Cookies zur Verbesserung der Privatsphäre blockieren (z.B. um Tracking zu verhindern) und ist eine vorgeschlagene Erweiterung der [Storage Access API](/de/docs/Web/API/Storage_Access_API).
 
-`requestStorageAccessFor()` kann Drittanbieter-Cookie-Zugriff für plattformübergreifende Ressourcen ermöglichen, die direkt in eine oberste Website eingebettet sind und selbst keinen Speicherzugriff anfordern können, zum Beispiel {{htmlelement("img")}}-Elemente. Plattformübergreifende Inhalte, die in `<iframe>`s eingebettet sind, eigene Logik und Ressourcen haben und Drittanbieter-Cookie-Zugriff benötigen, sollten den Speicherzugriff über [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) anfordern.
+`requestStorageAccessFor()` kann den Zugriff auf Drittanbieter-Cookies für cross-site Ressourcen ermöglichen, die direkt in eine Top-Level-Seite eingebettet sind und nicht selbst Speicherzugriff anfordern können, wie zum Beispiel {{htmlelement("img")}} Elemente. Cross-site Inhalt, der in `<iframe>`s eingebettet ist und seine eigene Logik und Ressourcen hat und Zugriff auf Drittanbieter-Cookies benötigt, sollte den Speicherzugriff über [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) anfordern.
 
-Um zu überprüfen, ob die Erlaubnis zum Zugriff auf Drittanbieter-Cookies bereits über `requestStorageAccessFor()` erteilt wurde, können Sie [`Permissions.query()`](/de/docs/Web/API/Permissions/query) aufrufen und den Funktionsnamen `"top-level-storage-access"` angeben. Dies unterscheidet sich vom Funktionsnamen, der für die reguläre [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess)-Methode verwendet wird, der `"storage-access"` lautet.
+Um zu überprüfen, ob die Berechtigung für den Zugriff auf Drittanbieter-Cookies bereits über `requestStorageAccessFor()` gewährt wurde, können Sie [`Permissions.query()`](/de/docs/Web/API/Permissions/query) aufrufen, wobei Sie den Feature-Namen `"top-level-storage-access"` angeben. Dies unterscheidet sich vom Feature-Namen, der für die reguläre [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) Methode verwendet wird, welche `"storage-access"` ist.
 
-Der `Permissions.query()`-Aufruf muss den eingebetteten Ursprung angeben; zum Beispiel:
+Der `Permissions.query()` Aufruf muss den eingebetteten Ursprung angeben; zum Beispiel:
 
 ```js
 navigator.permissions.query({
@@ -65,7 +65,7 @@ navigator.permissions.query({
 ```
 
 > [!NOTE]
-> Die Nutzung dieser Funktion kann durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Berechtigungsrichtlinie](/de/docs/Web/HTTP/Permissions_Policy) blockiert werden, die auf Ihrem Server festgelegt ist (die gleiche, die den Rest der Storage Access API steuert). Außerdem muss das Dokument zusätzliche, browserspezifische Prüfungen bestehen, wie z.B. Zulassungslisten, Sperrlisten, Geräteklassifizierung, Benutzereinstellungen oder Anti-{{Glossary("Clickjacking", "Clickjacking")}}-Heuristiken.
+> Die Verwendung dieser Funktion kann durch eine auf Ihrem Server eingestellte {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/de/docs/Web/HTTP/Permissions_Policy) blockiert werden (dieselbe, die den Rest der Storage Access API kontrolliert). Zusätzlich muss das Dokument zusätzliche browserspezifische Prüfungen bestehen, wie zum Beispiel Zulassungslisten, Sperrlisten, Geräteklassifikation, Benutzereinstellungen oder Anti-[Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) Heuristiken.
 
 ## Beispiele
 
@@ -85,7 +85,7 @@ function rSAFor() {
 }
 ```
 
-Nach einem erfolgreichen `requestStorageAccessFor()`-Aufruf werden plattformübergreifende Anfragen Cookies enthalten, wenn sie [CORS](/de/docs/Web/HTTP/CORS) / [`crossorigin`](/de/docs/Web/HTML/Attributes/crossorigin) beinhalten, sodass Websites möglicherweise warten möchten, bevor sie eine Anfrage auslösen. Solche Anfragen müssen die Option [`credentials: "include"`](/de/docs/Web/API/RequestInit#credentials) verwenden und Ressourcen müssen das Attribut `crossorigin="use-credentials"` beinhalten.
+Nach einem erfolgreichen `requestStorageAccessFor()` Aufruf werden cross-site Anfragen Cookies enthalten, wenn sie [CORS](/de/docs/Web/HTTP/CORS) / [`crossorigin`](/de/docs/Web/HTML/Attributes/crossorigin) einschließen, daher sollten Seiten möglicherweise warten, bevor sie eine Anfrage auslösen. Solche Anfragen müssen die [`credentials: "include"`](/de/docs/Web/API/RequestInit#credentials) Option verwenden und Ressourcen müssen das `crossorigin="use-credentials"` Attribut enthalten.
 
 Zum Beispiel:
 
@@ -103,7 +103,7 @@ function checkCookie() {
 ```
 
 > [!NOTE]
-> Siehe [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using) für ein ausführlicheres Beispiel.
+> Siehe [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using) für ein vollständigeres Beispiel.
 
 ## Spezifikationen
 
@@ -117,4 +117,4 @@ function checkCookie() {
 
 - [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess), [`Document.hasUnpartitionedCookieAccess()`](/de/docs/Web/API/Document/hasUnpartitionedCookieAccess), [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess)
 - [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using)
-- [Einführung der Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit-Blog)
+- [Einführung der Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit Blog)
diff --git a/files/de/web/api/messagechannel/port2/index.md b/files/de/web/api/messagechannel/port2/index.md
index be061efd9..2c2fe1f8f 100644
--- a/files/de/web/api/messagechannel/port2/index.md
+++ b/files/de/web/api/messagechannel/port2/index.md
@@ -3,12 +3,12 @@ title: "MessageChannel: port2-Eigenschaft"
 short-title: port2
 slug: Web/API/MessageChannel/port2
 l10n:
-  sourceCommit: e4c0939929e1b3e1fa3fd3da82b827fca3ed4c79
+  sourceCommit: 5c5b3aba670613917760cf78f639c6156823ff59
 ---
 
 {{APIRef("Channel Messaging API")}} {{AvailableInWorkers}}
 
-Die schreibgeschützte Eigenschaft **`port2`** der [`MessageChannel`](/de/docs/Web/API/MessageChannel)-Schnittstelle gibt den zweiten Port des Nachrichtenkanals zurück — den Port, der mit dem Kontext am anderen Ende des Kanals verbunden ist und an den die Nachricht ursprünglich gesendet wird.
+Die **`port2`**-Eigenschaft des [`MessageChannel`](/de/docs/Web/API/MessageChannel)-Interfaces gibt den zweiten Port des Nachrichtenkanals zurück — den Port, der mit dem Kontext am anderen Ende des Kanals verbunden ist und an den die Nachricht ursprünglich gesendet wird.
 
 ## Wert
 
@@ -16,7 +16,7 @@ Ein [`MessagePort`](/de/docs/Web/API/MessagePort)-Objekt, das den zweiten Port d
 
 ## Beispiele
 
-Im folgenden Codeblock sehen Sie, wie ein neuer Kanal mithilfe des [`MessageChannel()`](/de/docs/Web/API/MessageChannel/MessageChannel)-Konstruktors erstellt wird. Sobald das IFrame geladen ist, übergeben wir `port2` zusammen mit einer Nachricht an das IFrame mithilfe von [`MessagePort.postMessage`](/de/docs/Web/API/MessagePort/postMessage). Der `handleMessage`-Handler reagiert dann auf eine Nachricht, die vom IFrame zurückgesendet wird (mit [`onmessage`](/de/docs/Web/API/MessagePort/message_event)), indem er sie in einen Absatz einfügt. [`port1`](/de/docs/Web/API/MessageChannel/port1) wird überwacht, um zu prüfen, wann die Nachricht eintrifft.
+Im folgenden Codeblock sehen Sie, wie ein neuer Kanal mithilfe des [`MessageChannel()`](/de/docs/Web/API/MessageChannel/MessageChannel)-Konstruktors erstellt wird. Wenn das IFrame geladen ist, übergeben wir `port2` an das IFrame mithilfe von [`Window.postMessage()`](/de/docs/Web/API/Window/postMessage) zusammen mit einer Nachricht. Der `handleMessage`-Handler antwortet dann auf eine Nachricht, die vom IFrame zurückgesendet wird (mittels [`onmessage`](/de/docs/Web/API/MessagePort/message_event)), und fügt sie in einen Absatz ein. [`port1`](/de/docs/Web/API/MessageChannel/port1) wird beobachtet, um zu überprüfen, wann die Nachricht ankommt.
 
 ```js
 const channel = new MessageChannel();
@@ -37,7 +37,7 @@ function handleMessage(e) {
 }
 ```
 
-Für ein vollständiges funktionierendes Beispiel sehen Sie sich unser [Beispiel für grundlegende Kanalnachrichtenübertragung](https://github.com/mdn/dom-examples/tree/main/channel-messaging-basic) auf GitHub an ([führen Sie es auch live aus](https://mdn.github.io/dom-examples/channel-messaging-basic/)).
+Für ein vollständiges funktionierendes Beispiel, siehe unser [channel messaging basic demo](https://github.com/mdn/dom-examples/tree/main/channel-messaging-basic) auf GitHub ([auch live ausführen](https://mdn.github.io/dom-examples/channel-messaging-basic/)).
 
 ## Spezifikationen
 
@@ -49,4 +49,4 @@ Für ein vollständiges funktionierendes Beispiel sehen Sie sich unser [Beispiel
 
 ## Siehe auch
 
-- [Verwendung der Kanalnachrichtenübertragung](/de/docs/Web/API/Channel_Messaging_API/Using_channel_messaging)
+- [Verwendung von Channel Messaging](/de/docs/Web/API/Channel_Messaging_API/Using_channel_messaging)
diff --git a/files/de/web/api/mutationevent/attrchange/index.md b/files/de/web/api/mutationevent/attrchange/index.md
index df7dadcee..eb86b309e 100644
--- a/files/de/web/api/mutationevent/attrchange/index.md
+++ b/files/de/web/api/mutationevent/attrchange/index.md
@@ -3,16 +3,16 @@ title: "MutationEvent: attrChange-Eigenschaft"
 short-title: attrChange
 slug: Web/API/MutationEvent/attrChange
 l10n:
-  sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die **`attrChange`** schreibgeschützte Eigenschaft des [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces gibt eine Zahl zurück, die anzeigt, welche Art von Änderung das `DOMAttrModified`-Ereignis ausgelöst hat. Die drei möglichen Werte sind `MODIFICATION` (`1`), `ADDITION` (`2`) oder `REMOVAL` (`3`). Für andere Ereignisse hat sie keine Bedeutung und wird dann auf `0` gesetzt.
+Die schreibgeschützte **`attrChange`**-Eigenschaft der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle gibt eine Zahl zurück, die angibt, welche Art von Änderung das `DOMAttrModified`-Ereignis ausgelöst hat. Die drei möglichen Werte sind `MODIFICATION` (`1`), `ADDITION` (`2`) oder `REMOVAL` (`3`). Für andere Ereignisse hat sie keine Bedeutung und ist dann auf `0` gesetzt.
 
 ## Wert
 
-Ein Integer: `0`, `1` (`MODIFICATION`), `2` (`ADDITION`) oder `3` (`REMOVAL`).
+Ein Integer: `0`, `1` (`MODIFICATION`), `2` (`ADDITION`), oder `3` (`REMOVAL`).
 
 ## Beispiele
 
diff --git a/files/de/web/api/mutationevent/attrname/index.md b/files/de/web/api/mutationevent/attrname/index.md
index b92ff8b1c..4e6afd3dd 100644
--- a/files/de/web/api/mutationevent/attrname/index.md
+++ b/files/de/web/api/mutationevent/attrname/index.md
@@ -3,12 +3,12 @@ title: "MutationEvent: attrName-Eigenschaft"
 short-title: attrName
 slug: Web/API/MutationEvent/attrName
 l10n:
-  sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die **`attrName`** schreibgeschützte Eigenschaft des [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces gibt einen String mit dem Namen des Knotens zurück, der durch das `DOMAttrModified`-Ereignis betroffen ist. Für andere Ereignisse hat sie keine Bedeutung und wird dann auf den leeren String (`""`) gesetzt.
+Die **`attrName`** schreibgeschützte Eigenschaft des [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces gibt einen String mit dem Namen des Knotens zurück, der von dem `DOMAttrModified`-Ereignis betroffen ist. Für andere Ereignisse hat sie keine Bedeutung und wird dann auf den leeren String (`""`) gesetzt.
 
 ## Wert
 
diff --git a/files/de/web/api/mutationevent/index.md b/files/de/web/api/mutationevent/index.md
index ddc8ecbba..8fab88c58 100644
--- a/files/de/web/api/mutationevent/index.md
+++ b/files/de/web/api/mutationevent/index.md
@@ -2,21 +2,21 @@
 title: MutationEvent
 slug: Web/API/MutationEvent
 l10n:
-  sourceCommit: bb48907e64eb4bf60f17efd7d39b46c771d220a0
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die **`MutationEvent`**-Schnittstelle stellt Ereigniseigenschaften bereit, die spezifisch für Änderungen an der Document Object Model (DOM)-Hierarchie und den Knoten sind.
+Die **`MutationEvent`**-Schnittstelle bietet Ereigniseigenschaften, die speziell für Änderungen an der Document Object Model (DOM)-Hierarchie und -Knoten sind.
 
 > [!NOTE]
 > Die Verwendung von _Mutation Events_ ist problematisch:
 >
 > - Ihr Design ist [fehlerhaft](https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html).
-> - Das Hinzufügen von DOM-Mutations-Listenern zu einem Dokument [verschlechtert die Leistung](https://groups.google.com/g/mozilla.dev.platform/c/L0Lx11u5Bvs?pli=1) weiterer DOM-Änderungen in diesem Dokument erheblich (sie werden 1,5- bis 7-mal langsamer!). Darüber hinaus wird der Schaden durch das Entfernen der Listener nicht rückgängig gemacht.
-> - Sie haben schlechte plattformübergreifende Browser-Kompatibilität: Safari unterstützt `DOMAttrModified` nicht (siehe [WebKit Bug 8191](https://webkit.org/b/8191)) und Firefox unterstützt keine _Mutation Name Events_ (wie `DOMElementNameChanged` und `DOMAttributeNameChanged`).
+> - Das Hinzufügen von DOM-Mutations-Listenern zu einem Dokument [verschlechtert die Leistung erheblich](https://groups.google.com/g/mozilla.dev.platform/c/L0Lx11u5Bvs?pli=1) bei weiteren DOM-Änderungen in diesem Dokument (macht sie 1,5 - 7 Mal langsamer!). Zudem wird der Schaden durch das Entfernen der Listener nicht rückgängig gemacht.
+> - Sie haben eine schlechte Browser-Kompatibilität: Safari unterstützt `DOMAttrModified` nicht (siehe [WebKit-Fehler 8191](https://webkit.org/b/8191)) und Firefox unterstützt keine _Mutation Name Events_ (wie `DOMElementNameChanged` und `DOMAttributeNameChanged`).
 >
-> Sie wurden zugunsten von [Mutation Observers](/de/docs/Web/API/MutationObserver) als veraltet markiert. **Bitte verwenden Sie stattdessen diese.**
+> Sie wurden zugunsten von [MutationObservern](/de/docs/Web/API/MutationObserver) abgelöst. **Erwägen Sie, stattdessen diese zu verwenden.**
 
 {{InheritanceDiagram}}
 
@@ -24,25 +24,25 @@ Die **`MutationEvent`**-Schnittstelle stellt Ereigniseigenschaften bereit, die s
 
 _Diese Schnittstelle erbt auch Eigenschaften von ihrem übergeordneten [`UIEvent`](/de/docs/Web/API/UIEvent) und indirekt von [`Event`](/de/docs/Web/API/Event)._
 
-- [`MutationEvent.attrChange`](/de/docs/Web/API/MutationEvent/attrChange) {{ReadOnlyInline}} {{Deprecated_Inline}}
-  - : Gibt an, welche Art von Änderung das `DOMAttrModified`-Ereignis ausgelöst hat. Es kann `MODIFICATION` (`1`), `ADDITION` (`2`) oder `REMOVAL` (`3`) sein. Es hat für andere Ereignisse keine Bedeutung und wird dann auf `0` gesetzt.
-- [`MutationEvent.attrName`](/de/docs/Web/API/MutationEvent/attrName) {{ReadOnlyInline}} {{Deprecated_Inline}}
-  - : Gibt den Namen des Knotens an, der durch das `DOMAttrModified`-Ereignis betroffen ist. Für andere Ereignisse hat es keine Bedeutung und wird dann auf den leeren String (`""`) gesetzt.
-- [`MutationEvent.newValue`](/de/docs/Web/API/MutationEvent/newValue) {{ReadOnlyInline}} {{Deprecated_Inline}}
-  - : Enthält bei `DOMAttrModified`-Ereignissen den neuen Wert des modifizierten [`Attr`](/de/docs/Web/API/Attr)-Knotens. Bei `DOMCharacterDataModified`-Ereignissen enthält es den neuen Wert des modifizierten [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen wird der leere String (`""`) zurückgegeben.
-- [`MutationEvent.prevValue`](/de/docs/Web/API/MutationEvent/prevValue) {{ReadOnlyInline}} {{Deprecated_Inline}}
-  - : Enthält bei `DOMAttrModified`-Ereignissen den vorherigen Wert des modifizierten [`Attr`](/de/docs/Web/API/Attr)-Knotens. Bei `DOMCharacterDataModified`-Ereignissen enthält es den vorherigen neuen Wert des modifizierten [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen wird der leere String (`""`) zurückgegeben.
-- [`MutationEvent.relatedNode`](/de/docs/Web/API/MutationEvent/relatedNode) {{ReadOnlyInline}} {{Deprecated_Inline}}
-  - : Gibt den mit dem Ereignis verbundenen Knoten an, wie den geänderten Knoten innerhalb der Unterstruktur für `DOMSubtreeModified`.
+- [`MutationEvent.attrChange`](/de/docs/Web/API/MutationEvent/attrChange) {{ReadOnlyInline}} {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Gibt an, welche Art von Änderung das `DOMAttrModified`-Ereignis ausgelöst hat. Es kann `MODIFICATION` (`1`), `ADDITION` (`2`) oder `REMOVAL` (`3`) sein. Für andere Ereignisse hat es keine Bedeutung und ist dann auf `0` gesetzt.
+- [`MutationEvent.attrName`](/de/docs/Web/API/MutationEvent/attrName) {{ReadOnlyInline}} {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Gibt den Namen des Knotens an, der vom `DOMAttrModified`-Ereignis betroffen ist. Für andere Ereignisse hat es keine Bedeutung und ist dann auf den leeren String (`""`) gesetzt.
+- [`MutationEvent.newValue`](/de/docs/Web/API/MutationEvent/newValue) {{ReadOnlyInline}} {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Enthält bei `DOMAttrModified`-Ereignissen den neuen Wert des geänderten [`Attr`](/de/docs/Web/API/Attr)-Knotens. Bei `DOMCharacterDataModified`-Ereignissen enthält es den neuen Wert des geänderten [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen wird der leere String (`""`) zurückgegeben.
+- [`MutationEvent.prevValue`](/de/docs/Web/API/MutationEvent/prevValue) {{ReadOnlyInline}} {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Enthält bei `DOMAttrModified`-Ereignissen den vorherigen Wert des geänderten [`Attr`](/de/docs/Web/API/Attr)-Knotens. Bei `DOMCharacterDataModified`-Ereignissen enthält es den vorherigen neuen Wert des geänderten [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen wird der leere String (`""`) zurückgegeben.
+- [`MutationEvent.relatedNode`](/de/docs/Web/API/MutationEvent/relatedNode) {{ReadOnlyInline}} {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Gibt den mit dem Ereignis verbundenen Knoten an, wie den geänderten Knoten innerhalb des Teilbaums für `DOMSubtreeModified`.
 
 ## Instanz-Methoden
 
-- [`MutationEvent.initMutationEvent()`](/de/docs/Web/API/MutationEvent/initMutationEvent) {{Deprecated_Inline}}
-  - : Konstruktormethode, die ein neues `MutationEvent` mit den gegebenen Parametern konfiguriert zurückgibt.
+- [`MutationEvent.initMutationEvent()`](/de/docs/Web/API/MutationEvent/initMutationEvent) {{Deprecated_Inline}} {{non-standard_inline}}
+  - : Konstruktor-Methode, die ein neues `MutationEvent` mit den angegebenen Parametern konfiguriert zurückgibt.
 
 ## Liste der Mutation Events
 
-Die folgende Liste enthält alle Mutation Events:
+Die folgende Liste zeigt alle Mutation Events:
 
 - `DOMAttrModified` (Nicht unterstützt von Safari)
 - `DOMAttributeNameChanged` (Nicht unterstützt von Firefox)
@@ -56,7 +56,7 @@ Die folgende Liste enthält alle Mutation Events:
 
 ## Beispiele
 
-Sie können einen Listener für Mutation Events registrieren, indem Sie [`EventTarget.addEventListener()`](/de/docs/Web/API/EventTarget/addEventListener) wie folgt verwenden:
+Sie können einen Listener für Mutation Events mit [`EventTarget.addEventListener()`](/de/docs/Web/API/EventTarget/addEventListener) wie folgt registrieren:
 
 ```js
 element.addEventListener(
diff --git a/files/de/web/api/mutationevent/initmutationevent/index.md b/files/de/web/api/mutationevent/initmutationevent/index.md
index 2d73aada0..67938e49d 100644
--- a/files/de/web/api/mutationevent/initmutationevent/index.md
+++ b/files/de/web/api/mutationevent/initmutationevent/index.md
@@ -3,18 +3,17 @@ title: "MutationEvent: initMutationEvent() Methode"
 short-title: initMutationEvent()
 slug: Web/API/MutationEvent/initMutationEvent
 l10n:
-  sourceCommit: bb48907e64eb4bf60f17efd7d39b46c771d220a0
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{deprecated_header}}
+{{APIRef("UI Events")}}{{deprecated_header}}{{non-standard_header}}
 
-Die **`initMutationEvent()`** Methode des [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces initialisiert den
-Wert eines Mutationsevents, nachdem es erstellt wurde (normalerweise mit der [`Document.createEvent()`](/de/docs/Web/API/Document/createEvent)-Methode).
+Die **`initMutationEvent()`**-Methode der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle initialisiert den Wert eines Mutation-Events, nachdem es erstellt wurde (normalerweise mit der [`Document.createEvent()`](/de/docs/Web/API/Document/createEvent)-Methode).
 
-Diese Methode muss aufgerufen werden, um das Event festzulegen, bevor es mit [`EventTarget.dispatchEvent()`](/de/docs/Web/API/EventTarget/dispatchEvent) gesendet wird.
+Diese Methode muss aufgerufen werden, um das Event zu setzen, bevor es mithilfe von [`EventTarget.dispatchEvent()`](/de/docs/Web/API/EventTarget/dispatchEvent) ausgesendet wird.
 
 > [!NOTE]
-> Im Allgemeinen werden Sie diese Events nicht selbst erstellen; sie werden vom Browser erstellt.
+> Im Allgemeinen werden Sie diese Events nicht selbst erstellen; sie werden vom Browser erzeugt.
 
 ## Syntax
 
@@ -26,21 +25,21 @@ initMutationEvent(type, canBubble, cancelable, relatedNode,
 ### Parameter
 
 - `type`
-  - : Ein String, der den [`type`](/de/docs/Web/API/Event/type) des Events festlegt. Browser setzen die folgenden Werte für [`MutationEvent`](/de/docs/Web/API/MutationEvent): `DOMAttrModified`, `DOMAttributeNameChanged`, `DOMCharacterDataModified`, `DOMElementNameChanged`, `DOMNodeInserted`, `DOMNodeInsertedIntoDocument`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMSubtreeModified`.
+  - : Ein String, um den [`type`](/de/docs/Web/API/Event/type) des Events festzulegen. Browser setzen die folgenden Werte für [`MutationEvent`](/de/docs/Web/API/MutationEvent): `DOMAttrModified`, `DOMAttributeNameChanged`, `DOMCharacterDataModified`, `DOMElementNameChanged`, `DOMNodeInserted`, `DOMNodeInsertedIntoDocument`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMSubtreeModified`.
 - `canBubble`
-  - : Ein Boolean, der angibt, ob das Event bubbeln kann oder nicht. Setzt den Wert von [`Event.bubbles`](/de/docs/Web/API/Event/bubbles).
+  - : Ein Boolean-Wert, der angibt, ob das Event "bubblen" kann oder nicht. Setzt den Wert von [`Event.bubbles`](/de/docs/Web/API/Event/bubbles).
 - `cancelable`
-  - : Ein Boolean, der angibt, ob die Standardaktion des Events verhindert werden kann oder nicht. Setzt den Wert von [`Event.cancelable`](/de/docs/Web/API/Event/cancelable).
+  - : Ein Boolean-Wert, der angibt, ob die Standardaktion des Events verhindert werden kann oder nicht. Setzt den Wert von [`Event.cancelable`](/de/docs/Web/API/Event/cancelable).
 - `relatedNode`
-  - : Ein String, der den neuen Wert des geänderten Knotens darstellt, falls vorhanden. Setzt den Wert von [`MutationEvent.relatedNode`](/de/docs/Web/API/MutationEvent/relatedNode).
+  - : Ein String, der den neuen Wert des modifizierten Knotens, falls vorhanden, darstellt. Setzt den Wert von [`MutationEvent.relatedNode`](/de/docs/Web/API/MutationEvent/relatedNode).
 - `prevValue`
-  - : Ein String, der den vorherigen Wert des geänderten Knotens darstellt, falls vorhanden. Setzt den Wert von [`MutationEvent.prevValue`](/de/docs/Web/API/MutationEvent/prevValue).
+  - : Ein String, der den vorherigen Wert des modifizierten Knotens, falls vorhanden, darstellt. Setzt den Wert von [`MutationEvent.prevValue`](/de/docs/Web/API/MutationEvent/prevValue).
 - `newValue`
-  - : Ein String, der den neuen Wert des geänderten Knotens darstellt, falls vorhanden. Setzt den Wert von [`MutationEvent.newValue`](/de/docs/Web/API/MutationEvent/newValue).
+  - : Ein String, der den neuen Wert des modifizierten Knotens, falls vorhanden, darstellt. Setzt den Wert von [`MutationEvent.newValue`](/de/docs/Web/API/MutationEvent/newValue).
 - `attrName`
-  - : Ein String, der den Namen des geänderten [`Attr`](/de/docs/Web/API/Attr)-Knotens darstellt, falls vorhanden. Setzt den Wert von [`MutationEvent.attrName`](/de/docs/Web/API/MutationEvent/attrName).
+  - : Ein String, der den Namen des geänderten [`Attr`](/de/docs/Web/API/Attr)-Knotens, falls vorhanden, darstellt. Setzt den Wert von [`MutationEvent.attrName`](/de/docs/Web/API/MutationEvent/attrName).
 - `attrChange`
-  - : Ein Integer, der den Grund für die Änderung des Attributknotens darstellt. Setzt den Wert von [`MutationEvent.attrChange`](/de/docs/Web/API/MutationEvent/attrChange).
+  - : Ein Integer, der den Grund darstellt, warum der Attributknoten geändert wurde. Setzt den Wert von [`MutationEvent.attrChange`](/de/docs/Web/API/MutationEvent/attrChange).
 
 ### Rückgabewert
 
diff --git a/files/de/web/api/mutationevent/newvalue/index.md b/files/de/web/api/mutationevent/newvalue/index.md
index 2c681192e..442d81c1d 100644
--- a/files/de/web/api/mutationevent/newvalue/index.md
+++ b/files/de/web/api/mutationevent/newvalue/index.md
@@ -1,14 +1,14 @@
 ---
-title: "MutationEvent: Eigenschaft newValue"
+title: "MutationEvent: newValue-Eigenschaft"
 short-title: newValue
 slug: Web/API/MutationEvent/newValue
 l10n:
-  sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die **`newValue`**-Eigenschaft der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle ist eine schreibgeschützte Eigenschaft, die einen String zurückgibt. Bei `DOMAttrModified`-Ereignissen stellt sie den neuen Wert des [`Attr`](/de/docs/Web/API/Attr)-Knotens dar. Bei `DOMCharacterDataModified`-Ereignissen enthält sie den neuen Wert des [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen gibt sie den leeren String (`""`) zurück.
+Die schreibgeschützte **`newValue`**-Eigenschaft des [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces gibt einen String zurück. In `DOMAttrModified`-Ereignissen stellt sie den neuen Wert des [`Attr`](/de/docs/Web/API/Attr)-Knotens dar. In `DOMCharacterDataModified`-Ereignissen enthält sie den neuen Wert des [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen gibt sie den leeren String (`""`) zurück.
 
 ## Wert
 
diff --git a/files/de/web/api/mutationevent/prevvalue/index.md b/files/de/web/api/mutationevent/prevvalue/index.md
index 4b478dd5f..e9957bc51 100644
--- a/files/de/web/api/mutationevent/prevvalue/index.md
+++ b/files/de/web/api/mutationevent/prevvalue/index.md
@@ -3,12 +3,12 @@ title: "MutationEvent: prevValue-Eigenschaft"
 short-title: prevValue
 slug: Web/API/MutationEvent/prevValue
 l10n:
-  sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die schreibgeschützte Eigenschaft **`prevValue`** der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle gibt einen String zurück. Bei `DOMAttrModified`-Ereignissen stellt sie den vorherigen Wert des [`Attr`](/de/docs/Web/API/Attr)-Knotens dar. Bei `DOMCharacterDataModified`-Ereignissen enthält sie den vorherigen Wert des [`CharacterData`](/de/docs/Web/API/CharacterData)-Knotens. In allen anderen Fällen gibt sie den leeren String (`""`) zurück.
+Die schreibgeschützte Eigenschaft **`prevValue`** der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle gibt einen String zurück. Bei `DOMAttrModified`-Ereignissen repräsentiert sie den vorherigen Wert des [`Attr`](/de/docs/Web/API/Attr)-Nodes. Bei `DOMCharacterDataModified`-Ereignissen enthält sie den vorherigen Wert des [`CharacterData`](/de/docs/Web/API/CharacterData)-Nodes. In allen anderen Fällen gibt sie den leeren String (`""`) zurück.
 
 ## Wert
 
diff --git a/files/de/web/api/mutationevent/relatednode/index.md b/files/de/web/api/mutationevent/relatednode/index.md
index 18242b4d1..522a24f98 100644
--- a/files/de/web/api/mutationevent/relatednode/index.md
+++ b/files/de/web/api/mutationevent/relatednode/index.md
@@ -3,12 +3,12 @@ title: "MutationEvent: relatedNode-Eigenschaft"
 short-title: relatedNode
 slug: Web/API/MutationEvent/relatedNode
 l10n:
-  sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{APIRef("UI Events")}}{{Deprecated_Header}}
+{{APIRef("UI Events")}}{{Deprecated_Header}}{{non-standard_header}}
 
-Die **`relatedNode`**-Eigenschaft des schreibgeschützten [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Interfaces gibt einen String zurück, der den Knoten bezeichnet, der mit dem Ereignis in Beziehung steht, wie der geänderte Knoten innerhalb des Unterbaums für `DOMSubtreeModified`.
+Die **`relatedNode`** schreibgeschützte Eigenschaft der [`MutationEvent`](/de/docs/Web/API/MutationEvent)-Schnittstelle gibt einen String zurück, der den mit dem Ereignis verbundenen Knoten angibt, wie zum Beispiel den geänderten Knoten innerhalb des Unterbaums für `DOMSubtreeModified`.
 
 ## Wert
 
diff --git a/files/de/web/api/storage_access_api/index.md b/files/de/web/api/storage_access_api/index.md
index 55ce11c98..bcd2af446 100644
--- a/files/de/web/api/storage_access_api/index.md
+++ b/files/de/web/api/storage_access_api/index.md
@@ -2,72 +2,72 @@
 title: Storage Access API
 slug: Web/API/Storage_Access_API
 l10n:
-  sourceCommit: f2088b8912ef205a737551441d54b73507bd3ac6
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{DefaultAPISidebar("Storage Access API")}}
 
-Die Storage Access API bietet eine Möglichkeit für plattformübergreifende Inhalte, die in einem Drittanbieter-Kontext geladen werden (z.B. eingebettet in einem `<iframe>`), auf [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und [unpartitionierten Zustand](/de/docs/Web/Privacy/State_Partitioning#state_partitioning) zuzugreifen, auf die sie typischerweise nur in einem Erstanbieter-Kontext Zugriff hätten (d.h., wenn sie direkt in einem Browser-Tab geladen werden).
+Die Storage Access API bietet eine Möglichkeit für cross-site-Inhalte, die in einem Drittanbieter-Kontext geladen werden (z. B. eingebettet in ein {{htmlelement("iframe")}}), auf [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und [unpartionierten Zustand](/de/docs/Web/Privacy/State_Partitioning#state_partitioning) zuzugreifen, auf die normalerweise nur in einem Erstanbieter-Kontext zugegriffen werden könnte (d. h. wenn sie direkt in einem Browser-Tab geladen werden).
 
-Die Storage Access API ist für User Agents relevant, die standardmäßig den Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand blockieren, um die Privatsphäre zu verbessern (beispielsweise um Tracking zu verhindern). Es gibt legitime Verwendungen für Drittanbieter-Cookies und unpartitionierten Zustand, die wir auch mit diesen Standardbeschränkungen weiterhin ermöglichen möchten. Beispiele hierfür sind Single Sign-On (SSO) mit föderierten Identitätsanbietern (IdPs) oder das Speichern von Benutzerdetails wie Standortdaten oder Anzeigepräferenzen über verschiedene Websites hinweg.
+Die Storage Access API ist für Benutzeragenten relevant, die standardmäßig den Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand blockieren, um die Privatsphäre zu verbessern (beispielsweise um Tracking zu verhindern). Es gibt jedoch legitime Verwendungen für Drittanbieter-Cookies und unpartitionierten Zustand, die wir auch mit diesen Standardbeschränkungen ermöglichen möchten. Beispiele umfassen Single Sign-On (SSO) mit föderierten Identitätsanbietern (IdPs) oder das Speichern von Benutzerdetails wie Standortdaten oder Anzeigeeinstellungen über verschiedene Seiten hinweg.
 
-Die API bietet Methoden, die eingebetteten Ressourcen ermöglichen zu prüfen, ob sie derzeit Zugriff auf Drittanbieter-Cookies haben und, wenn nicht, Zugriffsanfragen an den User Agent zu stellen.
+Die API bietet Methoden, die es eingebetteten Ressourcen ermöglichen zu überprüfen, ob sie aktuell Zugriff auf Drittanbieter-Cookies haben und, falls nicht, Zugriff beim Benutzeragenten anzufordern.
 
 ## Konzepte und Nutzung
 
-Browser implementieren mehrere Features und Richtlinien für den Speicherzugriff, die den Zugang zu Drittanbieter-Cookies und unpartitioniertem Zustand einschränken. Diese reichen von der Bereitstellung eines einzigartigen Cookie-Speicherraums für eingebettete Ressourcen unter jedem Top-Level-Ursprung ([partitionierte Cookies](#unpartitionierte_versus_partitionierte_cookies)) bis hin zur vollständigen Blockierung des Cookie-Zugriffs, wenn Ressourcen in einem Drittanbieter-Kontext geladen werden.
+Browser implementieren verschiedene Funktionen und Richtlinien für den Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand. Diese reichen von der Bereitstellung eines einzigartigen Cookie-Speicherplatzes für eingebettete Ressourcen unter jedem Top-Level-Ursprung ([partitionierte Cookies](#unpartitionierte_vs._partitionierte_cookies)) bis hin zur kompletten Blockierung des Cookie-Zugriffs, wenn Ressourcen in einem Drittanbieter-Kontext geladen werden.
 
-Die Semantik bezüglich der Blockierung von Drittanbieter-Cookies und unpartitioniertem Zustand unterscheidet sich von Browser zu Browser, aber die Grundfunktionalität ist ähnlich. In einem Drittanbieter-Kontext eingebettete plattformübergreifende Ressourcen haben nicht denselben Zugriff auf den Status, den sie hätten, wenn sie in einem Erstanbieter-Kontext geladen würden. Dies geschieht mit guter Absicht — Browser-Anbieter wollen Schritte unternehmen, um die Privatsphäre und Sicherheit ihrer Nutzer besser zu schützen. Beispiele beinhalten, sie weniger offen für das Tracking ihrer Aktivitäten über verschiedene Websites und weniger anfällig für Exploits wie Cross-Site-Request-Forgery ({{Glossary("CSRF", "CSRF")}}) zu machen.
+Die Semantik bezüglich der Blockierungsfunktionen und Richtlinien für Drittanbieter-Cookies und unpartitionierten Zustand unterscheidet sich von Browser zu Browser, aber die Kernfunktionalität ist ähnlich. Cross-Site-Ressourcen, die in einem Drittanbieter-Kontext eingebettet sind, erhalten nicht denselben Zugriff auf den Zustand, auf den sie in einem Erstanbieter-Kontext zugreifen könnten. Dies geschieht mit guter Absicht – Browseranbieter möchten Maßnahmen ergreifen, um die Privatsphäre und Sicherheit der Benutzer besser zu schützen. Beispiele sind, sie weniger anfällig dafür zu machen, dass ihre Aktivitäten über verschiedene Websites hinweg verfolgt werden, und weniger anfällig für Exploits wie Cross-Site-Request-Forgery ({{Glossary("CSRF", "CSRF")}}) zu sein.
 
-Es gibt jedoch legitime Verwendungen für eingebettete plattformübergreifende Inhalte, die Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand benötigen, die durch die eingangs beschriebenen Funktionen und Richtlinien beeinträchtigt werden. Nehmen wir an, Sie haben eine Serie von verschiedenen Websites, die Zugriff auf unterschiedliche Produkte bieten – `heads-example.com`, `shoulders-example.com`, `knees-example.com` und `toes-example.com`.
+Es gibt jedoch legitime Verwendungen für eingebettete Cross-Site-Inhalte, die auf Drittanbieter-Cookies und unpartitionierten Zustand zugreifen, die durch die oben genannten Funktionen und Richtlinien beeinträchtigt werden. Nehmen wir an, Sie haben eine Reihe unterschiedlicher Websites, die Zugriff auf verschiedene Produkte bieten — `heads-example.com`, `shoulders-example.com`, `knees-example.com` und `toes-example.com`.
 
-Alternativ könnten Sie Ihre Inhalte oder Dienste auf verschiedene Länderdomains zur Lokalisierung aufteilen – `example.com`, `example.ua`, `example.br`, etc. – oder in irgendeiner anderen Weise.
+Alternativ könnten Sie Ihre Inhalte oder Dienste in verschiedene Länderdomains für Lokalisierungszwecke aufteilen — `example.com`, `example.ua`, `example.br` usw. — oder auf eine andere Weise.
 
-Sie könnten begleitende Nutzwebsites mit Komponenten haben, die in allen anderen Seiten eingebettet sind, zum Beispiel um SSO (`sso-example.com`) oder allgemeine Personalisierungsdienste (`services-example.com`) bereitzustellen. Diese Nutzwebsites möchten ihren Status mit den Seiten, in die sie eingebettet sind, über Cookies teilen. Sie können keine Erstanbieter-Cookies teilen, weil sie auf unterschiedlichen Domains liegen, und Drittanbieter-Cookies funktionieren nicht mehr in Browsern, die diese blockieren.
+Sie könnten auch begleitende Dienstleistungsseiten mit Komponenten haben, die in allen anderen Seiten eingebettet sind, um beispielsweise SSO (`sso-example.com`) oder allgemeine Personalisierungsdienste (`services-example.com`) bereitzustellen. Diese Dienstleistungsseiten möchten ihren Zustand mit den Seiten teilen, in die sie eingebettet sind, über Cookies. Sie können keine Erstanbieter-Cookies teilen, weil sie sich auf verschiedenen Domains befinden, und Drittanbieter-Cookies werden in Browsern, die sie blockieren, nicht mehr funktionieren.
 
-In solchen Situationen ermutigen Website-Betreiber oft Nutzer, ihre Website als Ausnahme hinzuzufügen oder die Drittanbieter-Cookie-Blockierungsrichtlinien vollständig zu deaktivieren. Nutzer, die weiterhin mit ihren Inhalten interagieren möchten, müssen ihre Blockierungsrichtlinie für Ressourcen, die von allen eingebetteten Ursprüngen geladen werden, und möglicherweise über alle Websites hinweg erheblich lockern.
+In solchen Situationen ermutigen Website-Eigentümer oft Nutzer, ihre Seite als Ausnahme hinzuzufügen oder die Policies zur Blockierung von Drittanbieter-Cookies vollständig zu deaktivieren. Nutzer, die weiterhin mit ihren Inhalten interagieren möchten, müssen ihre Blockierungsrichtlinie für Ressourcen, die von allen eingebetteten Ursprüngen geladen werden, erheblich lockern und möglicherweise über alle Websites hinweg.
 
-Die Storage Access API soll dieses Problem lösen; eingebettete plattformübergreifende Inhalte können über die Methode [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) auf Basis einzelner Frames uneingeschränkten Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand anfordern. Sie kann auch überprüfen, ob sie bereits Zugriff hat, über die Methode [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess).
+Die Storage Access API soll dieses Problem lösen; eingebettete Cross-Site-Inhalte können auf Basis pro Frame unbegrenzten Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand über die Methode [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) anfordern. Sie kann auch überprüfen, ob bereits Zugriff besteht, über die Methode [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess).
 
-### Unpartitionierte versus partitionierte Cookies
+### Unpartitionierte vs. partitionierte Cookies
 
-Es ist wichtig zu beachten, dass die Storage Access API nur benötigt wird, um Zugriff auf _unpartitionierte_ Drittanbieter-Cookies zu gewähren. Das bedeutet Cookies, die auf die traditionelle Weise seit dem frühen Web gespeichert werden – alle auf derselben Website gesetzten Cookies werden im selben Cookie-Container gespeichert. Dies steht im Gegensatz zu _partitionierten_ Cookies, bei denen eingebetteten Ressourcen unter jeder Top-Level-Site ein einzigartiger Cookiesspeicher zugewiesen wird, wodurch das Verfolgen von Benutzern über diese Cookies über Websites hinweg unmöglich wird.
+Es ist wichtig zu beachten, dass die Storage Access API nur benötigt wird, um Zugriff auf _unpartitionierte_ Drittanbieter-Cookies zu bieten. Dies bedeutet, dass Cookies auf die traditionelle Weise seit den Anfängen des Webs gespeichert werden — alle auf derselben Website gesetzten Cookies werden in demselben Cookie-Glas gespeichert. Dies steht im Gegensatz zu _partitionierten_ Cookies, bei denen eingebettete Ressourcen unter jeder Top-Level-Site einen einzigartigen Cookie-Speicherplatz erhalten und somit das Tracking von Nutzern über diese Cookies unmöglich gemacht wird.
 
-Browser verfügen über verschiedene Mechanismen zur Partitionierung des Drittanbieter-Cookie-Zugriffs, wie zum Beispiel [Firefox Total Cookie Protection](https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/) und [Cookies Having Independent Partitioned State (CHIPS)](/de/docs/Web/Privacy/Privacy_sandbox/Partitioned_cookies).
+Browser verfügen über verschiedene Mechanismen zur Partitonierung des Zugriffs auf Drittanbieter-Cookies, zum Beispiel [Firefox Total Cookie Protection](https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/) und [Cookies Having Independent Partitioned State (CHIPS)](/de/docs/Web/Privacy/Privacy_sandbox/Partitioned_cookies).
 
-Wenn wir im Zusammenhang mit der Storage Access API von Drittanbieter-Cookies sprechen, meinen wir implizit _unpartitionierte_ Drittanbieter-Cookies.
+Wenn wir in Bezug auf die Storage Access API über Drittanbieter-Cookies sprechen, meinen wir implizit _unpartitionierte_ Drittanbieter-Cookies.
 
 ### Funktionsweise
 
-Eingebettete Inhalte, die einen legitimen Bedarf an Zugriff auf Drittanbieter-Cookies oder unpartitionierten Zustand haben, können diesen Zugriff mit der Storage Access API wie folgt anfordern:
-
-1. Sie können die Methode [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess) aufrufen, um zu prüfen, ob sie bereits den benötigten Zugriff haben.
-2. Falls nicht, können sie Zugriff über die Methode [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) anfordern.
-3. Abhängig vom Browser wird der Nutzer auf verschiedene Weisen gefragt, ob der Zugriff dem anfragenden Embed gewährt werden soll.
-   - Safari zeigt Aufforderungen für alle eingebetteten Inhalte, die zuvor keinen Speicherzugriff erhalten haben.
-   - Firefox fordert Nutzer nur auf, nachdem ein Ursprung auf mehr als einer bestimmten Anzahl von Websites Speicherzugriff angefordert hat.
-   - Chrome zeigt Aufforderungen für alle eingebetteten Inhalte, die zuvor keinen Speicherzugriff erhalten haben. Der Zugriff wird jedoch automatisch gewährt und Aufforderungen übersprungen, wenn das eingebettete und das einbettende Website im selben [zusammengehörigen Websiteset](/de/docs/Web/API/Storage_Access_API/Related_website_sets) Teil sind.
-4. Der Zugriff wird gewährt oder abgelehnt basierend darauf, ob der Inhalt alle Sicherheitsanforderungen erfüllt — siehe [Sicherheitsmaßnahmen](#sicherheitsmaßnahmen) für allgemeine Anforderungen und [Browserspezifische Variationen](#browserspezifische_variationen) für einige browserspezifische Sicherheitsanforderungen. Die auf {{jsxref("Promise")}} basierende Natur von `requestStorageAccess()` ermöglicht es Ihnen, Code zum Behandeln von Erfolgs- und Misserfolgsfällen auszuführen.
-   - Modernes Spezifikationsverhalten besagt, dass der Zugriff _pro Frame_ gewährt wird — jedes separate Inhaltsembed hat standardmäßig seinen Drittanbieter-Cookie-Zugriff gesperrt und muss `requestStorageAccess()` aufrufen, um den Zugriff zu aktivieren. Wenn ein Inhaltsembed Zugriff erhalten hat und gleichseitige Embeds dann `requestStorageAccess()` aufrufen, werden ihre Versprechen automatisch erfüllt. Aber sie müssen dennoch aktiviert sein.
-   - Die einzige Ausnahme von dem "standardmäßig blockierten" Verhalten besteht, wenn ein Inhaltsembed erfolgreich `requestStorageAccess()` ausführt, sich dann aber eine gleichursprungsige Navigation durchführt (zum Beispiel durch Neuladen von sich selbst). In solchen Fällen wird der Speicherzugriff von der vorherigen Navigation übernommen.
-   - In älteren Spezifikationsversionen war der Zugriff _pro Seite_ (Safari ist der einzige Browser, der dieses Modell noch verwendet). Wenn ein Embed Drittanbieter-Cookie-Zugriff über `requestStorageAccess()` erhielt, würden alle anderen gleichseitigen Embeds automatisch Zugriff erhalten. Dies war aus Sicherheitsgründen nicht wünschenswert — zum Beispiel, wenn `shop.example.com` `locator.users.com` einbetten würde, um es den Benutzern zu ermöglichen, ihre Standortinformationen beim Einkaufen zu verwenden, und `locator.users.com` `requestStorageAccess()` aufruft, könnten `shop.example.com` und alle anderen darin eingebetteten Sites auf seine Cookies zugreifen, aber auch auf Cookies von `private.users.com`, was nicht zum Einbetten vorgesehen ist. [Lesen Sie mehr über die Beweggründe](https://github.com/privacycg/storage-access/issues/113) hinter dieser Änderung.
-5. Sobald der Zugriff gewährt wird, wird ein Berechtigungsschlüssel im Browser mit der Struktur `<Top-Level-Site, eingebettete Site>` gespeichert. Zum Beispiel, wenn die einbettende Site `embedder.com` ist und das Embed `locator.example.com`, wäre der Schlüssel `<embedder.com, example.com>`. Gleichseitige Embeds (`docs.example.com`, `profile.example.com`, etc.) könnten dann `requestStorageAccess()` aufrufen und das Versprechen würde automatisch erfüllt, wie bereits erwähnt.
-   - Ältere Spezifikationsversionen nutzten die spezifischere Berechtigungsschlüsselstruktur `<Top-Level-Site, eingebetteter Ursprung>`, was bedeutete, dass gleichseitige, aber ursprungsübergreifende Embeds nicht mit dem Berechtigungsschlüssel übereinstimmten und den gesamten Prozess separat durchlaufen mussten.
+Eingebettete Inhalte, die einen legitimen Bedarf an Drittanbieter-Cookies oder unpartitioniertem Zustandszugriff haben, können den Zugriff über die Storage Access API wie folgt anfordern:
+
+1. Sie können die Methode [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess) aufrufen, um zu überprüfen, ob der benötigte Zugriff bereits besteht.
+2. Falls nicht, kann der Zugriff über die Methode [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) angefordert werden.
+3. Abhängig vom Browser wird der Nutzer gefragt, ob dem anfordernden Embed Zugriff gewährt werden soll, wobei dies auf leicht unterschiedliche Weise geschieht.
+   - Safari zeigt Aufforderungen für alle eingebetteten Inhalte, die zuvor noch keinen Speicherzugriff erhalten haben.
+   - Firefox fordert Nutzer erst auf, nachdem ein Ursprung auf mehr als einer festgelegten Anzahl von Websites Speicherzugriff angefordert hat.
+   - Chrome zeigt Aufforderungen für alle eingebetteten Inhalte, die zuvor noch keinen Speicherzugriff erhalten haben. Es wird jedoch automatisch Zugriff gewährt und Aufforderungen übersprungen, wenn der eingebettete Inhalt und die einbettende Seite Teil desselben [verwandten Website-Sets](/de/docs/Web/API/Storage_Access_API/Related_website_sets) sind.
+4. Der Zugriff wird gewährt oder verweigert, basierend darauf, ob der Inhalt alle Sicherheitsanforderungen erfüllt — siehe [Sicherheitsmaßnahmen](#sicherheitsmaßnahmen) für allgemeine Anforderungen und [Browserspezifische Variationen](#browserspezifische_variationen) für einige browserspezifische Sicherheitsanforderungen. Die auf {{jsxref("Promise")}} basierende Natur von `requestStorageAccess()` ermöglicht es Ihnen, Code auszuführen, um Erfolge und Fehlschläge zu behandeln.
+   - Das moderne Spezifikationsverhalten besagt, dass der Zugriff _pro Frame_ gewährt wird — jedes eingebettete Inhaltselement hat standardmäßig seinen Drittanbieter-Cookie-Zugriff blockiert und muss `requestStorageAccess()` aufrufen, um Zugriff zu erhalten. Wenn ein eingebetteter Inhalt Zugriff erhalten hat und gleiche Site-Embeds dann `requestStorageAccess()` aufrufen, wird ihr Promise automatisch erfüllt. Sie müssen sich jedoch weiterhin anmelden.
+   - Die einzige Ausnahme vom "standardmäßig blockiert"-Verhalten ist, wenn ein eingebetteter Inhalt einen erfolgreichen `requestStorageAccess()`-Aufruf macht, sich dann aber einer gleichen Ursprungsnavigation unterzieht (z. B. sich selbst neu lädt). In solchen Fällen wird der Speicherzugriff von der vorherigen Navigation übernommen.
+   - In älteren Spezifikationen war der Zugriff _pro Seite_ (Safari ist der einzige Browser, der dieses Modell noch verwendet). Wenn ein Embed Drittanbieter-Cookie-Zugriff über `requestStorageAccess()` erhielt, würden alle anderen gleichen Site-Embeds automatisch Zugriff erhalten. Dies war aus Sicherheitsgründen nicht wünschenswert — zum Beispiel, wenn `shop.example.com` `locator.users.com` einbettete, um Nutzern zu erlauben, ihre Standortinformationen während des Einkaufs zu verwenden, und `locator.users.com` `requestStorageAccess()` aufrief, würde `shop.example.com` und alle anderen eingebetteten Seiten Zugriff auf seine Cookies erhalten, aber auch auf Cookies von `private.users.com`, die nicht eingebettet werden sollen. [Lesen Sie mehr über die Motivationen](https://github.com/privacycg/storage-access/issues/113) hinter dieser Änderung.
+5. Sobald der Zugriff gewährt wird, wird im Browser ein Berechtigungsschlüssel mit der Struktur `<Top-Level-Site, eingebettete Seite>` gespeichert. Wenn zum Beispiel die einbettende Seite `embedder.com` ist und das Embed `locator.example.com`, wäre der Schlüssel `<embedder.com, example.com>`. Gleichseitige Embeds (`docs.example.com`, `profile.example.com` usw.) könnten dann `requestStorageAccess()` aufrufen und das Promise würde automatisch erfüllt, wie bereits erwähnt.
+   - Ältere Spezifikationsversionen verwendeten die spezifischere Berechtigungsschlüssel-Struktur `<Top-Level-Site, eingebetteter Ursprung>`, was bedeutete, dass gleichseitige, cross-origin Embeds nicht mit dem Berechtigungsschlüssel übereinstimmten und den gesamten Prozess separat durchlaufen mussten.
 
 > [!NOTE]
-> In Fällen, in denen eine Top-Level-Site ihre Cookies [partitioniert](#unpartitionierte_versus_partitionierte_cookies) hat, ist die Storage Access API nicht erforderlich, da das Teilen der Cookies standardmäßig kein Datenschutzrisiko darstellt.
+> In Fällen, in denen eine Top-Level-Site ihre Cookies [partitioniert](#unpartitionierte_vs._partitionierte_cookies) hat, ist die Storage Access API nicht erforderlich, da das Teilen der Cookies standardmäßig kein Datenschutzrisiko darstellt.
 
 ## Sicherheitsmaßnahmen
 
-Es gibt mehrere unterschiedliche Sicherheitsmaßnahmen, die dazu führen können, dass ein Aufruf von [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) fehlschlägt. Überprüfen Sie die folgende Liste, wenn Sie Probleme haben, eine Anforderung zum Laufen zu bringen:
+Verschiedene Sicherheitsmaßnahmen könnten dazu führen, dass ein Aufruf von [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess) fehlschlägt. Prüfen Sie die folgende Liste, wenn Sie Probleme haben, eine Anfrage zum Laufen zu bringen:
 
-1. Der Aufruf muss mit einer Benutzergeste ({{Glossary("transient_activation", "transiente Aktivierung")}}) wie einem Tippen oder Klicken verbunden sein. Dies verhindert, dass eingebettete Inhalte auf der Seite den Browser oder Nutzer mit übermäßigen Zugriffsanforderungen bombardieren. Beachten Sie, dass dies nicht erforderlich ist, wenn:
-   - Die Berechtigung zur Verwendung der API bereits erteilt wurde, z.B. durch eine andere gleichseitige Ressource, die `requestStorageAccess()` aufruft.
-   - Der Aufrufer ein Top-Level-Dokument oder gleichseitig zum Top-Level-Dokument ist. In solchen Fällen muss `requestStorageAccess()` wahrscheinlich überhaupt nicht aufgerufen werden.
+1. Der Aufruf muss mit einem Benutzerbefehl ({{Glossary("transient_activation", "transiente Aktivierung")}}) wie Tippen oder Klicken verbunden sein. Dies verhindert, dass eingebettete Inhalte auf der Seite den Browser oder den Nutzer mit übermäßigen Zugriffsanfragen spammen. Beachten Sie, dass dies nicht erforderlich ist, wenn:
+   - Die Berechtigung zur Nutzung der API bereits gewährt wurde, beispielsweise durch eine andere gleiche Site-Ressource, die `requestStorageAccess()` aufruft.
+   - Der Anrufer ein Top-Level-Dokument oder gleiche Site zum Top-Level-Dokument ist. In solchen Fällen muss `requestStorageAccess()` wahrscheinlich überhaupt nicht aufgerufen werden.
 2. Das Dokument und das Top-Level-Dokument dürfen keinen `null`-Ursprung haben.
-3. Ursprünge, die nie als Erstanbieter interagiert wurden, haben keinen Begriff von Erstanbieterspeicher. Aus der Sicht des Benutzers haben sie nur eine Drittanbieterbeziehung zu diesem Ursprung. Zugriffsanforderungen werden automatisch abgelehnt, wenn der Browser erkennt, dass der Nutzer in einem Erstanbieter-Kontext kürzlich nicht mit dem eingebetteten Inhalt interagiert hat (in Firefox bedeutet "kürzlich" innerhalb von 30 Tagen).
+3. Ursprünge, mit denen nie als Erstnutzer interagiert wurde, haben keinen Begriff von einem Erstnutzer-Speicher. Aus Sicht des Nutzers haben sie nur eine Drittanbieter-Beziehung mit diesem Ursprung. Zugriffsanfragen werden automatisch abgelehnt, wenn der Browser erkennt, dass der Nutzer in letzter Zeit (in Firefox bedeutet "in letzter Zeit" innerhalb von 30 Tagen) nicht in einem Erstnutzer-Kontext mit den eingebetteten Inhalten interagiert hat.
 4. Das Fenster des Dokuments muss ein [sicherer Kontext](/de/docs/Web/Security/Secure_Contexts) sein.
-5. Sandboxed `<iframe>`s können aus Sicherheitsgründen standardmäßig keinen Speicherzugriff gewährt werden. Die API fügt daher auch das `allow-storage-access-by-user-activation` [Sandbox-Token](/de/docs/Web/HTML/Element/iframe#sandbox) hinzu. Die einbettende Website muss dieses hinzufügen, um Speicherzugriffsanfragen erfolgreich zu ermöglichen, zusammen mit `allow-scripts` und `allow-same-origin`, um ein Skript für den API-Aufruf und die Ausführung in einem Ursprung, der Cookies/Zustand haben kann, auszuführen:
+5. Sandboxed {{htmlelement("iframe")}}s können aus Sicherheitsgründen standardmäßig keinen Speicherzugriff gewährt bekommen. Die API fügt daher auch den `allow-storage-access-by-user-activation` [Sandbox-Token](/de/docs/Web/HTML/Element/iframe#sandbox) hinzu. Die einbettende Website muss dies hinzufügen, um erfolgreiche Speicherzugriffsanfragen zu ermöglichen, zusammen mit `allow-scripts` und `allow-same-origin`, um es zu erlauben, ein Skript auszuführen, um die API aufzurufen und sie in einem Ursprung auszuführen, der Cookies/Zustand haben kann:
 
    ```html
    <iframe
@@ -78,57 +78,57 @@ Es gibt mehrere unterschiedliche Sicherheitsmaßnahmen, die dazu führen können
    </iframe>
    ```
 
-6. Die Verwendung dieser Funktion kann durch eine [Berechtigungen-Richtlinie](/de/docs/Web/HTTP/Permissions_Policy) {{httpheader("Permissions-Policy/storage-access", "storage-access")}} blockiert werden, die auf Ihrem Server gesetzt wurde.
+6. Die Nutzung dieses Features kann durch eine {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/de/docs/Web/HTTP/Permissions_Policy), die auf Ihrem Server gesetzt ist, blockiert werden.
 
 > [!NOTE]
-> Das Dokument muss möglicherweise auch zusätzliche browserspezifische Prüfungen bestehen. Beispiele: Whitelists, Blacklists, Klassifizierung auf dem Gerät, Benutzereinstellungen, Anti-{{Glossary("Clickjacking", "Clickjacking")}}-Heuristiken oder das Abfragen des Nutzers um ausdrückliche Berechtigung.
+> Das Dokument kann auch verpflichtet sein, zusätzliche browserspezifische Prüfungen zu bestehen. Beispiele: Allowlisten, Blocklisten, Geräteklassifikation, Benutzereinstellungen, anti-[Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) Heuristiken oder das Anfordern expliziter Benutzergenehmigung.
 
 ## Browserspezifische Variationen
 
-Obwohl die API-Oberfläche dieselbe ist, sollten Websites, die die Storage Access API verwenden, Unterschiede im Umfang und Ausmaß des Drittanbieter-Cookie-Zugriffs erwarten, den sie zwischen verschiedenen Browsern erhalten, aufgrund von unterschiedlichen Speicherzugriffsrichtlinien.
+Obwohl die API-Oberfläche dieselbe ist, sollten Websites, die die Storage Access API nutzen, Unterschiede im Niveau und Umfang des Drittanbieter-Cookie-Zugriffs zwischen verschiedenen Browsern erwarten, aufgrund ihrer unterschiedlichen Richtlinien für den Speicherzugriff.
 
 ### Chrome
 
-- Cookies müssen explizit [`SameSite=None`](/de/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) gesetzt haben, da der Standardwert für Chrome `SameSite=Lax` ist (`SameSite=None` ist der Standard in Firefox und Safari).
-- Cookies müssen das [`Secure`](/de/docs/Web/HTTP/Headers/Set-Cookie#secure)-Attribut gesetzt haben.
-- Die Speicherzugriffsberechtigungen werden nach 30 Tagen Browsernutzung ohne Benutzerinteraktion ausgesetzt. Interaktion mit den eingebetteten Inhalten verlängert diese Grenze um weitere 30 Tage. Dies passiert nicht, wenn [`Document.requestStorageAccessFor()`](/de/docs/Web/API/Document/requestStorageAccessFor) aufgerufen wird, da der Benutzer bereits auf der Seite ist.
+- Cookies müssen das Attribut [`SameSite=None`](/de/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) explizit gesetzt haben, da der Standardwert für Chrome `SameSite=Lax` ist (`SameSite=None` ist der Standard in Firefox und Safari).
+- Cookies müssen das Attribut [`Secure`](/de/docs/Web/HTTP/Headers/Set-Cookie#secure) gesetzt haben.
+- Die Speicherzugriffsgewährungen werden nach 30 Tagen ohne Benutzerinteraktion aus der Browsernutzung aufgehoben. Die Interaktion mit den eingebetteten Inhalten verlängert diese Grenze um weitere 30 Tage. Dies tritt nicht auf, wenn [`Document.requestStorageAccessFor()`](/de/docs/Web/API/Document/requestStorageAccessFor) aufgerufen wird, da der Nutzer bereits auf der Seite ist.
 
 ### Firefox
 
-- Wenn der eingebettete Ursprung `tracker.example` bereits Drittanbieter-Cookie-Zugriff auf den Top-Level-Ursprung `foo.example` erhalten hat, und der Benutzer in weniger als 30 Tagen erneut eine Seite von `foo.example` besucht, die eine Seite von `tracker.example` einbettet, hat der eingebettete Ursprung beim Laden sofortigen Drittanbieter-Cookie-Zugriff.
-- Die Speicherzugriffsberechtigungen werden nach Ablauf von 30 Kalendertagen ausgesetzt.
+- Wenn der eingebettete Ursprung `tracker.example` bereits Drittanbieter-Cookie-Zugriff auf den Top-Level-Ursprung `foo.example` erhalten hat, und der Benutzer besucht in weniger als 30 Tagen erneut eine Seite von `foo.example`, die eine Seite von `tracker.example` einbettet, hat der eingebettete Ursprung sofort bei Laden Drittanbieter-Cookie-Zugriff.
+- Die Speicherzugriffsgewährungen werden nach 30 Kalendertagen aufgehoben.
 
-Die Dokumentation zur neuen Speicherzugriffsrichtlinie von Firefox zum Blockieren von Tracker-Cookies enthält [eine detaillierte Beschreibung](/de/docs/Web/Privacy/Storage_Access_Policy#storage_access_grants) des Umfangs von Speicherzugriffsberechtigungen.
+Die Dokumentation zur neuen Speicherzugangspolitik von Firefox für das Blockieren von Tracking-Cookies enthält [eine detaillierte Beschreibung](/de/docs/Web/Privacy/Storage_Access_Policy#storage_access_grants) des Umfangs der Speicherzugriffsgewährungen.
 
 ### Safari
 
-- Die Speicherzugriffsberechtigungen werden nach 30 Tagen Browsernutzung ohne Benutzerinteraktion aufgehoben. Erfolgreiche Nutzung der Storage Access API setzt diesen Zähler zurück.
+- Die Speicherzugriffsgewährungen werden nach 30 Tagen ohne Benutzerinteraktion aus der Browsernutzung aufgehoben. Der erfolgreiche Einsatz der Storage Access API setzt diesen Zähler zurück.
 
 ## Beispiele
 
-- Siehe [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using) für einen Implementierungsleitfaden mit Codebeispielen.
-- Siehe [Storage Access API Demo](https://storage-access-api-demo.glitch.me/) für eine Live-Demo.
+- Sehen Sie sich [Using the Storage Access API](/de/docs/Web/API/Storage_Access_API/Using) für einen Implementierungsleitfaden mit Codebeispielen an.
+- Sehen Sie sich [Storage Access API Demo](https://storage-access-api-demo.glitch.me/) für eine Live-Demo an.
 
 ## API-Methoden
 
 - [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess)
-  - : Gibt ein {{jsxref("Promise")}} zurück, das mit einem booleschen Wert angegeben wird, ob das Dokument Zugriff auf Drittanbieter-Cookies hat.
+  - : Gibt ein {{jsxref("Promise")}} zurück, das mit einem booleschen Wert aufgelöst wird, der angibt, ob das Dokument Zugriff auf Drittanbieter-Cookies hat.
 - [`Document.hasUnpartitionedCookieAccess()`](/de/docs/Web/API/Document/hasUnpartitionedCookieAccess)
   - : Neuer Name für [`Document.hasStorageAccess()`](/de/docs/Web/API/Document/hasStorageAccess).
 - [`Document.requestStorageAccess()`](/de/docs/Web/API/Document/requestStorageAccess)
-  - : Ermöglicht es, in einem Drittanbieter-Kontext geladene Inhalte (d.h. eingebettet in einem `<iframe>`) den Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand anzufordern; gibt ein {{jsxref("Promise")}} zurück, das erfüllt wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
+  - : Ermöglicht es, in einem Drittanbieter-Kontext geladene Inhalte (d. h. eingebettet in ein {{htmlelement("iframe")}}) Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand anzufordern; gibt ein {{jsxref("Promise")}} zurück, das erfüllt wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
 - [`Document.requestStorageAccessFor()`](/de/docs/Web/API/Document/requestStorageAccessFor) {{experimental_inline}}
-  - : Ein geplanter Erweiterungsvorschlag der Storage Access API, der es Top-Level-Sites ermöglicht, Drittanbieter-Cookie-Zugriff im Namen von eingebetteten Inhalten von einer anderen Site im selben [zusammengehörigen Websiteset](/de/docs/Web/API/Storage_Access_API/Related_website_sets) anzufordern. Gibt ein {{jsxref("Promise")}} zurück, das erfüllt wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.
+  - : Ein vorgeschlagener Ausbau der Storage Access API, der es Top-Level-Sites ermöglicht, im Namen von eingebetteten Inhalten, die von einer anderen Seite im selben [verwandten Website-Set](/de/docs/Web/API/Storage_Access_API/Related_website_sets) stammen, Zugriff auf Drittanbieter-Cookies anzufordern. Gibt ein {{jsxref("Promise")}} zurück, das erfüllt wird, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn er verweigert wurde.
 
 > [!NOTE]
-> Benutzerinteraktion überträgt sich auf das von diesen Methoden zurückgegebene Versprechen, was es den Aufrufern ermöglicht, Aktionen auszuführen, die Benutzerinteraktion erfordern, ohne einen zweiten Klick erforderlich zu machen. Beispielsweise könnte ein Aufrufer ein Pop-up-Fenster aus dem aufgelösten Versprechen öffnen, ohne den Pop-up-Blocker von Firefox auszulösen.
+> Die Benutzerinteraktion wird an das Promise weitergegeben, das von diesen Methoden zurückgegeben wird, was es den Anrufern erlaubt, Maßnahmen zu ergreifen, die eine Benutzerinteraktion erfordern, ohne einen zweiten Klick zu benötigen. Beispielsweise könnte ein Anrufer ein Pop-up-Fenster aus dem aufgelösten Promise öffnen, ohne den Pop-up-Blocker von Firefox auszulösen.
 
 ### Ergänzungen zu anderen APIs
 
-- [`Permissions.query()`](/de/docs/Web/API/Permissions/query), der `"storage-access"` Feature-Name
-  - : In unterstützenden Browsern kann dies abfragen, ob Drittanbieter-Cookie-Zugriff im Allgemeinen gewährt wurde, d.h., für einen anderen gleichseitigen Embed. Wenn ja, können Sie `requestStorageAccess()` ohne Benutzerinteraktion aufrufen, und das Versprechen erfüllt sich automatisch.
-- `Permissions.query()`, der `"top-level-storage-access"` Feature-Name {{experimental_inline}}
-  - : Ein separater Feature-Name, der abfragt, ob die Berechtigung zum Zugriff auf Drittanbieter-Cookies bereits über `requestStorageAccessFor()` gewährt wurde. Wenn ja, müssen Sie `requestStorageAccessFor()` nicht erneut aufrufen.
+- [`Permissions.query()`](/de/docs/Web/API/Permissions/query), der `"storage-access"`-Feature-Name
+  - : In unterstützenden Browsern kann abgefragt werden, ob im Allgemeinen Zugriff auf Drittanbieter-Cookies gewährt wurde, das heißt, einem anderen gleichen Site-Embed. Wenn ja, können Sie `requestStorageAccess()` ohne Benutzerinteraktion aufrufen und das Promise wird automatisch erfüllt.
+- `Permissions.query()`, der `"top-level-storage-access"`-Feature-Name {{experimental_inline}}
+  - : Ein separater Feature-Name, der verwendet wird, um abzufragen, ob die Berechtigung zum Zugriff auf Drittanbieter-Cookies bereits über `requestStorageAccessFor()` gewährt wurde. Wenn ja, müssen Sie `requestStorageAccessFor()` nicht erneut aufrufen.
 
 ## Spezifikationen
 
@@ -140,5 +140,5 @@ Die Dokumentation zur neuen Speicherzugriffsrichtlinie von Firefox zum Blockiere
 
 ## Siehe auch
 
-- [Verwendung der Storage Access API](/de/docs/Web/API/Storage_Access_API/Using)
-- [Introducing Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit blog)
+- [Using the Storage Access API](/de/docs/Web/API/Storage_Access_API/Using)
+- [Introducing Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit Blog)
diff --git a/files/de/web/css/@view-transition/index.md b/files/de/web/css/@view-transition/index.md
index 6b1fb7a14..257f51f90 100644
--- a/files/de/web/css/@view-transition/index.md
+++ b/files/de/web/css/@view-transition/index.md
@@ -2,14 +2,14 @@
 title: "@view-transition"
 slug: Web/CSS/@view-transition
 l10n:
-  sourceCommit: 6d311a5f07c97dbcd7bb9a6d49c2fe820a228659
+  sourceCommit: 8583c1238d297609d6db0623aba9070d5c57f330
 ---
 
-{{CSSRef}}{{SeeCompatTable}}
+{{CSSRef}}
 
-Die **`@view-transition`** [CSS](/de/docs/Web/CSS) [At-Regel](/de/docs/Web/CSS/At-rule) wird verwendet, um das aktuelle und das Ziel-Dokument für einen [Ansichtsübergang](/de/docs/Web/API/View_Transitions_API) im Falle einer Navigation über Dokumentengrenzen hinweg anzumelden.
+Die **`@view-transition`** [CSS](/de/docs/Web/CSS) [At-Regel](/de/docs/Web/CSS/At-rule) wird verwendet, um das aktuelle und das Ziel-Dokument für einen [View-Übergang](/de/docs/Web/API/View_Transitions_API) bei einer Dokument-übergreifenden Navigation anzumelden.
 
-Damit ein Ansichtsübergang zwischen Dokumenten funktioniert, müssen das aktuelle und das Zieldokument der Navigation ebenfalls aus demselben Ursprung stammen.
+Damit ein Dokument-übergreifender View-Übergang funktioniert, müssen das aktuelle und das Ziel-Dokument der Navigation auch auf demselben Ursprung sein.
 
 ## Syntax
 
@@ -23,11 +23,11 @@ Damit ein Ansichtsübergang zwischen Dokumenten funktioniert, müssen das aktuel
 
 - `navigation`
 
-  - : Gibt an, welche Wirkung diese At-Regel auf das Verhalten des Ansichtsübergangs des Dokuments hat. Mögliche Werte sind:
+  - : Gibt den Effekt an, den diese At-Regel auf das View-Übergangsverhalten des Dokuments haben wird. Mögliche Werte sind:
 
-    - `auto`: Das Dokument wird einen Ansichtsübergang durchlaufen, wenn es an einer Navigation beteiligt ist, vorausgesetzt, die Navigation ist gleich-origin, ohne ursprungsübergreifende Weiterleitungen, und ihr [`navigationType`](/de/docs/Web/API/NavigateEvent/navigationType) ist `traverse`, `push` oder `replace`. Im Falle von `push` oder `replace` muss die Navigation durch eine Benutzerinteraktion mit dem Seiteninhalt initiiert werden, nicht durch eine Browser-Oberflächenfunktion.
+    - `auto`: Das Dokument wird einen View-Übergang durchlaufen, wenn es an einer Navigation beteiligt ist, vorausgesetzt, die Navigation ist gleich-originig, ohne cross-origin Umleitungen, und ihr [`navigationType`](/de/docs/Web/API/NavigateEvent/navigationType) ist `traverse`, `push` oder `replace`. Im Falle von `push` oder `replace` muss die Navigation von einem Benutzerinteraktion mit dem Seiteninhalt initiiert werden, nicht durch eine Browser-UI-Funktion.
 
-    - `none`: Das Dokument wird keinen Ansichtsübergang durchlaufen.
+    - `none`: Das Dokument wird keinen View-Übergang durchlaufen.
 
 ## Formale Syntax
 
@@ -35,13 +35,11 @@ Damit ein Ansichtsübergang zwischen Dokumenten funktioniert, müssen das aktuel
 
 ## Beispiele
 
-### Übergang der Seitenansicht
+### Seitenansicht übergehen
 
-Die folgenden Codebeispiele zeigen die wichtigsten Konzepte, die in einer Seitenübergangs-Demo verwendet werden.
-Die Demo verwendet Dokumenten-übergreifende Ansichtsübergänge; einen halben Sekundenübergang, der auftritt, wenn zwischen zwei Seiten einer Website navigiert wird.
-Für die vollständige Demo siehe das [View Transitions Multi-Page App Demo](https://mdn.github.io/dom-examples/view-transitions/mpa/).
+Die folgenden Code-Snippets zeigen Schlüsselkonzepte, die in einer Seitenübergangs-Demo verwendet werden. Die Demo verwendet Dokument-übergreifende View-Übergänge; ein halbe Sekunde dauernder Übergang, der beim Navigieren zwischen zwei Seiten einer Website auftritt. Für die vollständige Demo siehe das [View transitions multi-page app demo](https://mdn.github.io/dom-examples/view-transitions/mpa/).
 
-Die `@view-transition` At-Regel wird im CSS sowohl für Ihre aktuellen als auch Ziel-Dokumente einer Navigation angegeben, um beide in den Ansichtsübergang einzubinden:
+Die `@view-transition` At-Regel wird im CSS sowohl für Ihr aktuelles als auch für das Ziel-Dokument einer Navigation angegeben, um beide für den View-Übergang anzumelden:
 
 ```css
 @view-transition {
@@ -49,7 +47,7 @@ Die `@view-transition` At-Regel wird im CSS sowohl für Ihre aktuellen als auch
 }
 ```
 
-Zusätzlich zur `@view-transition` At-Regel definieren wir zwei {{cssxref("@keyframe")}}-Animationen und verwenden die {{cssxref("animation")}}-Kurzschreibweise, um diese Keyframe-Animationen auf die Elemente in den ausgehenden ({{cssxref("::view-transition-old()")}}) und eingehenden ({{cssxref("::view-transition-new()")}}) Seiten anzuwenden, die wir animieren möchten.
+Zusätzlich zur `@view-transition` At-Regel definieren wir zwei {{cssxref("@keyframe")}} Animationen und verwenden die {{cssxref("animation")}} Kurzschreibweise, um diese Keyframe-Animationen auf die Elemente der ausgehenden ({{cssxref("::view-transition-old()")}}) und eingehenden ({{cssxref("::view-transition-new()")}}) Seiten anzuwenden, die wir animieren möchten.
 
 ```css
 /* Create a custom animation */
@@ -83,7 +81,7 @@ Zusätzlich zur `@view-transition` At-Regel definieren wir zwei {{cssxref("@keyf
 }
 ```
 
-Sehen Sie sich diese [Transitions Multi-Page App](https://mdn.github.io/dom-examples/view-transitions/mpa/) Demo live an.
+Sehen Sie sich dieses [transitions multi-page app](https://mdn.github.io/dom-examples/view-transitions/mpa/) Demo live an.
 
 ## Spezifikationen
 
diff --git a/files/de/web/html/element/summary/index.md b/files/de/web/html/element/summary/index.md
index b7250720e..0dab66a2b 100644
--- a/files/de/web/html/element/summary/index.md
+++ b/files/de/web/html/element/summary/index.md
@@ -2,12 +2,12 @@
 title: "<summary>: Das Disclosure Summary Element"
 slug: Web/HTML/Element/summary
 l10n:
-  sourceCommit: 9d1a95873d139d5e278b568e4d88361bf86e4123
+  sourceCommit: 0d945ca6e3ac02395dac9f1638ce6e488ada79f2
 ---
 
 {{HTMLSidebar}}
 
-Das **`<summary>`** [HTML](/de/docs/Web/HTML)-Element spezifiziert eine Zusammenfassung, eine Bildunterschrift oder eine Legende für das Disclosure Box des {{HTMLElement("details")}}-Elements. Ein Klick auf das `<summary>`-Element schaltet den Zustand des übergeordneten `<details>`-Elements zwischen offen und geschlossen.
+Das **`<summary>`** [HTML](/de/docs/Web/HTML)-Element gibt eine Zusammenfassung, Beschriftung oder Legende für ein {{HTMLElement("details")}}-Element an. Das Klicken auf das `<summary>`-Element schaltet den Zustand des übergeordneten `<details>`-Elements zwischen offen und geschlossen um.
 
 {{EmbedInteractiveExample("pages/tabbed/summary.html","tabbed-shorter")}}
 
@@ -15,35 +15,35 @@ Das **`<summary>`** [HTML](/de/docs/Web/HTML)-Element spezifiziert eine Zusammen
 
 Dieses Element umfasst nur die [globalen Attribute](/de/docs/Web/HTML/Global_attributes).
 
-## Nutzungshinweise
+## Verwendungshinweise
 
-Der Inhalt des `<summary>`-Elements kann jeglichen Überschriften-Inhalt, einfachen Text oder HTML sein, der innerhalb eines Absatzes verwendet werden kann.
+Der Inhalt des `<summary>`-Elements kann jeglichen Überschrift-Inhalt, einfachen Text oder HTML enthalten, das innerhalb eines Absatzes verwendet werden kann.
 
-Ein `<summary>`-Element darf _nur_ als erstes Kind eines `<details>`-Elements verwendet werden. Wenn der Benutzer auf die Zusammenfassung klickt, wird das übergeordnete `<details>`-Element geöffnet oder geschlossen, und dann wird ein [`toggle`](/de/docs/Web/API/HTMLElement/toggle_event)-Ereignis an das `<details>`-Element gesendet, das verwendet werden kann, um Sie über diesen Zustandswechsel zu informieren.
+Ein `<summary>`-Element darf _nur_ als das erste Kind eines `<details>`-Elements verwendet werden. Wenn der Benutzer auf die Zusammenfassung klickt, wird das übergeordnete `<details>`-Element geöffnet oder geschlossen, und es wird ein [`toggle`](/de/docs/Web/API/HTMLElement/toggle_event)-Ereignis an das `<details>`-Element gesendet, das verwendet werden kann, um Sie darüber zu informieren, wann diese Zustandsänderung eintritt.
 
 Der Inhalt des `<details>` bietet die {{Glossary("accessible_description", "zugängliche Beschreibung")}} für das `<summary>`.
 
-### Standardbeschriftungstext
+### Standard-Beschriftungstext
 
-Wenn das erste Kind eines `<details>`-Elements kein `<summary>`-Element ist, wird der {{Glossary("user_agent", "User-Agent")}} eine Standardzeichenfolge (typischerweise "Details") als Beschriftung für das Disclosure Box verwenden.
+Wenn das erste Kind eines `<details>`-Elements kein `<summary>`-Element ist, wird der {{Glossary("user_agent", "User Agent")}} eine Standardzeichenkette (typischerweise "Details") als Beschriftung für das Disclosure-Box verwenden.
 
 ### Standardstil
 
-Laut der HTML-Spezifikation umfasst der Standardstil für `<summary>`-Elemente `display: list-item`. Dies erlaubt es, das angezeigte Symbol als Disclosure-Widget neben der Beschriftung vom Standard, der typischerweise ein Dreieck ist, zu ändern oder zu entfernen.
+Nach der HTML-Spezifikation umfasst der Standardstil für `<summary>`-Elemente `display: list-item`. Dies ermöglicht es, das Symbol, das als Disclosure-Widget neben der Beschriftung angezeigt wird, vom Standard (typischerweise ein Dreieck) zu ändern oder zu entfernen.
 
-Sie können den Stil auch auf `display: block` ändern, um das Offenlegungssymbol-Dreieck zu entfernen.
+Sie können den Stil auch ändern zu `display: block`, um das Dreieck zu entfernen.
 
-Siehe den Abschnitt [Browser-Kompatibilität](#browser-kompatibilität) für Details, da nicht alle Browser die volle Funktionalität dieses Elements bereits unterstützen.
+Siehe den Abschnitt [Browser-Kompatibilität](#browser-kompatibilität) für Details, da nicht alle Browser die volle Funktionalität dieses Elements unterstützen.
 
-Für WebKit-basierte Browser wie Safari ist es möglich, die Symbolanzeige durch das nicht standardmäßige CSS-Pseudo-Element `::-webkit-details-marker` zu steuern. Um das Offenlegungsdreieck zu entfernen, verwenden Sie `summary::-webkit-details-marker { display: none }`.
+Für auf WebKit-basierende Browser wie Safari ist es möglich, die Anzeige des Symbols über das nicht standardmäßige CSS-Pseudoelement `::-webkit-details-marker` zu steuern. Um das Dreieck zu entfernen, verwenden Sie `summary::-webkit-details-marker { display: none }`.
 
 ## Beispiele
 
-Nachfolgend einige Beispiele, die `<summary>` in Verwendung zeigen. Weitere Beispiele finden Sie in der Dokumentation des {{HTMLElement("details")}}-Elements.
+Unten finden Sie einige Beispiele, die die Verwendung von `<summary>` zeigen. Weitere Beispiele finden Sie in der Dokumentation zum {{HTMLElement("details")}}-Element.
 
-### Einfaches Beispiel
+### Grundlegendes Beispiel
 
-Ein einfaches Beispiel, das die Verwendung von `<summary>` in einem {{HTMLElement("details")}}-Element zeigt:
+Ein grundlegendes Beispiel, das die Verwendung von `<summary>` in einem {{HTMLElement("details")}}-Element zeigt:
 
 ```html
 <details open>
@@ -62,7 +62,7 @@ Ein einfaches Beispiel, das die Verwendung von `<summary>` in einem {{HTMLElemen
 
 ### Zusammenfassungen als Überschriften
 
-Sie können Überschriftselemente in `<summary>` verwenden, wie folgt:
+Sie können Überschriftselemente in `<summary>` verwenden, wie zum Beispiel:
 
 ```html
 <details open>
@@ -77,12 +77,12 @@ Sie können Überschriftselemente in `<summary>` verwenden, wie folgt:
 
 #### Ergebnis
 
-{{EmbedLiveSample("Summaries_as_headings", 650, 120)}}
+{{EmbedLiveSample("Summaries_as_headings", 650, 200)}}
 
 Dies hat derzeit einige Abstandsprobleme, die mit CSS behoben werden könnten.
 
 > [!WARNING]
-> Da das `<summary>`-Element standardmäßig die Rolle [button](/de/docs/Web/Accessibility/ARIA/Roles/button_role) hat (die alle Rollen von den Kindelementen entfernt), wird dieses Beispiel für Benutzer von assistiven Technologien wie Bildschirmlesegeräten nicht funktionieren. Das `<h4>` wird seine Rolle verlieren und daher für diese Benutzer nicht als Überschrift behandelt werden.
+> Da das `<summary>`-Element standardmäßig die Rolle [button](/de/docs/Web/Accessibility/ARIA/Roles/button_role) hat (was alle Rollen von Kinderelementen entfernt), wird dieses Beispiel für Benutzer von unterstützenden Technologien wie Bildschirmlesegeräten nicht funktionieren. Das `<h4>` wird seine Rolle verlieren und somit nicht als Überschrift für diese Benutzer behandelt.
 
 ### HTML in Zusammenfassungen
 
@@ -101,15 +101,15 @@ Dieses Beispiel fügt dem `<summary>`-Element einige Semantiken hinzu, um die Be
 
 #### Ergebnis
 
-{{EmbedLiveSample("HTML_in_summaries", 650, 120)}}
+{{EmbedLiveSample("HTML_in_summaries", 650, 150)}}
 
 ### Ändern des Symbols der Zusammenfassung
 
-Das Markerzeichen des `<summary>`-Elements, das Offenlegungsdreieck, kann mit CSS angepasst werden. Der Marker kann mit dem {{cssxref("::marker")}}-Pseudo-Element angesprochen werden, das die {{cssxref("list-style")}}-Kurzform-Eigenschaft und seine Langform-Komponenten-Eigenschaften, wie {{cssxref("list-style-type")}}, akzeptiert. Dies ermöglicht es, das Dreieck in ein Bild (normalerweise mit {{cssxref("list-style-image")}}) oder eine Zeichenfolge (einschließlich Emojis) zu ändern. In diesem Beispiel ersetzen wir den Inhalt eines Offenlegungs-Widgets und entfernen das Symbol von einem anderen, indem wir `list-style: none` vor der Hinzufügung eines benutzerdefinierten Offenlegungssymbols über generierten Inhalt setzen.
+Das Marker-Symbol des `<summary>`-Elements, das Dreieck, kann mit CSS angepasst werden. Der Marker kann mit dem {{cssxref("::marker")}}-Pseudoelement angesprochen werden, das die {{cssxref("list-style")}}-Kurzschreibweise und dessen Langhand-Komponenten-Eigenschaften akzeptiert, wie z. B. {{cssxref("list-style-type")}}. Dadurch kann das Dreieck in ein Bild (normalerweise mit {{cssxref("list-style-image")}}) oder eine Zeichenkette (einschließlich Emojis) geändert werden. In diesem Beispiel ersetzen wir den Inhalt eines Disclosure-Widgets und entfernen das Symbol von einem anderen, indem wir `list-style: none` setzen, bevor wir ein benutzerdefiniertes Disclosure-Symbol über generierten Inhalt hinzufügen.
 
 #### CSS
 
-Im ersten Offenlegungs-Widget gestalten wir den `::marker` und ändern den {{cssxref("content")}} basierend auf dem `[open]`-Attribut des `<details>`-Elements. Für das zweite Widget entfernen wir den Marker mit `list-style`-Eigenschaften und fügen dann gestalteten generierten Inhalt mit dem {{cssxref("::after")}}-Pseudo-Element hinzu. Wir haben auch Stile für `::-webkit-details-marker` hinzugefügt, um Safari anzusprechen. Der Selektor für das browserspezifische Pseudo-Element ist in einer {{cssxref(":is()")}}-Pseudo-Klasse enthalten, um die Selektorliste nicht zu invalidieren.
+Im ersten Disclosure-Widget gestalten wir den `::marker`, indem wir den {{cssxref("content")}} auf Basis des `[open]`-Attributs des `<details>`-Elements ändern. Für das zweite Widget entfernen wir den Marker mit `list-style`-Eigenschaften und fügen dann gestylte generierte Inhalte mit dem {{cssxref("::after")}}-Pseudoelement hinzu. Wir fügen auch Stile für `::-webkit-details-marker` hinzu, um Safari zu adressieren. Der Selektor für das browserspezifische Pseudoelement ist in einer {{cssxref(":is()")}}-Pseudo-Klasse enthalten, sodass er die Selektorliste nicht ungültig macht.
 
 ```css
 details {
@@ -152,41 +152,37 @@ details:last-of-type summary::-webkit-details-marker {
 }
 ```
 
-Das CSS enthält den `[open]` [Attributselektor](/de/docs/Web/CSS/Attribute_selectors), der nur dann zutrifft, wenn das Attribut `open` vorhanden ist (wenn die `<details>` offen sind). Die {{cssxref(":first-of-type")}}- und {{cssxref(":last-of-type")}}-Pseudo-Klassen richten sich an die ersten und Geschwisterelemente desselben Typs. Wir haben das `-webkit-`-pseudoelement mit Präfix in eine {{cssxref(":is()")}}-Pseudo-Klasse einbezogen, da es eine [vergebende Selektorliste](/de/docs/Web/CSS/Selector_list#forgiving_selector_list) akzeptiert, sodass der gesamte Selektorblock nicht ungültig wird, wenn das Pseudo-Element mit Präfix in einem Browser ungültig ist. Wir haben auch das CSS [Verschachtelung](/de/docs/Web/CSS/Nesting_selector) verwendet. Siehe das Modul [CSS-Selektoren](/de/docs/Web/CSS/CSS_selectors).
+Das CSS enthält den `[open]` [Attributsselektor](/de/docs/Web/CSS/Attribute_selectors), der nur übereinstimmt, wenn das `open`-Attribut vorhanden ist (wenn die `<details>` geöffnet sind). Die {{cssxref(":first-of-type")}} und {{cssxref(":last-of-type")}} Pseudo-Klassen zielen auf das erste und Geschwisterelemente des gleichen Typs. Wir haben das mit `-webkit-` präfixierte Pseudoelement innerhalb einer {{cssxref(":is()")}}-Pseudoklasse aufgenommen, da es eine [verzeihende Selektorliste](/de/docs/Web/CSS/Selector_list#forgiving_selector_list) erfordert, sodass, falls das präfixierte Pseudoelement in einem Browser ungültig ist, der gesamte Selektorblock nicht ungültig ist. Wir haben auch CSS [Verschachtelung](/de/docs/Web/CSS/Nesting_selector) verwendet. Siehe das [CSS-Selektoren](/de/docs/Web/CSS/CSS_selectors) Modul.
 
 #### HTML
 
-```html
+```html-nolint
 <details>
   <h1>Quotes from Helen Keller</h1>
   <summary>On women's rights</summary>
   <p>
-    <q
-      >We have prayed, we have coaxed, we have begged, for the vote, with the
+    <q>We have prayed, we have coaxed, we have begged, for the vote, with the
       hope that men, out of chivalry, would bestow equal rights upon women and
       take them into partnership in the affairs of the state. We hoped that
       their common sense would triumph over prejudices and stupidity. We thought
       their boasted sense of justice would overcome the errors that so often
       fetter the human spirit; but we have always gone away empty-handed. We
-      shall beg no more.</q
-    >
+      shall beg no more.</q>
   </p>
 </details>
 
 <details>
   <summary>On optimism</summary>
   <p>
-    <q
-      >Optimism is the faith that leads to achievement; nothing can be done
-      without hope.</q
-    >
+    <q>Optimism is the faith that leads to achievement; nothing can be done
+      without hope.</q>
   </p>
 </details>
 ```
 
 #### Ergebnis
 
-{{EmbedLiveSample("Changing the summary's icon", 650, 150)}}
+{{EmbedLiveSample("Changing the summary's icon", 650, 400)}}
 
 ## Technische Zusammenfassung
 
@@ -203,22 +199,22 @@ Das CSS enthält den `[open]` [Attributselektor](/de/docs/Web/CSS/Attribute_sele
       </td>
     </tr>
     <tr>
-      <th scope="row">Erlaubter Inhalt</th>
+      <th scope="row">Zulässiger Inhalt</th>
       <td>
         <a href="/de/docs/Web/HTML/Content_categories#phrasing_content"
           >Phrasierungsinhalt</a
-        >, optional gemischt mit
+        >, optional durchmischt mit
         <a href="/de/docs/Web/HTML/Content_categories#heading_content"
-          >Überschrifteninhalt</a
+          >Überschrift-Inhalt</a
         >
       </td>
     </tr>
     <tr>
-      <th scope="row">Tag-Auslassung</th>
-      <td>Keiner; sowohl das Start- als auch das End-Tag sind obligatorisch.</td>
+      <th scope="row">Tag-Wege lassen</th>
+      <td>Keine; sowohl das Start-Tag als auch das End-Tag sind obligatorisch.</td>
     </tr>
     <tr>
-      <th scope="row">Erlaubte Eltern</th>
+      <th scope="row">Zulässige Eltern</th>
       <td>Das {{HTMLElement("details")}}-Element.</td>
     </tr>
     <tr>
@@ -226,7 +222,7 @@ Das CSS enthält den `[open]` [Attributselektor](/de/docs/Web/CSS/Attribute_sele
       <td> <a href="https://www.w3.org/TR/html-aria/#dfn-no-corresponding-role">Keine entsprechende Rolle</a></td>
     </tr>
     <tr>
-      <th scope="row">Erlaubte ARIA-Rollen</th>
+      <th scope="row">Zulässige ARIA-Rollen</th>
       <td>Keine <code>role</code> erlaubt</td>
     </tr>
     <tr>
@@ -238,11 +234,11 @@ Das CSS enthält den `[open]` [Attributselektor](/de/docs/Web/CSS/Attribute_sele
 
 ## Spezifikationen
 
-{{Specifications}}
+{{Spezifikationen}}
 
 ## Browser-Kompatibilität
 
-{{Compat}}
+{{Kompatibilität}}
 
 ## Siehe auch
 
diff --git a/files/de/web/http/csp/index.md b/files/de/web/http/csp/index.md
index 5d89b6988..1c95ed99b 100644
--- a/files/de/web/http/csp/index.md
+++ b/files/de/web/http/csp/index.md
@@ -2,30 +2,30 @@
 title: Content Security Policy (CSP)
 slug: Web/HTTP/CSP
 l10n:
-  sourceCommit: 4d12b3e4f9afb311f2656641260e42c0b6f8f4c6
+  sourceCommit: 9c09d1ce824bd5e6ef879094428879c476ccbace
 ---
 
 {{HTTPSidebar}}
 
-**Content Security Policy** (CSP) ist ein Feature, das dabei hilft, bestimmte Arten von Sicherheitsbedrohungen zu verhindern oder das Risiko zu minimieren. Es besteht aus einer Reihe von Instruktionen von einer Website an einen Browser, die den Browser anweisen, Einschränkungen für die Dinge zu setzen, die der Code der Seite tun darf.
+Die **Content Security Policy** (CSP) ist eine Funktion, die hilft, das Risiko bestimmter Arten von Sicherheitsbedrohungen zu verhindern oder zu minimieren. Sie besteht aus einer Reihe von Anweisungen einer Website an einen Browser, die dem Browser auftragen, Einschränkungen für die Dinge zu setzen, die der Code der Seite tun darf.
 
-Der Hauptanwendungsfall für CSP ist die Kontrolle darüber, welche Ressourcen, insbesondere JavaScript-Ressourcen, ein Dokument laden darf. Dies wird hauptsächlich als Schutz gegen {{Glossary("cross-site_scripting", "Cross-Site Scripting")}} (XSS)-Angriffe verwendet, bei denen ein Angreifer in der Lage ist, bösartigen Code in die Website des Opfers einzuschleusen.
+Der Hauptanwendungsfall für CSP besteht darin, zu kontrollieren, welche Ressourcen, insbesondere JavaScript-Ressourcen, ein Dokument laden darf. Dies wird hauptsächlich als Schutz gegen {{Glossary("cross-site_scripting", "Cross-Site-Scripting")}} (XSS) Angriffe verwendet, bei denen ein Angreifer in der Lage ist, böswilligen Code in die Seite des Opfers einzuschleusen.
 
-Eine CSP kann auch andere Zwecke haben, einschließlich des Schutzes gegen {{Glossary("clickjacking", "Clickjacking")}} und der Sicherstellung, dass die Seiten einer Website über HTTPS geladen werden.
+Eine CSP kann auch andere Zwecke erfüllen, einschließlich des Schutzes gegen [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) und der Sicherstellung, dass die Seiten einer Website über HTTPS geladen werden.
 
-In diesem Leitfaden beginnen wir damit zu beschreiben, wie eine CSP an einen Browser übermittelt wird und wie sie auf hoher Ebene aussieht.
+In diesem Leitfaden beginnen wir damit zu beschreiben, wie eine CSP an einen Browser geliefert wird und wie sie auf hoher Ebene aussieht.
 
-Dann beschreiben wir, wie sie verwendet werden kann, um [die geladenen Ressourcen zu kontrollieren](#kontrolle_des_ressourcenladens), um sich gegen XSS zu schützen, sowie andere Anwendungsfälle wie [Clickjacking-Schutz](#clickjacking-schutz) und [Upgrade unsicherer Anfragen](#upgrade_unsicherer_anfragen). Beachten Sie, dass es keine Abhängigkeit zwischen den verschiedenen Anwendungsfällen gibt: Wenn Sie nur Clickjacking-Schutz hinzufügen möchten, aber keine Maßnahmen gegen XSS ergreifen, können Sie einfach die Direktiven für diesen Anwendungsfall hinzufügen.
+Anschließend beschreiben wir, wie sie verwendet werden kann, um [zu kontrollieren, welche Ressourcen geladen werden](#kontrolle_der_ressourcenladung), um sich gegen XSS zu schützen, und dann andere Anwendungsfälle wie [Schutz gegen Clickjacking](#clickjacking-schutz) und [Upgrade unsicherer Anfragen](#upgrade_unsicherer_anfragen). Beachten Sie, dass es keine Abhängigkeit zwischen den verschiedenen Anwendungsfällen gibt: Wenn Sie Clickjacking-Schutz hinzufügen möchten, aber nicht die XSS-Milderung, können Sie einfach die Richtlinien für diesen Anwendungsfall hinzufügen.
 
-Schließlich werden wir [Strategien zur Implementierung einer CSP](#testen_ihrer_richtlinie) und Tools beschreiben, die helfen können, diesen Prozess zu erleichtern.
+Abschließend beschreiben wir [Strategien für die Bereitstellung einer CSP](#testen_ihrer_richtlinie) und Tools, die diesen Prozess vereinfachen können.
 
-## Überblick über CSP
+## CSP-Übersicht
 
-Eine CSP sollte dem Browser im {{httpheader("Content-Security-Policy")}}-Antwort-Header übermittelt werden. Sie sollte in allen Antworten auf alle Anfragen gesetzt werden, nicht nur im Hauptdokument.
+Eine CSP sollte dem Browser im {{httpheader("Content-Security-Policy")}} Antwort-Header bereitgestellt werden. Sie sollte bei allen Antworten auf alle Anfragen gesetzt werden, nicht nur im Hauptdokument.
 
-Sie können sie auch mit dem [`http-equiv`](/de/docs/Web/HTML/Element/meta#http-equiv)-Attribut des {{htmlelement("meta")}}-Elements Ihres Dokuments angeben, und dies ist eine nützliche Option für einige Anwendungsfälle, wie zum Beispiel eine clientseitig gerenderte {{Glossary("SPA", "Single Page App")}}, die nur statische Ressourcen hat, da Sie dann auf die Abhängigkeit von einer Serverinfrastruktur verzichten können. Allerdings unterstützt diese Option nicht alle CSP-Funktionen.
+Sie können es auch mit dem [`http-equiv`](/de/docs/Web/HTML/Element/meta#http-equiv) Attribut Ihres Dokuments {{htmlelement("meta")}} Elements angeben, und dies ist eine nützliche Option für einige Anwendungsfälle, wie eine clientseitig gerenderte {{Glossary("SPA", "Single Page App")}}, die nur statische Ressourcen hat, da Sie dann nicht auf eine Serverinfrastruktur angewiesen sind. Diese Option unterstützt jedoch nicht alle CSP-Funktionen.
 
-Die Richtlinie wird als eine Reihe von _Direktiven_ spezifiziert, die durch Semikolons getrennt sind. Jede Direktive steuert einen anderen Aspekt der Sicherheitsrichtlinie. Jede Direktive hat einen Namen, gefolgt von einem Leerzeichen und einem Wert. Verschiedene Direktiven können unterschiedliche Syntaxen haben.
+Die Richtlinie wird als eine Reihe von _Direktiven_ angegeben, die durch Semikolons getrennt sind. Jede Direktive steuert einen anderen Aspekt der Sicherheitsrichtlinie. Jede Direktive hat einen Namen, gefolgt von einem Leerzeichen, gefolgt von einem Wert. Unterschiedliche Direktiven können unterschiedliche Syntaxen haben.
 
 Betrachten Sie zum Beispiel die folgende CSP:
 
@@ -33,44 +33,44 @@ Betrachten Sie zum Beispiel die folgende CSP:
 Content-Security-Policy: default-src 'self'; img-src 'self' example.com
 ```
 
-Es setzt zwei Direktiven:
+Sie setzt zwei Direktiven:
 
-- die `default-src`-Direktive ist auf `'self'` gesetzt
-- die `img-src`-Direktive ist auf `'self' example.com` gesetzt.
+- die `default-src` Direktive ist auf `'self'` gesetzt
+- die `img-src` Direktive ist auf `'self' example.com` gesetzt.
 
-![Eine CSP, die in ihre Direktiven aufgeteilt ist.](csp-overview.svg)
+![Eine CSP, aufgeteilt in ihre Direktiven.](csp-overview.svg)
 
-Die erste Direktive, `default-src`, weist den Browser an, nur Ressourcen zu laden, die mit dem Dokument die gleiche Herkunft haben, es sei denn, andere spezifischere Direktiven setzen eine andere Richtlinie für andere Ressourcentypen. Die zweite, `img-src`, weist den Browser an, Bilder zu laden, die entweder aus derselben Herkunft stammen oder von `example.com` bereitgestellt werden.
+Die erste Direktive, `default-src`, weist den Browser an, nur Ressourcen zu laden, die mit dem Dokument gleichgeordnet sind, es sei denn, andere spezifischere Direktiven setzen eine andere Richtlinie für andere Ressourcentypen. Die zweite, `img-src`, weist den Browser an, Bilder zu laden, die entweder gleichgeordnet oder von `example.com` bereitgestellt werden.
 
-Im nächsten Abschnitt werden wir die verfügbaren Werkzeuge betrachten, um das Laden von Ressourcen zu kontrollieren, was die Hauptfunktion einer CSP ist.
+Im nächsten Abschnitt betrachten wir die verfügbaren Tools zur Kontrolle der Ressourcenladungen, was die Hauptfunktion einer CSP ist.
 
-## Kontrolle des Ressourcenladens
+## Kontrolle der Ressourcenladung
 
-Eine CSP kann verwendet werden, um die Ressourcen zu kontrollieren, die ein Dokument laden darf. Dies wird in erster Linie zum Schutz vor Cross-Site Scripting (XSS)-Angriffen eingesetzt.
+Eine CSP kann verwendet werden, um die Ressourcen zu kontrollieren, die ein Dokument laden darf. Dies wird hauptsächlich zum Schutz gegen Cross-Site-Scripting (XSS) Angriffe verwendet.
 
-In diesem Abschnitt werden wir zunächst sehen, wie die Kontrolle des Ressourcenladens helfen kann, sich gegen XSS zu schützen, dann die Tools, die CSP bietet, um zu kontrollieren, welche Ressourcen geladen werden. Schließlich beschreiben wir eine besonders empfohlene Strategie, die als "strikte CSP" bezeichnet wird.
+In diesem Abschnitt werden wir zuerst sehen, wie die Kontrolle der Ressourcenladungen dazu beitragen kann, sich vor XSS zu schützen, dann die von CSP bereitgestellten Tools, um zu kontrollieren, welche Ressourcen geladen werden. Schließlich beschreiben wir eine bestimmte empfohlene Strategie, die als "Strict CSP" bekannt ist.
 
-### XSS und Ressourcenladen
+### XSS und Ressourcenladung
 
-Ein Cross-Site Scripting (XSS)-Angriff ist einer, bei dem ein Angreifer in der Lage ist, seinen Code im Kontext der Ziel-Website auszuführen. Dieser Code kann dann alles tun, was der eigene Code der Website tun könnte, einschließlich zum Beispiel:
+Ein Cross-Site-Scripting (XSS) Angriff ist einer, bei dem ein Angreifer seinen Code im Kontext der Zielwebsite ausführen kann. Dieser Code kann dann alles tun, was der eigene Code der Website könnte, einschließlich zum Beispiel:
 
-- Zugriff oder Änderung der Inhalte der geladenen Seiten der Website
-- Zugang zu oder Änderung von Inhalten im lokalen Speicher
-- HTTP-Anfragen mit den Anmeldedaten des Nutzers stellen, wodurch er sich als der Nutzer ausgeben oder auf sensible Daten zugreifen kann
+- Zugriff auf oder Modifikation des Inhalts der geladenen Seiten der Website
+- Zugriff auf oder Modifikation von Inhalten im lokalen Speicher
+- Ausführung von HTTP-Anfragen mit den Anmeldeinformationen des Benutzers, was es ihm ermöglicht, den Benutzer zu imitieren oder auf sensible Daten zuzugreifen
 
-Ein XSS-Angriff ist möglich, wenn eine Website eine Eingabe akzeptiert, die von einem Angreifer manipuliert worden sein könnte (zum Beispiel URL-Parameter oder ein Kommentar zu einem Blogbeitrag), und diese dann in die Seite einbindet, ohne sie zu _bereinigen_: das heißt, ohne sicherzustellen, dass sie nicht als JavaScript ausgeführt werden kann.
+Ein XSS-Angriff ist möglich, wenn eine Website eine Eingabe akzeptiert, die von einem Angreifer erstellt worden sein könnte (zum Beispiel URL-Parameter oder ein Kommentar zu einem Blog-Beitrag) und diese dann in die Seite einfügt, ohne sie zu _säubern_: Das bedeutet, ohne sicherzustellen, dass sie nicht als JavaScript ausgeführt werden kann.
 
-Websites sollten sich vor XSS schützen, indem sie diese Eingaben bereinigen, bevor sie in die Seite eingebunden werden. Eine CSP bietet einen ergänzenden Schutz, der die Website auch dann schützen kann, wenn die Bereinigung fehlschlägt.
+Websites sollten sich gegen XSS schützen, indem sie diese Eingaben säubern, bevor sie in die Seite eingefügt werden. Eine CSP bietet einen ergänzenden Schutz, der die Website schützen kann, selbst wenn die Säuberung fehlschlägt.
 
-Wenn die Bereinigung tatsächlich fehlschlägt, können die injizierten bösartigen Codes verschiedene Formen im Dokument annehmen, einschließlich:
+Wenn die Säuberung fehlschlägt, können verschiedene Formen bösartiger, eingeschleuster Code im Dokument angenommen werden, darunter:
 
-- Ein {{htmlelement("script")}}-Tag, das auf eine bösartige Quelle verweist:
+- Ein {{htmlelement("script")}} Tag, das auf eine bösartige Quelle verweist:
 
   ```html
   <script src="https://evil.example.com/hacker.js"></script>
   ```
 
-- Ein `<script>`-Tag, das Inline-JavaScript enthält:
+- Ein `<script>` Tag, das inline JavaScript enthält:
 
   ```html
   <script>
@@ -78,19 +78,19 @@ Wenn die Bereinigung tatsächlich fehlschlägt, können die injizierten bösarti
   </script>
   ```
 
-- Ein Inline-Ereignis-Handler:
+- Ein inline Event-Handler:
 
   ```html
   <img onmouseover="console.log(`You've been hacked!`)" />
   ```
 
-- Eine `javascript:`-URL:
+- Eine `javascript:` URL:
 
   ```html
   <iframe src="javascript:console.log(`You've been hacked!`)"></iframe>
   ```
 
-- Ein Zeichenfolgenargument für eine unsichere API wie [`eval()`](/de/docs/Web/JavaScript/Reference/Global_Objects/eval):
+- Ein Zeichenfolgen-Argument für eine unsichere API wie [`eval()`](/de/docs/Web/JavaScript/Reference/Global_Objects/eval):
 
   ```js
   eval("console.log(`You've been hacked!`)");
@@ -98,80 +98,80 @@ Wenn die Bereinigung tatsächlich fehlschlägt, können die injizierten bösarti
 
 Eine CSP kann Schutz gegen all diese bieten. Mit einer CSP können Sie:
 
-- die erlaubten Quellen für JavaScript-Dateien und andere Ressourcen definieren, wodurch effektiv das Laden von `https://evil.example.com` blockiert wird
+- die erlaubten Quellen für JavaScript-Dateien und andere Ressourcen definieren, wodurch effektiv das Laden aus `https://evil.example.com` blockiert wird
 - Inline-Skript-Tags deaktivieren
-- nur Skript-Tags erlauben, die mit einem korrekten Nonce oder Hash versehen sind
-- Inline-Ereignis-Handler deaktivieren
-- `javascript:`-URLs deaktivieren
+- nur Skript-Tags zulassen, die das korrekte Nonce oder den Hash gesetzt haben
+- Inline-Event-Handler deaktivieren
+- `javascript:` URLs deaktivieren
 - gefährliche APIs wie `eval()` deaktivieren
 
-Im nächsten Abschnitt werden wir die Werkzeuge besprechen, die CSP bietet, um diese Dinge zu tun.
+Im nächsten Abschnitt gehen wir auf die Tools ein, die CSP bereitstellt, um diese Dinge zu tun.
 
 > [!NOTE]
-> Das Setzen einer CSP ist kein Ersatz für die Bereinigung von Eingaben. Websites sollten Eingaben bereinigen _und_ eine CSP setzen, um einen tiefgehenden Schutz gegen XSS zu gewährleisten.
+> Das Setzen einer CSP ist keine Alternative zur Eingabereinigung. Websites sollten Eingaben reinigen _und_ eine CSP setzen, um einen umfassenden Schutz gegen XSS zu bieten.
 
 ### Fetch-Direktiven
 
-Fetch-Direktiven werden verwendet, um eine bestimmte Kategorie von Ressourcen anzugeben, die ein Dokument laden darf — wie JavaScript, CSS-Stylesheets, Bilder, Schriftarten und so weiter.
+Fetch-Direktiven werden verwendet, um eine bestimmte Kategorie von Ressourcen anzugeben, die ein Dokument laden darf – wie JavaScript, CSS-Stylesheets, Bilder, Schriftarten und so weiter.
 
 Es gibt unterschiedliche Fetch-Direktiven für verschiedene Arten von Ressourcen. Zum Beispiel:
 
-- [`script-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) legt erlaubte Quellen für JavaScript fest.
-- [`style-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/style-src) legt erlaubte Quellen für CSS-Stylesheets fest.
-- [`img-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/img-src) legt erlaubte Quellen für Bilder fest.
+- [`script-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) legt die erlaubten Quellen für JavaScript fest.
+- [`style-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/style-src) legt die erlaubten Quellen für CSS-Stylesheets fest.
+- [`img-src`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/img-src) legt die erlaubten Quellen für Bilder fest.
 
-Eine spezielle Fetch-Direktive ist `default-src`, die eine Fallback-Richtlinie für alle Ressourcen festlegt, deren Direktiven nicht explizit aufgelistet sind.
+Eine besondere Fetch-Direktive ist `default-src`, die eine Fallback-Richtlinie für alle Ressourcen setzt, deren Direktiven nicht explizit aufgeführt sind.
 
 Für die vollständige Liste der Fetch-Direktiven siehe die [Referenzdokumentation](/de/docs/Web/HTTP/Headers/Content-Security-Policy#fetch_directives).
 
-Jede Fetch-Direktive wird entweder als einzelnes Schlüsselwort `'none'` oder als eine oder mehrere _Quell-Ausdrücke_ angegeben, getrennt durch Leerzeichen. Wenn mehr als ein Quell-Ausdruck angegeben ist: Wenn eine der Methoden die Ressource erlaubt, dann ist die Ressource erlaubt.
+Jede Fetch-Direktive wird entweder als einzelnes Schlüsselwort `'none'` oder durch eine oder mehrere _Quellausdrücke_, getrennt durch Leerzeichen, angegeben. Wenn mehr als ein Quellausdruck aufgeführt ist: Wenn eine der Methoden die Ressource erlaubt, wird die Ressource erlaubt.
 
 Zum Beispiel setzt die untenstehende CSP zwei Fetch-Direktiven:
 
-- `default-src` erhält den einzelnen Quell-Ausdruck `'self'`
-- `img-src` erhält zwei Quell-Ausdrücke: `'self'` und `example.com`
+- `default-src` wird der einzelne Quellausdruck `'self'` gegeben
+- `img-src` wird zwei Quellausdrücke gegeben: `'self'` und `example.com`
 
-![CSP-Diagramm, das Quell-Ausdrücke zeigt](csp-source-expressions.svg)
+![CSP-Diagramm mit Quellausdrücken](csp-source-expressions.svg)
 
 Die Wirkung davon ist, dass:
 
-- Bilder entweder aus derselben Herkunft wie das Dokument stammen müssen oder von `example.com` geladen werden
-- alle anderen Ressourcen aus derselben Herkunft wie das Dokument stammen müssen.
+- Bilder entweder gleichgeordnet mit dem Dokument sein müssen oder von `example.com` geladen werden
+- alle anderen Ressourcen gleichgeordnet mit dem Dokument sein müssen.
 
-In den nächsten Abschnitten werden wir einige der Möglichkeiten beschreiben, wie Sie Quell-Ausdrücke verwenden können, um das Laden von Ressourcen zu kontrollieren. Beachten Sie, dass diese Ausdrücke, obwohl wir sie getrennt beschreiben, im Allgemeinen kombiniert werden können: Zum Beispiel kann eine einzelne Fetch-Direktive sowohl Nonces als auch Hostnamen enthalten.
+In den nächsten Abschnitten beschreiben wir einige der Möglichkeiten, wie Sie Quellausdrücke verwenden können, um Ressourcenladen zu kontrollieren. Beachten Sie, dass, obwohl wir sie getrennt beschreiben, diese Ausdrücke im Allgemeinen kombiniert werden können: zum Beispiel kann eine einzelne Fetch-Direktive sowohl Nonces als auch Hostnames einschließen.
 
 #### Blockieren von Ressourcen
 
-Um eine Art von Ressource vollständig zu blockieren, verwenden Sie das `'none'`-Schlüsselwort. Zum Beispiel blockiert die folgende Direktive alle {{htmlelement("object")}}- und {{htmlelement("embed")}}-Ressourcen:
+Um einen Ressourcentyp vollständig zu blockieren, verwenden Sie das Schlüsselwort `'none'`. Zum Beispiel blockiert die folgende Direktive alle {{htmlelement("object")}} und {{htmlelement("embed")}} Ressourcen:
 
 ```http
 Content-Security-Policy: object-src 'none'
 ```
 
-Beachten Sie, dass `'none'` nicht mit einer anderen Methode in einer bestimmten Direktive kombiniert werden kann: In der Praxis werden alle anderen Quell-Ausdrücke ignoriert, wenn sie neben `'none'` angegeben werden.
+Beachten Sie, dass `'none'` nicht mit einer anderen Methode in einer bestimmten Direktive kombiniert werden kann: In der Praxis, wenn neben `'none'` andere Quellausdrücke angegeben sind, werden diese ignoriert.
 
 #### Nonces
 
-Ein `nonce` ist die empfohlene Methode, um das Laden von {{htmlelement("script")}}- und {{htmlelement("style")}}-Ressourcen einzuschränken.
+Ein `nonce` ist der empfohlene Ansatz, um das Laden von {{htmlelement("script")}} und {{htmlelement("style")}} Ressourcen zu beschränken.
 
-Bei einem Nonce generiert der Server einen zufälligen Wert für jede HTTP-Antwort und fügt ihn in eine `script-src`-und/oder eine `style-src`-Direktive ein:
+Mit einem Nonce generiert der Server einen zufälligen Wert für jede HTTP-Antwort und fügt ihn in eine `script-src` und/oder eine `style-src` Direktive ein:
 
 ```http
 Content-Security-Policy:
   script-src 'nonce-416d1177-4d12-4e3b-b7c9-f6c409789fb8'
 ```
 
-Der Server schließt diesen Wert dann als Wert des `nonce`-Attributs in allen `<script>`-und/oder `<style>`-Tags ein, die er in das Dokument einfügen möchte.
+Der Server fügt diesen Wert dann als Wert des `nonce` Attributs in alle `<script>` und/oder `<style>` Tags ein, die er in das Dokument aufnehmen möchte.
 
-Der Browser vergleicht die beiden Werte und lädt die Ressource nur, wenn sie übereinstimmen. Die Idee ist, dass selbst wenn ein Angreifer JavaScript in die Seite einfügen kann, er nicht wissen wird, welches Nonce der Server verwenden wird, sodass der Browser sich weigern wird, das Skript auszuführen.
+Der Browser vergleicht die beiden Werte und lädt die Ressource nur, wenn sie übereinstimmen. Die Idee ist, dass selbst wenn ein Angreifer JavaScript in die Seite einfügen kann, er nicht weiß, welches Nonce der Server verwenden wird, sodass der Browser das Skript nicht ausführen wird.
 
-Damit dieser Ansatz funktioniert, darf es einem Angreifer nicht möglich sein, das Nonce zu erraten.
+Damit dieser Ansatz funktioniert, darf es einem Angreifer nicht möglich sein, das Nonce vorherzusagen.
 
 **In der Praxis bedeutet dies, dass das Nonce für jede HTTP-Antwort unterschiedlich sein muss und nicht vorhersehbar sein darf.**
 
-Dies bedeutet wiederum, dass der Server kein statisches HTML liefern kann, da er jedes Mal ein neues Nonce einfügen muss. In der Regel würde der Server eine Template-Engine verwenden, um das Nonce einzufügen.
+Dies bedeutet wiederum, dass der Server kein statisches HTML bereitstellen kann, da er jedes Mal ein neues Nonce einfügen muss. Typischerweise würde der Server eine Template-Engine verwenden, um das Nonce einzufügen.
 
-Hier ist ein Code-Snippet von [Express](/de/docs/Learn/Server-side/Express_Nodejs), um das zu demonstrieren:
+Hier ist ein Snippet von [Express](/de/docs/Learn/Server-side/Express_Nodejs) Code zur Demonstration:
 
 ```js
 function content(nonce) {
@@ -189,23 +189,23 @@ app.get("/", (req, res) => {
 });
 ```
 
-Bei jeder Anfrage generiert der Server ein neues Nonce, fügt es in die CSP und in die {{htmlelement("script")}}-Tags im zurückgegebenen Dokument ein. Beachten Sie, dass der Server:
+Bei jeder Anforderung generiert der Server ein neues Nonce, fügt es in die CSP und in die {{htmlelement("script")}} Tags im zurückgegebenen Dokument ein. Beachten Sie, dass der Server:
 
-- für jede Anfrage ein neues Nonce generiert
-- Nonces sowohl mit externen als auch Inline-Skripten verwenden kann
-- dasselbe Nonce für alle `<script>`-Tags im Dokument verwendet
+- für jede Anfrage ein neues Nonce erzeugt
+- Nonces sowohl mit externen als auch Inline-Skripts verwenden kann
+- das gleiche Nonce für alle `<script>` Tags im Dokument verwendet
 
-Es ist wichtig, dass der Server eine Art von Templating verwendet, um Nonces einzufügen, und sie nicht einfach in alle `<script>`-Tags einfügt: Ansonsten könnte der Server unbeabsichtigt Nonces in Skripte einfügen, die von einem Angreifer eingeschleust wurden.
+Es ist wichtig, dass der Server eine Art Templating verwendet, um Nonces einzufügen, und nicht einfach alle `<script>` Tags zu versehen: Ansonsten könnte der Server versehentlich Nonces in Skripts einfügen, die von einem Angreifer eingeschleust wurden.
 
-Beachten Sie, dass Nonces nur für Elemente verwendet werden können, die ein `nonce`-Attribut haben: das heißt, nur `<script>`-und `<style>`-Elemente.
+Beachten Sie, dass Nonces nur für Elemente verwendet werden können, die ein `nonce` Attribut haben: das heißt, nur `<script>` und `<style>` Elemente.
 
 #### Hashes
 
-Fetch-Direktiven können auch einen Hash des Skripts verwenden, um seine Integrität zu garantieren. Mit dieser Methode:
+Fetch-Direktiven können auch einen Hash des Skripts verwenden, um dessen Integrität zu garantieren. Bei diesem Verfahren:
 
-1. berechnet der Server einen Hash des Skriptinhalts mit einer {{Glossary("cryptographic_hash_function", "kryptografischen Hash-Funktion")}} (eine von SHA-256, SHA-384 oder SHA-512)
-2. erstellt eine {{Glossary("Base64", "Base64")}}-Kodierung des Ergebnisses
-3. fügt ein Präfix hinzu, das den verwendeten Hash-Algorithmus identifiziert (eine von `sha256-`, `sha384-` oder `sha512-`).
+1. berechnet der Server einen Hash der Skriptinhalte mit einer {{Glossary("cryptographic_hash_function", "kryptografischen Hash-Funktion")}} (eine von SHA-256, SHA-384, oder SHA-512)
+2. erstellt eine {{Glossary("Base64", "Base64")}} Codierung des Ergebnisses
+3. fügt als Präfix den Hash-Algorithmus hinzu, der verwendet wurde (einer von `sha256-`, `sha384-`, oder `sha512-`).
 
 Dann fügt er das Ergebnis der Direktive hinzu:
 
@@ -213,11 +213,11 @@ Dann fügt er das Ergebnis der Direktive hinzu:
 Content-Security-Policy: script-src 'sha256-cd9827ad...'
 ```
 
-Wenn der Browser das Dokument erhält, hasht er das Skript, vergleicht das Ergebnis mit dem Wert aus dem Header und lädt das Skript nur, wenn sie übereinstimmen.
+Wenn der Browser das Dokument erhält, hasht er das Skript, vergleicht das Ergebnis mit dem Wert im Header und lädt das Skript nur, wenn diese übereinstimmen.
 
-Externe Skripte müssen für diese Methode auch das Attribut [`integrity`](/de/docs/Web/HTML/Element/script#integrity) enthalten.
+Externe Skripts müssen auch das [`integrity`](/de/docs/Web/HTML/Element/script#integrity) Attribut enthalten, damit diese Methode funktioniert.
 
-Hier ist ein Express-Code-Snippet, um dies zu demonstrieren:
+Hier ist ein Snippet von Express-Code zur Demonstration:
 
 ```js
 const hash1 = "sha256-ex2O7MWOzfczthhKm6azheryNVoERSFrPrdvxRtP8DI=";
@@ -236,15 +236,15 @@ app.get("/", (req, res) => {
 });
 ```
 
-Beachten Sie, dass:
+Beachten Sie:
 
-- wir einen separaten Hash für jedes Skript im Dokument haben.
-- für das externe Skript "main.js" geben wir auch das Attribut `integrity` an und geben ihm denselben Wert.
-- im Gegensatz zum Beispiel mit Nonces sowohl die CSP als auch der Inhalt statisch sein können, da die Hashes gleich bleiben. Dies macht hash-basierte Richtlinien besser geeignet für statische Seiten oder Websites, die auf clientseitigem Rendering basieren.
+- Wir haben einen separaten Hash für jedes Skript im Dokument.
+- Für das externe Skript "main.js" fügen wir auch das `integrity` Attribut hinzu und geben ihm denselben Wert.
+- Im Gegensatz zum Beispiel mit Nonces können sowohl die CSP als auch der Inhalt statisch sein, da die Hashes gleich bleiben. Dies macht hash-basierte Richtlinien besser geeignet für statische Seiten oder Websites, die auf clientseitiges Rendering angewiesen sind.
 
 #### Schema-basierte Richtlinien
 
-Fetch-Direktiven können ein Schema auflisten, wie `https:`, um Ressourcen zu erlauben, die mit diesem Schema bereitgestellt werden. Dies erlaubt es einer Richtlinie beispielsweise, HTTPS für alle Ressourcentypen zu verlangen:
+Fetch-Direktiven können ein Schema, wie `https:`, auflisten, um Ressourcen zu erlauben, die mit diesem Schema bereitgestellt werden. Dies ermöglicht es beispielsweise, eine Richtlinie zu erfordern, dass alle Ressourcen über HTTPS geladen werden:
 
 ```http
 Content-Security-Policy: default-src https:
@@ -252,21 +252,21 @@ Content-Security-Policy: default-src https:
 
 #### Standortbasierte Richtlinien
 
-Fetch-Direktiven können das Laden von Ressourcen basierend auf dem Standort der Ressource kontrollieren.
+Fetch-Direktiven können das Laden von Ressourcen basierend darauf steuern, wo sich die Ressource befindet.
 
-Das Schlüsselwort `'self'` erlaubt Ressourcen, die dieselbe Herkunft wie das Dokument selbst haben:
+Das Schlüsselwort `'self'` erlaubt Ressourcen, die gleichgeordnet mit dem Dokument selbst sind:
 
 ```http
 Content-Security-Policy: img-src 'self'
 ```
 
-Sie können auch ein oder mehrere Hostnamen angeben, möglicherweise einschließlich Platzhaltern, und nur Ressourcen, die von diesen Hosts bereitgestellt werden, sind erlaubt. Dies könnte beispielsweise verwendet werden, um Inhalt zu erlauben, der von einem vertrauenswürdigen CDN bereitgestellt wird.
+Sie können auch einen oder mehrere Hostnamen angeben, möglicherweise einschließlich Platzhaltern, und nur Ressourcen, die von diesen Hosts bereitgestellt werden, sind erlaubt. Dies könnte verwendet werden, um Inhalte von einem vertrauenswürdigen CDN zuzulassen.
 
 ```http
 Content-Security-Policy: img-src *.example.org
 ```
 
-Sie können mehrere Standorte angeben. Die folgende Direktive erlaubt nur Bilder, die dieselbe Herkunft wie das aktuelle Dokument haben, oder auf einem Subdomain von "example.org" gehostet werden, oder von "example.com" bereitgestellt werden:
+Sie können mehrere Standorte angeben. Die folgende Direktive erlaubt nur Bilder, die gleichgeordnet mit dem aktuellen Dokument sind oder von einer Subdomain von "example.org" oder von "example.com" bereitgestellt werden:
 
 ```http
 Content-Security-Policy: img-src 'self' *.example.org  example.com
@@ -274,9 +274,9 @@ Content-Security-Policy: img-src 'self' *.example.org  example.com
 
 #### Inline-JavaScript
 
-Wenn eine CSP entweder eine `default-src`- oder eine `script-src`-Direktive enthält, dann dürfen Inline-JavaScripts nicht ausgeführt werden, es sei denn, es werden zusätzliche Maßnahmen ergriffen, um es zu erlauben. Dies schließt ein:
+Wenn eine CSP entweder eine `default-src` oder eine `script-src` Direktive enthält, wird das Ausführen von inline JavaScript nicht erlaubt sein, es sei denn, es werden zusätzliche Maßnahmen ergriffen, um es zu ermöglichen. Dies schließt ein:
 
-- JavaScript, das innerhalb eines `<script>`-Elements im Dokument enthalten ist:
+- JavaScript, das innerhalb eines `<script>` Elements auf der Seite enthalten ist:
 
   ```html
   <script>
@@ -284,34 +284,34 @@ Wenn eine CSP entweder eine `default-src`- oder eine `script-src`-Direktive enth
   </script>
   ```
 
-- JavaScript in einem Inline-Ereignis-Handler-Attribut:
+- JavaScript in einem Inline-Event-Handler-Attribut:
 
   ```html
   <img src="x" onerror="console.log('Hello from an inline event handler')" />
   ```
 
-- JavaScript in einer `javascript:`-URL:
+- JavaScript in einer `javascript:` URL:
 
   ```html
   <a href="javascript:console.log('Hello from a javascript: URL')"></a>
   ```
 
-Das Schlüsselwort `unsafe-inline` kann verwendet werden, um diese Einschränkung aufzuheben. Zum Beispiel erlaubt die folgende Direktive alle Ressourcen aus derselben Herkunft, erlaubt aber auch Inline-JavaScript:
+Das Schlüsselwort `unsafe-inline` kann verwendet werden, um diese Einschränkung aufzuheben. Zum Beispiel erlaubt die folgende Direktive, dass alle Ressourcen gleichgeordnet sein müssen, erlaubt jedoch inline JavaScript:
 
 ```http example-bad
 Content-Security-Policy: default-src 'self' 'unsafe-inline'
 ```
 
 > [!WARNING]
-> Entwickler sollten `'unsafe-inline'` vermeiden, da es den größten Teil des Zwecks einer CSP untergräbt. Inline-JavaScript ist einer der häufigsten XSS-Vektoren und eines der grundlegendsten Ziele einer CSP ist es, seine unkontrollierte Nutzung zu verhindern.
+> Entwickler sollten `'unsafe-inline'` vermeiden, da es den Zweck einer CSP weitgehend zunichte macht. Inline-JavaScript ist eines der häufigsten XSS-Vektoren, und eines der grundlegendsten Ziele einer CSP ist es, dessen unkontrollierte Verwendung zu verhindern.
 
-Inline-`<script>`-Elemente sind erlaubt, wenn sie durch ein Nonce oder einen Hash geschützt sind, wie oben beschrieben.
+Inline-`<script>` Elemente sind erlaubt, wenn sie durch ein Nonce oder einen Hash geschützt sind, wie oben beschrieben.
 
-Wenn eine Direktive Nonce- oder Hash-Ausdrücke enthält, wird das Schlüsselwort `unsafe-inline` von Browsern ignoriert.
+Wenn eine Direktive Nonce- oder Hash-Ausdrücke enthält, wird das `unsafe-inline` Schlüsselwort von Browsern ignoriert.
 
 #### `eval()` und ähnliche APIs
 
-Wenn eine CSP entweder eine `default-src`- oder eine `script-src`-Direktive enthält, dann dürfen `eval()` und ähnliche APIs nicht ausgeführt werden. Dies schließt ein, unter anderem:
+Wie inline JavaScript wird, wenn eine CSP entweder eine `default-src` oder eine `script-src` Direktive enthält, `eval()` und ähnliche APIs nicht erlaubt sein, auszuführen. Dies umfasst neben anderen APIs:
 
 - [`eval()`](/de/docs/Web/JavaScript/Reference/Global_Objects/eval) selbst:
 
@@ -319,30 +319,30 @@ Wenn eine CSP entweder eine `default-src`- oder eine `script-src`-Direktive enth
   eval('console.log("hello from eval()")');
   ```
 
-- Den {{jsxref("Function/Function()", "Function()")}}-Konstruktor:
+- Den {{jsxref("Function/Function()", "Funktion()")}}-Konstruktor:
 
   ```js
   const sum = new Function("a", "b", "return a + b");
   ```
 
-- Das Zeichenfolgenargument für [`setTimeout()`](/de/docs/Web/API/Window/setTimeout) und [`setInterval()`](/de/docs/Web/API/Window/setInterval):
+- Das Zeichenfolgen-Argument für [`setTimeout()`](/de/docs/Web/API/Window/setTimeout) und [`setInterval()`](/de/docs/Web/API/Window/setInterval):
 
   ```js
   setTimeout("console.log('hello from setTimeout')", 1);
   ```
 
-Das Schlüsselwort `unsafe-eval` kann verwendet werden, um dieses Verhalten zu überschreiben, und aus den gleichen Gründen wie bei `unsafe-inline`: **Entwickler sollten `unsafe-eval` vermeiden**. Manchmal kann es schwierig sein, die Verwendung von `eval()` zu entfernen: In diesen Situationen kann die [Trusted Types API](/de/docs/Web/API/Trusted_Types_API) es sicherer machen, indem sie sicherstellt, dass die Eingabe einer definierten Richtlinie entspricht.
+Das Schlüsselwort `unsafe-eval` kann verwendet werden, um dieses Verhalten zu überschreiben, und wie bei `unsafe-inline` und aus den gleichen Gründen: **Entwickler sollten `unsafe-eval` vermeiden**. Manchmal kann es schwierig sein, die Verwendung von `eval()` zu entfernen: In diesen Situationen kann die [Trusted Types API](/de/docs/Web/API/Trusted_Types_API) es sicherer machen, indem sichergestellt wird, dass die Eingabe einer definierten Richtlinie entspricht.
 
-Anders als `unsafe-inline` funktioniert das Schlüsselwort `unsafe-eval` weiterhin in einer Direktive, die Nonce- oder Hash-Ausdrücke enthält.
+Im Gegensatz zu `unsafe-inline` funktioniert das Schlüsselwort `unsafe-eval` dennoch in einer Direktive, die Nonce- oder Hash-Ausdrücke enthält.
 
 ### Strikte CSP
 
-Um das Laden von Skripten als Schutzmaßnahme gegen XSS zu kontrollieren, wird empfohlen, [nonce-](#nonces) oder [hash-](#hashes) basierte Fetch-Direktiven zu verwenden. Dies wird als _strikte CSP_ bezeichnet. Diese Art von CSP hat zwei Hauptvorteile gegenüber einer standortbasierten CSP (üblicherweise als _Erlaubnisliste CSP_ bezeichnet):
+Um das Laden von Skripten als Schutzmaßnahme gegen XSS zu kontrollieren, wird die Verwendung von Nonce- oder Hash-basierten Fetch-Direktiven empfohlen. Dies wird als _strikte CSP_ bezeichnet. Diese Art von CSP hat zwei Hauptvorteile gegenüber einer standortbasierten CSP (normalerweise als _Whitelisting-CSP_ bezeichnet):
 
-- Erlaubnislisten-CSPs sind schwer richtig zu implementieren und oft erlauben Richtlinien versehentlich unsichere Domains, und bieten daher keinen wirksamen Schutz gegen XSS (siehe [CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy](https://dl.acm.org/doi/pdf/10.1145/2976749.2978363)).
-- Erlaubnislisten-CSPs können sehr umfangreich und schwer zu warten sein, insbesondere wenn Skripte verwendet werden, die außerhalb Ihrer Kontrolle liegen. Laut [How I learned to stop worrying and love the Content Security Policy](https://www.netlify.com/blog/general-availability-content-security-policy-csp-nonce-integration/), um Google Analytics zu integrieren, wird einem Entwickler empfohlen, 187 Google-Domains zur Erlaubnisliste hinzuzufügen.
+- Whitelisting-CSPs sind schwer richtig zu implementieren und oft schließt die Richtlinie versehentlich unsichere Domains ein und bietet daher keinen effektiven Schutz gegen XSS (siehe [CSP ist tot, lang lebe CSP! Über die Unsicherheit von Whitelists und die Zukunft der Content Security Policy](https://dl.acm.org/doi/pdf/10.1145/2976749.2978363)).
+- Whitelisting-CSPs können sehr groß und schwer zu pflegen sein, insbesondere wenn Skripte verwendet werden, die nicht unter Ihrer Kontrolle stehen. Laut [How I learned to stop worrying and love the Content Security Policy](https://www.netlify.com/blog/general-availability-content-security-policy-csp-nonce-integration/) wird ein Entwickler nur zur Integration von Google Analytics aufgefordert, 187 Google-Domains auf die Whitelist zu setzen.
 
-Eine Nonce-basierte strikte CSP sieht so aus:
+Eine nonce-basierte strikte CSP sieht so aus:
 
 ```http
 Content-Security-Policy:
@@ -351,13 +351,13 @@ Content-Security-Policy:
   base-uri 'none';
 ```
 
-In diesem CSP haben wir:
+In dieser CSP:
 
-- Nonces verwendet, um zu kontrollieren, welche JavaScript-Ressourcen geladen werden dürfen
-- alle Objekteingaben blockiert
-- alle Verwendungen des `<base>`-Elements zur Festlegung einer Basis-URI blockiert.
+- verwenden wir Nonces, um zu kontrollieren, welche JavaScript-Ressourcen geladen werden dürfen
+- blockieren wir alle Objekteinbettungen
+- blockieren wir alle Verwendungen des `<base>` Elements, um eine Basis-URI festzulegen.
 
-Eine Hash-basierte strikte CSP ist identisch, außer dass sie Hashes anstelle von Nonces verwendet:
+Eine Hash-basierte strikte CSP ist die gleiche, außer dass sie Hashes anstelle von Nonces verwendet:
 
 ```http
 Content-Security-Policy:
@@ -366,15 +366,15 @@ Content-Security-Policy:
   base-uri 'none';
 ```
 
-Nonce-basierte Direktiven sind einfacher zu warten, wenn Sie in der Lage sind, Antworten, einschließlich des Inhalts selbst, dynamisch zu generieren. Ansonsten müssen Sie Hash-basierte Direktiven verwenden. Das Problem mit Hash-basierten Direktiven ist, dass Sie den Hash neu berechnen und anwenden müssen, wenn Änderungen am Skriptinhalt vorgenommen werden.
+Nonce-basierte Direktiven sind einfacher zu pflegen, wenn Sie Antworten dynamisch generieren können, einschließlich des Inhalts selbst. Andernfalls müssen Sie hash-basierte Direktiven verwenden. Das Problem mit hash-basierten Direktiven ist, dass Sie den Hash neu berechnen und erneut anwenden müssen, wenn eine Änderung an den Skriptinhalten vorgenommen wird.
 
 #### Das `strict-dynamic` Schlüsselwort
 
-Wie oben präsentiert, ist die strikte CSP schwierig zu implementieren, wenn Sie Skripte verwenden, die nicht unter Ihrer Kontrolle stehen. Wenn ein Drittanbieter-Skript zusätzliche Skripte lädt oder Inline-Skripte verwendet, dann schlägt dies fehl, da das Drittanbieter-Skript den Nonce oder Hash nicht weitergibt.
+Wie oben gezeigt, ist es schwierig, die strikte CSP zu implementieren, wenn Sie Skripte verwenden, die nicht unter Ihrer Kontrolle stehen. Wenn ein Drittanbieter-Skript zusätzliche Skripte lädt oder Inline-Skripte verwendet, schlägt dies fehl, da das Drittanbieter-Skript das Nonce oder den Hash nicht durchgibt.
 
-Das `strict-dynamic`-Schlüsselwort wird bereitgestellt, um bei diesem Problem zu helfen. Es ist ein Schlüsselwort, das in einer Fetch-Direktive enthalten sein kann und die Wirkung hat, dass wenn ein Skript einen Nonce oder einen Hash angehängt hat, dann wird diesem Skript erlaubt, weitere Skripte zu laden, die selbst keinen Nonce oder Hash haben. Das heißt, das Vertrauen, das in ein Skript durch einen Nonce oder Hash gesetzt wird, wird an Skripte weitergegeben, die das ursprüngliche Skript lädt (und Skripte, die _sie_ laden, und so weiter).
+Das `strict-dynamic` Schlüsselwort wird bereitgestellt, um bei diesem Problem zu helfen. Es ist ein Schlüsselwort, das in eine Fetch-Direktive aufgenommen werden kann, und es hat die Wirkung, dass, wenn ein Skript ein Nonce oder einen Hash enthält, dann dieses Skript weitere Skripte laden darf, die selbst keine Nonces oder Hashes haben. Das heißt, das Vertrauen in ein Skript durch ein Nonce oder einen Hash wird an die von dem ursprünglichen Skript geladenen Skripte weitergegeben (und an die, die _sie_ laden, und so weiter).
 
-Zum Beispiel, betrachten Sie ein Dokument wie dieses:
+Zum Beispiel betrachten Sie ein Dokument wie dieses:
 
 ```html
 <html>
@@ -389,7 +389,7 @@ Zum Beispiel, betrachten Sie ein Dokument wie dieses:
 </html>
 ```
 
-Es enthält ein Skript "main.js", das ein anderes Skript "main2.js" erstellt und hinzufügt:
+Es enthält ein Skript "main.js", das ein weiteres Skript "main2.js" erstellt und hinzufügt:
 
 ```js
 console.log("hello");
@@ -400,16 +400,16 @@ scriptElement.src = `main2.js`;
 document.head.appendChild(scriptElement);
 ```
 
-Wir liefern unser Dokument mit einem CSP wie diesem:
+Wir liefern unser Dokument mit einer CSP wie dieser:
 
 ```http
 Content-Security-Policy:
   script-src 'sha256-gEh1+8U9S1vkEuQSmmUMTZjyNSu5tIoECP4UXIEjMTk='
 ```
 
-Das "main.js"-Skript wird zugelassen, weil sein Hash mit dem Wert in der CSP übereinstimmt. Aber sein Versuch, "main2.js" zu laden, schlägt fehl.
+Das "main.js" Skript wird geladen, da sein Hash mit dem Wert in der CSP übereinstimmt. Aber der Versuch, "main2.js" zu laden, schlägt fehl.
 
-Wenn wir `'strict-dynamic'` zur CSP hinzufügen, dann darf "main.js" "main2.js" laden:
+Wenn wir `'strict-dynamic'` zur CSP hinzufügen, darf "main.js" "main2.js" laden:
 
 ```http
 Content-Security-Policy:
@@ -417,11 +417,11 @@ Content-Security-Policy:
   strict-dynamic
 ```
 
-Das `'strict-dynamic'`-Schlüsselwort macht es wesentlich einfacher, Nonce- oder Hash-basierte CSPs zu erstellen und zu pflegen, insbesondere wenn eine Website Drittanbieter-Skripte verwendet. Dies macht Ihre CSP jedoch weniger sicher, da, wenn die Skripte, die Sie einbeziehen, `<script>`-Elemente basierend auf potenziellen XSS-Quellen erstellen, die CSP diese nicht schützt.
+Das `'strict-dynamic'` Schlüsselwort macht es viel einfacher, Nonce- oder Hash-basierte CSPs zu erstellen und zu pflegen, insbesondere wenn eine Website Drittanbieter-Skripte verwendet. Es macht Ihre CSP jedoch weniger sicher, da die CSP sie nicht schützen wird, wenn die Skripte, die Sie einfügen, `<script>` Elemente basierend auf potenziellen XSS-Quellen erstellen.
 
 #### Refactoring von Inline-JavaScript und `eval()`
 
-Wir haben oben gesehen, dass Inline-JavaScript standardmäßig in einer CSP nicht zugelassen ist. Mit Nonces oder Hashes kann ein Entwickler Inline-`<script>`-Tags verwenden, aber dennoch müssen Sie den Code umgestalten, um andere unzulässige Muster zu entfernen, wie zum Beispiel Inline-Ereignis-Handler, `javascript:`-URLs und die Verwendung von `eval()`. Zum Beispiel sollten Inline-Ereignis-Handler in der Regel durch Aufrufe von [`addEventListener()`](/de/docs/Web/API/EventTarget/addEventListener) ersetzt werden:
+Wie wir oben gesehen haben, ist Inline-JavaScript standardmäßig in einer CSP nicht erlaubt. Mit Nonces oder Hashes kann ein Entwickler Inline-`<script>` Tags verwenden, aber Sie müssen den Code dennoch refaktorisieren, um andere nicht erlaubte Muster zu entfernen, einschließlich Inline-Event-Handler, `javascript:` URLs und Verwendungen von `eval()`. Zum Beispiel sollten Inline-Event-Handler normalerweise durch Aufrufe von [`addEventListener()`](/de/docs/Web/API/EventTarget/addEventListener) ersetzt werden:
 
 ```html example-bad
 <p onclick="console.log('Hello from an inline event handler')">click me</p>
@@ -442,69 +442,69 @@ Wir haben oben gesehen, dass Inline-JavaScript standardmäßig in einer CSP nich
 
 ## Clickjacking-Schutz
 
-Die [`frame-ancestors`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors)-Direktive kann verwendet werden, um zu steuern, welche Dokumente, falls überhaupt, dieses Dokument in einem verschachtelten Browsing-Kontext wie einem {{htmlelement("iframe")}} einbetten dürfen. Dies ist ein wirksamer Schutz gegen Clickjacking-Angriffe, da diese Angriffe davon abhängen, die Zielseite in einer vom Angreifer kontrollierten Website einzubetten.
+Die [`frame-ancestors`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) Direktive kann verwendet werden, um zu kontrollieren, welche Dokumente, wenn überhaupt, dieses Dokument in einem eingebetteten Browsing-Kontext wie einem {{htmlelement("iframe")}} einbetten dürfen. Dies ist ein effektiver Schutz gegen Clickjacking-Angriffe, da diese Angriffe darauf angewiesen sind, das Ziel in einer vom Angreifer kontrollierten Seite einzubetten.
 
-Die Syntax von `frame-ancestors` ist ein Subset der Fetch-Direktiv-Syntax: Sie können den einzelnen Schlüsselwortwert `'none'` oder einen oder mehrere Quell-Ausdrücke angeben. Allerdings können die einzigen Quell-Ausdrücke, die Sie verwenden können, Schemas, Hostnamen oder das Schlüsselwort `'self'` sein.
+Die Syntax von `frame-ancestors` ist ein Subset der Fetch-Direktiven-Syntax: Sie können entweder das einzelne Schlüsselwort `'none'` oder einen oder mehrere Quellausdrücke angeben. Die einzigen Quellausdrücke, die Sie verwenden können, sind jedoch Schemas, Hostnamen oder das `'self'` Schlüsselwort.
 
-Wenn Ihre Seite nicht eingebettet werden muss, sollten Sie `frame-ancestors` auf `'none'` setzen:
+Es sei denn, Sie benötigen Ihre Website, um eingebettet zu werden, sollten Sie `frame-ancestors` auf `'none'` setzen:
 
 ```http
 Content-Security-Policy: frame-ancestors 'none'
 ```
 
-Diese Direktive ist ein flexiblerer Ersatz für den {{httpheader("X-Frame-Options")}}-Header.
+Diese Direktive ist ein flexiblerer Ersatz für den {{httpheader("X-Frame-Options")}} Header.
 
 ## Upgrade unsicherer Anfragen
 
-Webentwickler werden dringend dazu ermutigt, alle ihre Inhalte über HTTPS bereitzustellen. Im Prozess der Umstellung einer Website auf HTTPS dient eine Seite manchmal das Hauptdokument über HTTPS aus, während ihre Ressourcen über HTTP bereitgestellt werden, indem sie beispielsweise Markup wie dieses verwenden:
+Webentwickler werden dringend ermutigt, allen Inhalt über HTTPS zu bedienen. Im Prozess der Umstellung einer Website auf HTTPS kommt es manchmal vor, dass die Hauptdokumente über HTTPS bedient werden, aber ihre Ressourcen über HTTP, indem zum Beispiel Markup wie dieses verwendet wird:
 
 ```html
 <script src="http://example.org/my-cat.js"></script>
 ```
 
-Dies wird als _Mixed Content_ bezeichnet und das Vorhandensein unsicherer Ressourcen schwächt den durch HTTPS gewährten Schutz erheblich. Nach dem von Browsern implementierten [Mixed Content-Algorithmus](/de/docs/Web/Security/Mixed_content) wird unsicherer Inhalt, wenn ein Dokument über HTTPS bereitgestellt wird, in "upgradable content" und "blockable content" kategorisiert. Upgradable content wird auf HTTPS aufgerüstet, und blockable content wird blockiert, was möglicherweise die Seite funktionsunfähig macht.
+Das wird als _gemischter Inhalt_ bezeichnet, und das Vorhandensein unsicherer Ressourcen schwächt den Schutz, den HTTPS bietet, erheblich. Unter dem [Algorithmus für gemischten Inhalt](/de/docs/Web/Security/Mixed_content), den Browser implementieren, werden gewährleistet, dass unsichere Ressourcen auf "upgradable content" und "blockable content" aufgeteilt werden. Upgradable Content wird zu HTTPS hochgestuft, während blockbarer Content blockiert wird, was die Seite möglicherweise zerstört.
 
-Die ultimative Lösung für Mixed Content ist, dass Entwickler alle Ressourcen über HTTPS laden. Aber selbst wenn eine Seite in der Lage ist, alle Inhalte über HTTPS bereitzustellen, kann es für einen Entwickler immer noch sehr schwierig sein (oder sogar effektiv unmöglich, wenn es um archivierte Inhalte geht), alle von der Seite verwendeten URLs zum Laden von Ressourcen umzuschreiben.
+Die ultimative Lösung für gemischte Inhalte besteht darin, dass Entwickler alle Ressourcen über HTTPS laden. Selbst wenn eine Site tatsächlich in der Lage ist, allen Content über HTTPS zu bedienen, kann es jedoch sehr schwierig (oder sogar praktisch unmöglich) sein, wo archivierter Content betroffen ist, dass ein Entwickler alle URLs der Site umschreibt, die Ressourcen laden.
 
-Die [`upgrade-insecure-requests`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests)-Direktive soll dieses Problem lösen. Diese Direktive hat keinen Wert: Um sie zu setzen, geben Sie einfach den Direktivennamen ein:
+Die [`upgrade-insecure-requests`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests) Direktive soll dieses Problem lösen. Diese Direktive hat keinen Wert: Um sie einzustellen, fügen Sie einfach den Direktivnamen hinzu:
 
 ```http
 Content-Security-Policy: upgrade-insecure-requests
 ```
 
-Wenn diese Direktive für ein Dokument gesetzt ist, wird der Browser automatisch alle HTTP-URLs in folgenden Fällen auf HTTPS upgraden:
+Wenn diese Direktive in einem Dokument gesetzt ist, wird der Browser automatisch alle HTTP-URLs in den folgenden Fällen zu HTTPS upgraden:
 
-- Anfragen, um Ressourcen zu laden (wie Bilder, Skripte oder Schriftarten)
-- Navigationsanforderungen (wie Linkziele), die dieselbe Herkunft wie das Dokument haben
-- Navigationsanforderungen in verschachtelten Browsing-Kontexten wie iframes
-- Formulareinsendungen
+- Anfragen, um Ressourcen zu laden (z.B. Bilder, Skripte oder Schriftarten)
+- Navigationsanfragen (wie Link-Ziele), die gleichgeordnet mit dem Dokument sind
+- Navigationsanfragen in eingebetteten Browsing-Kontexten, wie Iframes
+- Formularübertragungen
 
-Allerdings werden Top-Level-Navigationsanforderungen, deren Ziel eine andere Herkunft ist, nicht aufgerüstet.
+Navigationsanfragen auf Top-Ebene, deren Ziel ein anderer Ursprung ist, werden jedoch nicht hochgestuft.
 
-Angenommen, das Dokument unter `https://example.org` wird mit einer CSP geliefert, die die `upgrade-insecure-requests`-Direktive enthält, und das Dokument enthält ein Markup wie dieses:
+Angenommen, das Dokument unter `https://example.org` wird mit einer CSP serviert, die die `upgrade-insecure-requests` Direktive enthält, und das Dokument enthält Markup wie dieses:
 
 ```html
 <script src="http://example.org/my-cat.js"></script>
 <script src="http://not-example.org/another-cat.js"></script>
 ```
 
-Der Browser wird beide Anfragen automatisch auf HTTPS upgraden.
+Der Browser wird beide Anforderungen automatisch zu HTTPS hochstufen.
 
-Angenommen, das Dokument enthält auch Folgendes:
+Angenommen, das Dokument enthält auch dies:
 
 ```html
 <a href="http://example.org/more-cats">See some more cats!</a>
 <a href="http://not-example.org/even-more-cats">More cats, on another site!</a>
 ```
 
-Der Browser wird den ersten Link auf HTTPS upgraden, aber nicht den zweiten, da er sich zu einer anderen Herkunft bewegt.
+Der Browser wird den ersten Link zu HTTPS upgraden, aber nicht den zweiten, da er zu einem anderen Ursprung navigiert.
 
-Diese Direktive ist kein Ersatz für den {{httpheader("Strict-Transport-Security")}}-Header (auch bekannt als HSTS), da sie keine externen Links zu einer Site aufrüstet. Seiten sollten diese Direktive sowie den `Strict-Transport-Security`-Header einbeziehen.
+Diese Direktive ist kein Ersatz für den {{httpheader("Strict-Transport-Security")}} Header (auch bekannt als HSTS), weil sie keine externen Links zu einer Site hochstufen wird. Sites sollten diese Direktive und den `Strict-Transport-Security` Header einfügen.
 
 ## Testen Ihrer Richtlinie
 
-Um die Bereitstellung zu erleichtern, kann CSP im "report-only"-Modus bereitgestellt werden.
-Die Richtlinie wird nicht durchgesetzt, aber alle Verstöße werden an den in der Richtlinie angegebenen Reporting-Endpunkt gesendet. Zusätzlich kann ein report-only-Header verwendet werden, um eine zukünftige Überarbeitung einer Richtlinie zu testen, ohne sie tatsächlich bereitzustellen.
+Um die Bereitstellung zu erleichtern, kann CSP im Bericht-Only-Modus bereitgestellt werden.
+Die Richtlinie wird nicht erzwungen, aber alle Verstöße werden an den in der Richtlinie angegebenen Berichts-Endpunkt gesendet. Zusätzlich kann ein Bericht-Only-Header verwendet werden, um eine zukünftige Revision einer Richtlinie zu testen, ohne sie tatsächlich auszuliefern.
 
 Sie können den {{HTTPHeader("Content-Security-Policy-Report-Only")}} HTTP-Header verwenden, um Ihre Richtlinie anzugeben, wie folgt:
 
@@ -512,48 +512,48 @@ Sie können den {{HTTPHeader("Content-Security-Policy-Report-Only")}} HTTP-Heade
 Content-Security-Policy-Report-Only: policy
 ```
 
-Wenn sowohl ein {{HTTPHeader("Content-Security-Policy-Report-Only")}}-Header als auch ein {{HTTPHeader("Content-Security-Policy")}}-Header in derselben Antwort vorhanden sind, werden beide Richtlinien beachtet.
-Die Richtlinie, die in den `Content-Security-Policy`-Headern angegeben ist, wird durchgesetzt, während die `Content-Security-Policy-Report-Only`-Richtlinie Berichte generiert, aber nicht durchgesetzt wird.
+Wenn sowohl ein {{HTTPHeader("Content-Security-Policy-Report-Only")}} Header als auch ein {{HTTPHeader("Content-Security-Policy")}} Header in derselben Antwort vorhanden sind, werden beide Richtlinien berücksichtigt.
+Die in den `Content-Security-Policy` Headern angegebene Richtlinie wird durchgesetzt, während die `Content-Security-Policy-Report-Only` Richtlinie Berichte generiert, aber nicht durchgesetzt wird.
 
-Beachten Sie, dass eine report-only-Richtlinie im Gegensatz zu einer normalen Content Security Policy nicht in einem `<meta>`-Element geliefert werden kann.
+Beachten Sie, dass im Gegensatz zu einer normalen Content-Security-Policy eine Report-Only-Richtlinie nicht in einem `<meta>` Element bereitgestellt werden kann.
 
-### Verstoßberichterstattung
+### Fehlerberichterstattung
 
-Die empfohlene Methode zur Berichterstattung von CSP-Verstößen ist die Verwendung der [Reporting API](/de/docs/Web/API/Reporting_API), wobei Endpunkte in {{HTTPHeader("Reporting-Endpoints")}} deklariert und einer dieser Punkte als CSP-Berichtsziele verwendet wird, mittels der {{CSP("report-to")}}-Direktive des `Content-Security-Policy`-Headers.
+Die empfohlene Methode, um CSP-Verstöße zu berichten, besteht darin, die [Berichts-API](/de/docs/Web/API/Reporting_API) zu verwenden, indem Endpunkte in {{HTTPHeader("Reporting-Endpoints")}} angegeben werden und einer davon als CSP-Berichts-Ziel mit der `Content-Security-Policy` Kopfzeile {{CSP("report-to")}} Direktive spezifiziert wird.
 
 > [!WARNING]
-> Sie können auch die CSP-{{CSP("report-uri")}}-Direktive verwenden, um eine Ziel-URL für CSP-Verstoßberichte anzugeben.
+> Sie können auch die CSP {{CSP("report-uri")}} Direktive verwenden, um eine Ziel-URL für CSP-Verletzungsberichte anzugeben.
 > Dies sendet ein etwas anderes JSON-Berichtsformat über eine `POST`-Operation mit einem {{HTTPHeader("Content-Type")}} von `application/csp-report`.
-> Dieser Ansatz wird als veraltet angesehen, aber Sie sollten beide verwenden, bis {{CSP("report-to")}} in allen Browsern unterstützt wird.
-> Für weitere Informationen über den Ansatz siehe das Thema {{CSP("report-uri")}}.
+> Dieser Ansatz ist veraltet, aber Sie sollten beide deklarieren, bis {{CSP("report-to")}} in allen Browsern unterstützt wird.
+> Weitere Informationen zu diesem Ansatz finden Sie im {{CSP("report-uri")}} Thema.
 
-Ein Server kann die Clients darüber informieren, wo Berichte gesendet werden sollen, indem er den {{HTTPHeader("Reporting-Endpoints")}} HTTP-Antwort-Header verwendet.
-Dieser Header definiert eine oder mehrere Endpunkt-URLs als kommaseparierte Liste.
-Zum Beispiel kann die Antwort des Servers folgendermaßen aussehen, um einen Reporting-Endpunkt namens `csp-endpoint` zu definieren, der Berichte an `https://example.com/csp-reports` akzeptiert:
+Ein Server kann Clients informieren, wohin Berichte gesendet werden sollen, indem er den {{HTTPHeader("Reporting-Endpoints")}} HTTP-Antwortheader verwendet.
+Dieser Header definiert eine oder mehrere Endpunkt-URLs als Komma-separierte Liste.
+Zum Beispiel, um einen Berichts-Endpunkt namens `csp-endpoint` zu definieren, der Berichte unter `https://example.com/csp-reports` akzeptiert, könnte der Antwortheader des Servers folgendermaßen aussehen:
 
 ```http
 Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
 ```
 
-Wenn Sie mehrere Endpunkte haben möchten, die unterschiedliche Arten von Berichten bearbeiten, würden Sie sie wie folgt angeben:
+Wenn Sie mehrere Endpunkte haben möchten, die unterschiedliche Arten von Berichten verarbeiten, würden Sie sie wie folgt spezifizieren:
 
 ```http
 Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports",
                      hpkp-endpoint="https://example.com/hpkp-reports"
 ```
 
-Sie können dann die {{CSP("report-to")}}-Direktive des `Content-Security-Policy`-Headers verwenden, um anzugeben, dass ein bestimmter definierter Endpunkt für die Berichterstattung verwendet werden soll.
-Zum Beispiel, um CSP-Verstoßberichte an `https://example.com/csp-reports` für den `default-src` zu senden, könnten Sie Antwort-Header verwenden, die folgendermaßen aussehen:
+Sie können dann die `Content-Security-Policy` Kopfzeile {{CSP("report-to")}} Direktive verwenden, um anzugeben, dass ein bestimmter definierter Endpunkt für die Berichterstattung verwendet werden soll.
+Zum Beispiel, um CSP-Verletzungsberichte an `https://example.com/csp-reports` für `default-src` zu senden, könnten Sie Antwortheader senden, die wie folgt aussehen:
 
 ```http
 Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
 Content-Security-Policy: default-src 'self'; report-to csp-endpoint
 ```
 
-Wenn ein CSP-Verstoß auftritt, sendet der Browser den Bericht als JSON-Objekt an den angegebenen Endpunkt über eine HTTP-`POST`-Operation, mit einem {{HTTPHeader("Content-Type")}} von `application/reports+json`.
-Der Bericht ist eine serialisierte Form des [`Report`](/de/docs/Web/API/Report)-Objekts, das eine `type`-Eigenschaft mit einem Wert von `"csp-violation"` und einen `body`, der die serialisierte Form eines [`CSPViolationReportBody`](/de/docs/Web/API/CSPViolationReportBody)-Objekts ist, enthält.
+Wenn eine CSP-Verletzung auftritt, sendet der Browser den Bericht als JSON-Objekt an den angegebenen Endpunkt über eine HTTP `POST`-Operation, mit einem {{HTTPHeader("Content-Type")}} von `application/reports+json`.
+Der Bericht ist eine serialisierte Form des [`Report`](/de/docs/Web/API/Report) Objekts, das eine `type` Eigenschaft mit einem Wert von `"csp-violation"` enthält, und einen `body`, der die serialisierte Form eines [`CSPViolationReportBody`](/de/docs/Web/API/CSPViolationReportBody) Objekts ist.
 
-Ein typisches Objekt könnte folgendermaßen aussehen:
+Ein typisches Objekt könnte so aussehen:
 
 ```json
 {
@@ -577,12 +577,12 @@ Ein typisches Objekt könnte folgendermaßen aussehen:
 }
 ```
 
-Sie müssen einen Server einrichten, um Berichte mit dem angegebenen JSON-Format und Inhaltstyp zu empfangen.
-Der Server, der diese Anfragen behandelt, kann dann die eingehenden Berichte in einer Weise speichern oder verarbeiten, die am besten zu Ihren Anforderungen passt.
+Sie müssen einen Server einrichten, um Berichte im angegebenen JSON-Format und Inhalts-Typ zu empfangen.
+Der Server, der diese Anforderungen verarbeitet, kann dann die eingehenden Berichte in einer Weise speichern oder verarbeiten, die am besten zu Ihren Bedürfnissen passt.
 
 ## Siehe auch
 
-- [Mitigieren von Cross-Site Scripting mit einer strikten Content Security Policy](https://web.dev/articles/strict-csp) auf web.dev (2024)
-- [Content Security Policy: Ein erfolgreicher Mischmasch zwischen Härtung und Abschwächung](https://infocondb.org/con/locomocosec/locomocosec-2019/content-security-policy-a-successful-mess-between-hardening-and-mitigation)
+- [Mitigate cross-site scripting with a strict Content Security Policy](https://web.dev/articles/strict-csp) auf web.dev (2024)
+- [Content Security Policy: A successful mess between hardening and mitigation](https://infocondb.org/con/locomocosec/locomocosec-2019/content-security-policy-a-successful-mess-between-hardening-and-mitigation)
 - [Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) auf owasp.org
 - [CSP Evaluator](https://csp-evaluator.withgoogle.com/)
diff --git a/files/de/web/http/headers/x-frame-options/index.md b/files/de/web/http/headers/x-frame-options/index.md
index 9c3080c2d..b0fc7701a 100644
--- a/files/de/web/http/headers/x-frame-options/index.md
+++ b/files/de/web/http/headers/x-frame-options/index.md
@@ -2,17 +2,17 @@
 title: X-Frame-Options
 slug: Web/HTTP/Headers/X-Frame-Options
 l10n:
-  sourceCommit: ed041385cf874deec203e820fd415bdcd6f98a19
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{HTTPSidebar}}{{deprecated_header}}
 
 > [!WARNING]
-> Anstelle dieses Headers verwenden Sie die {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}} Anweisung in einem {{HTTPHeader("Content-Security-Policy")}} Header.
+> Anstatt dieses Headers verwenden Sie die {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}}-Direktive in einem {{HTTPHeader("Content-Security-Policy")}}-Header.
 
-Der HTTP **`X-Frame-Options`** {{Glossary("response_header", "Antwort-Header")}} kann verwendet werden, um anzugeben, ob ein Browser eine Seite in einem {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} oder {{HTMLElement("object")}} rendern darf. Websites können dies nutzen, um [Clickjacking](/de/docs/Web/Security/Types_of_attacks#click-jacking)-Angriffe zu vermeiden, indem sie sicherstellen, dass ihr Inhalt nicht in andere Websites eingebettet wird.
+Der HTTP **`X-Frame-Options`** {{Glossary("response_header", "Antwort-Header")}} kann verwendet werden, um anzugeben, ob ein Browser eine Seite in einem {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} oder {{HTMLElement("object")}} rendern darf. Websites können dies nutzen, um [Clickjacking](/de/docs/Web/Security/Types_of_attacks#clickjacking)-Angriffe zu vermeiden, indem sie sicherstellen, dass ihre Inhalte nicht in andere Seiten eingebettet werden.
 
-Die zusätzliche Sicherheit wird nur geboten, wenn der Benutzer, der auf das Dokument zugreift, einen Browser verwendet, der `X-Frame-Options` unterstützt.
+Die zusätzliche Sicherheit wird nur bereitgestellt, wenn der Benutzer, der auf das Dokument zugreift, einen Browser verwendet, der `X-Frame-Options` unterstützt.
 
 <table class="properties">
   <tbody>
@@ -29,32 +29,32 @@ Die zusätzliche Sicherheit wird nur geboten, wenn der Benutzer, der auf das Dok
 
 ## Syntax
 
-Es gibt zwei mögliche Anweisungen für `X-Frame-Options`:
+Es gibt zwei mögliche Direktiven für `X-Frame-Options`:
 
 ```http
 X-Frame-Options: DENY
 X-Frame-Options: SAMEORIGIN
 ```
 
-### Anweisungen
+### Direktiven
 
-Wenn Sie `DENY` angeben, wird nicht nur der Versuch, die Seite in einem Frame zu laden, scheitern, wenn sie von anderen Websites geladen wird, sondern auch Versuche, dies von derselben Website aus zu tun, werden fehlschlagen. Wenn Sie hingegen `SAMEORIGIN` angeben, können Sie die Seite in einem Frame verwenden, solange die Seite, die sie in einem Frame einbettet, dieselbe ist wie die, die die Seite selbst bereitstellt.
+Wenn Sie `DENY` angeben, wird der Versuch des Browsers, die Seite in einem Frame zu laden, nicht nur beim Laden von anderen Seiten fehlschlagen, sondern auch beim Laden von derselben Seite. Wenn Sie hingegen `SAMEORIGIN` angeben, können Sie die Seite weiterhin in einem Frame verwenden, solange die Seite, die sie in einem Frame einfügt, dieselbe ist wie diejenige, die die Seite bereitstellt.
 
 - `DENY`
-  - : Die Seite kann in keinem Frame angezeigt werden, unabhängig von der Website, die versucht, dies zu tun.
+  - : Die Seite kann in keinem Frame angezeigt werden, unabhängig von der Seite, die es versucht.
 - `SAMEORIGIN` {{deprecated_inline}}
-  - : Die Seite kann nur angezeigt werden, wenn alle Vorfahren-Frames denselben Ursprung haben wie die Seite selbst.
+  - : Die Seite kann nur angezeigt werden, wenn alle übergeordneten Frames denselben Ursprung wie die Seite selbst haben.
 - `ALLOW-FROM origin` {{deprecated_inline}}
-  - : Dies ist eine veraltete Anweisung. Moderne Browser, die Antwort-Header mit dieser Anweisung vorfinden, ignorieren den Header vollständig. Der {{HTTPHeader("Content-Security-Policy")}} HTTP-Header enthält eine {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}} Anweisung, die Sie stattdessen verwenden sollten.
+  - : Dies ist eine veraltete Direktive. Moderne Browser, die Antwort-Header mit dieser Direktive vorfinden, ignorieren den Header vollständig. Der {{HTTPHeader("Content-Security-Policy")}} HTTP-Header hat eine {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}}-Direktive, die Sie stattdessen verwenden sollten.
 
 ## Beispiele
 
 > [!WARNING]
-> Das Setzen von `X-Frame-Options` innerhalb des {{HTMLElement("meta")}} Elements (z. B. `<meta http-equiv="X-Frame-Options" content="deny">`) hat keine Wirkung. `X-Frame-Options` wird nur über HTTP-Header durchgesetzt, wie in den folgenden Beispielen gezeigt.
+> Das Setzen von `X-Frame-Options` innerhalb des {{HTMLElement("meta")}}-Elements (z.B. `<meta http-equiv="X-Frame-Options" content="deny">`) hat keine Wirkung. `X-Frame-Options` wird nur über HTTP-Header erzwungen, wie in den folgenden Beispielen gezeigt.
 
 ### Konfiguration von Apache
 
-Um Apache so zu konfigurieren, dass es den `X-Frame-Options` Header für alle Seiten sendet, fügen Sie dies zur Konfiguration Ihrer Website hinzu:
+Um Apache so zu konfigurieren, dass der `X-Frame-Options`-Header für alle Seiten gesendet wird, fügen Sie dies zur Konfiguration Ihrer Website hinzu:
 
 ```apacheconf
 Header always set X-Frame-Options "SAMEORIGIN"
@@ -68,13 +68,13 @@ Header set X-Frame-Options "DENY"
 
 ### Konfiguration von Nginx
 
-Um Nginx so zu konfigurieren, dass es den `X-Frame-Options` Header sendet, fügen Sie dies entweder Ihrer http-, Server- oder Standortkonfiguration hinzu:
+Um Nginx so zu konfigurieren, dass der `X-Frame-Options`-Header gesendet wird, fügen Sie dies entweder zu Ihrer http-, server- oder location-Konfiguration hinzu:
 
 ```nginx
 add_header X-Frame-Options SAMEORIGIN always;
 ```
 
-Sie können den `X-Frame-Options` Header auf `DENY` setzen, indem Sie:
+Sie können den `X-Frame-Options`-Header auf `DENY` setzen, indem Sie:
 
 ```nginx
 add_header X-Frame-Options DENY always;
@@ -82,7 +82,7 @@ add_header X-Frame-Options DENY always;
 
 ### Konfiguration von IIS
 
-Um IIS so zu konfigurieren, dass es den `X-Frame-Options` Header sendet, fügen Sie dies zur `Web.config` Datei Ihrer Website hinzu:
+Um IIS so zu konfigurieren, dass der `X-Frame-Options`-Header gesendet wird, fügen Sie dies zur Datei `Web.config` Ihrer Website hinzu:
 
 ```xml
 <system.webServer>
@@ -96,17 +96,17 @@ Um IIS so zu konfigurieren, dass es den `X-Frame-Options` Header sendet, fügen
 </system.webServer>
 ```
 
-Für weitere Informationen lesen Sie den [Microsoft Support Artikel zur Konfiguration mittels der Benutzeroberfläche des IIS Managers](https://support.microsoft.com/en-US/office/mitigating-framesniffing-with-the-x-frame-options-header-1911411b-b51e-49fd-9441-e8301dcdcd79).
+Für weitere Informationen lesen Sie den [Microsoft Support-Artikel zur Einstellung dieser Konfiguration mit der IIS Manager-Benutzeroberfläche](https://support.microsoft.com/en-US/office/mitigating-framesniffing-with-the-x-frame-options-header-1911411b-b51e-49fd-9441-e8301dcdcd79).
 
 ### Konfiguration von HAProxy
 
-Um HAProxy so zu konfigurieren, dass es den `X-Frame-Options` Header sendet, fügen Sie dies Ihrer Frontend-, Listen-, oder Back-End-Konfiguration hinzu:
+Um HAProxy so zu konfigurieren, dass der `X-Frame-Options`-Header gesendet wird, fügen Sie dies Ihrer Frontend-, Listener- oder Backend-Konfiguration hinzu:
 
 ```plain
 rspadd X-Frame-Options:\ SAMEORIGIN
 ```
 
-Alternativ in neueren Versionen:
+Alternativ, in neueren Versionen:
 
 ```plain
 http-response set-header X-Frame-Options SAMEORIGIN
@@ -114,7 +114,7 @@ http-response set-header X-Frame-Options SAMEORIGIN
 
 ### Konfiguration von Express
 
-Um `X-Frame-Options` auf `SAMEORIGIN` zu setzen, verwenden Sie [Helmet](https://helmetjs.github.io/) und fügen Sie folgendes zu Ihrer Serverkonfiguration hinzu:
+Um `X-Frame-Options` auf `SAMEORIGIN` zu setzen, verwenden Sie [Helmet](https://helmetjs.github.io/) und fügen Sie das Folgende zu Ihrer Server-Konfiguration hinzu:
 
 ```js
 const helmet = require("helmet");
@@ -136,6 +136,6 @@ app.use(
 
 ## Siehe auch
 
-- {{HTTPHeader("Content-Security-Policy")}} Anweisung {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}}
-- [ClickJacking-Abwehrmaßnahmen - IEBlog](https://learn.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-vii-clickjacking-defenses)
+- {{HTTPHeader("Content-Security-Policy")}}-Direktive {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}}
+- [ClickJacking-Abwehr - IEBlog](https://learn.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-vii-clickjacking-defenses)
 - [Bekämpfung von ClickJacking mit X-Frame-Options - IEInternals](https://learn.microsoft.com/en-us/archive/blogs/ieinternals/combating-clickjacking-with-x-frame-options)
diff --git a/files/de/web/security/attacks/clickjacking/index.md b/files/de/web/security/attacks/clickjacking/index.md
new file mode 100644
index 000000000..3c694a98d
--- /dev/null
+++ b/files/de/web/security/attacks/clickjacking/index.md
@@ -0,0 +1,72 @@
+---
+title: Clickjacking
+slug: Web/Security/Attacks/Clickjacking
+l10n:
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
+---
+
+Bei einem **Clickjacking**-Angriff wird der Benutzer dazu gebracht, mit einer Zielseite auf eine Weise zu interagieren, die er nicht beabsichtigt hat.
+
+Um dies zu erreichen, erstellt der Angreifer eine Lockvogel-Seite, die die Zielseite des Benutzers innerhalb eines {{htmlelement("iframe")}}-Elements einbettet. Die Seite des Angreifers verbirgt das `<iframe>` und richtet einige Lockvogel-Elemente so aus, dass sie an derselben Stelle erscheinen wie die Elemente auf der Zielseite, die sensible Aktionen auslösen. Wenn der Benutzer versucht, mit diesen Lockvogel-Elementen zu interagieren, interagiert er tatsächlich mit der Zielseite und kann dazu gebracht werden, dort Aktionen durchzuführen, die er nicht beabsichtigt hat.
+
+## Ein Clickjacking-Beispiel
+
+Nehmen wir an, die Website der Bank des Benutzers ist `https://my-bank.example.com`. Der Benutzer bleibt in der Regel auf dieser Seite angemeldet. Zur Vereinfachung sagen wir, dass die Seite über eine Schaltfläche verfügt, die alle Gelder des Benutzers an den Angreifer überträgt — obwohl dies offensichtlich unrealistisch ist, ist es plausibel, dass die Seite einige interaktive Elemente hat, die eine sensible Operation durchführen.
+
+![Screenshot einer Bank-Website mit einem Button "Transfer all my money?"](my-bank.png)
+
+Der Angreifer erstellt eine Webseite, die enthält:
+
+- ein {{htmlelement("button")}}-Element, dessen Inhalt den Benutzer ermutigt, darauf zu klicken
+- ein {{htmlelement("iframe")}}-Element, das die Bank-Seite einbettet.
+
+```html
+<button id="fake-button">Click here for a free kitten!</button>
+<iframe width="800" height="200" src="https://my-bank.example.com"></iframe>
+```
+
+Im CSS der Seite sorgt der Angreifer dafür, dass:
+
+- das `<iframe>` versteckt wird, zum Beispiel durch Setzen der {{cssxref("opacity")}} auf null
+- der Button so platziert wird, dass er an derselben Stelle wie der Button "Transfer all your money?" ist.
+
+```css
+iframe {
+  opacity: 0;
+}
+
+#fake-button {
+  position: absolute;
+  top: 185px;
+  left: 90px;
+}
+```
+
+Das Ergebnis sieht folgendermaßen aus (wir haben die `<iframe>`-Transparenz auf `0.1` gesetzt, damit Sie die Überlagerung sehen können):
+
+![Screenshot einer Clickjacking-Website, die die Bank-Website eingebettet zeigt.](attacker.png)
+
+Wenn der Benutzer versucht, auf "Click here for a free kitten!" zu klicken, klickt er tatsächlich auf den unsichtbaren "Transfer all your money?"-Button auf der Bank-Website. Wenn der Benutzer bereits angemeldet ist, wird die Anforderung, die an den Server der Bank gesendet wird, die echten Anmeldedaten des Benutzers enthalten und die Anforderung wird erfolgreich ausgeführt.
+
+## Clickjacking-Abwehrmaßnahmen
+
+Clickjacking hängt von der Tatsache ab, dass die Zielwebsite in der Lockvogel-Seite des Angreifers innerhalb eines `<iframe>` eingebettet ist. Die Hauptabwehrmaßnahme besteht darin, diese Möglichkeit zu verbieten oder zumindest zu kontrollieren.
+
+Hierfür gibt es zwei relevante Werkzeuge:
+
+- Die [`frame-ancestors`-Direktive](/de/docs/Web/HTTP/CSP#clickjacking_protection) in einer [Content-Security-Policy](/de/docs/Web/HTTP/CSP)
+- Der {{httpheader("X-Frame-Options")}}-Antwortheader.
+
+Die `frame-ancestors`-Direktive ist ein Ersatz für `X-Frame-Options`. Durch das Setzen von `X-Frame-Options` und `frame-ancestors` kann das Einbetten in Browsern verhindert werden, die `frame-ancestors` nicht unterstützen. Da [die Unterstützung für `frame-ancestors` in Browsern sehr gut ist](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors#browser_compatibility), ist dies kein großes Problem.
+
+Wenn `frame-ancestors` und `X-Frame-Options` beide gesetzt sind, ignorieren Browser, die `frame-ancestors` unterstützen, `X-Frame-Options`.
+
+Als zusätzliche partielle Gegenmaßnahme sollten Websites das [`SameSite`](/de/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value)-Cookie-Attribut für Sitzungs-Cookies auf `Lax` oder `Strict` setzen. Anfragen aus eingebetteten Kontexte wie `<iframe>`-Elementen, die nicht {{Glossary("Site", "same-site")}} mit dem obersten Dokument sind, werden diese Cookies nicht enthalten, und der Server wird die Anfrage daher nicht als von einem angemeldeten Benutzer kommend behandeln.
+
+## Siehe auch
+
+- [Clickjacking Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) auf [owasp.org](https://owasp.org/)
+
+<section id="Quick_links">
+{{ListSubpages("/de/docs/Web/Security", "1", "0", "1")}}
+</section>
diff --git a/files/de/web/security/attacks/index.md b/files/de/web/security/attacks/index.md
index 5ccb0ae40..305a39b01 100644
--- a/files/de/web/security/attacks/index.md
+++ b/files/de/web/security/attacks/index.md
@@ -2,12 +2,14 @@
 title: Angriffe
 slug: Web/Security/Attacks
 l10n:
-  sourceCommit: 023a970ac41f9de098b31650b69f210e3be368e1
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
-In der Websicherheit ist ein Angriff eine spezifische Methode, die ein Angreifer einsetzt, um sein Ziel zu erreichen. Wenn zum Beispiel das Ziel darin besteht, die Daten eines Benutzers zu stehlen, könnte ein Cross-Site-Scripting (XSS)-Angriff eine der Methoden sein, die sie verwenden. Ein gegebener Angriff kann durch eine oder mehrere Gegenmaßnahmen abgewehrt werden: Zum Beispiel könnte XSS durch korrektes Sanitieren von Daten und Implementierung einer [Content-Security-Policy](/de/docs/Web/HTTP/CSP) abgewehrt werden.
+Im Bereich der Web-Sicherheit ist ein Angriff eine spezifische Methode, die ein Angreifer verwendet, um sein Ziel zu erreichen. Wenn zum Beispiel das Ziel darin besteht, die Daten eines Benutzers zu stehlen, könnte ein Cross-Site-Scripting- (XSS) Angriff eine Methode sein, die er verwendet. Ein bestimmter Angriff kann durch eine oder mehrere Maßnahmen abgewehrt werden: zum Beispiel könnte XSS durch das richtige Bereinigen von Daten und die Implementierung einer [Content-Security-Policy](/de/docs/Web/HTTP/CSP) abgewehrt werden.
 
-Diese Seite verlinkt zu Seiten, die erklären, wie einige gängige Angriffe funktionieren und wie sie gemindert werden können.
+Diese Seite verlinkt auf Seiten, die erklären, wie einige gängige Angriffe funktionieren und wie sie abgewehrt werden können.
 
+- [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking)
+  - : Bei einem Clickjacking-Angriff erstellt ein Angreifer eine Köderseite, die die Zielseite innerhalb eines {{htmlelement("iframe")}}-Elements einbettet. Er verbirgt das `<iframe>` und überlagert einige Köderelemente darüber. Wenn der Benutzer mit diesen Köderelementen interagiert, interagiert er unbeabsichtigt mit der Zielseite und könnte dazu verleitet werden, Aktionen mit der Zielseite durchzuführen, die er nicht beabsichtigt hatte.
 - [Cross-site scripting (XSS)](/de/docs/Web/Security/Attacks/XSS)
-  - : Bei einem Cross-Site-Scripting (XSS)-Angriff akzeptiert eine Website eine vom Angreifer gestaltete Eingabe und integriert diese fälschlicherweise in die eigenen Seiten der Website so, dass der Browser sie als Code ausführt. Der bösartige Code kann dann alles tun, was der eigene Frontend-Code der Website tun könnte.
+  - : Bei einem Cross-Site-Scripting- (XSS) Angriff akzeptiert eine Website einige vom Angreifer erstellte Eingaben und nimmt diese fälschlicherweise in die eigenen Seiten der Website auf, sodass der Browser sie als Code ausführt. Der bösartige Code kann dann alles tun, was der eigene Frontend-Code der Website tun könnte.
diff --git a/files/de/web/security/index.md b/files/de/web/security/index.md
index daac4bb6c..3c60fc6f9 100644
--- a/files/de/web/security/index.md
+++ b/files/de/web/security/index.md
@@ -2,178 +2,178 @@
 title: Sicherheit im Web
 slug: Web/Security
 l10n:
-  sourceCommit: f75b2c86ae4168e59416aed4c7121f222afc201d
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
-Websites enthalten verschiedene Arten von Informationen. Manche davon sind nicht sensibel, zum Beispiel der Text auf öffentlichen Seiten. Andere Informationen sind sensibel, wie Benutzernamen, Passwörter und Bankinformationen von Kunden oder interne Algorithmen und private Produktinformationen.
+Websites enthalten verschiedene Arten von Informationen. Einige davon sind nicht sensibel, wie zum Beispiel der Text auf öffentlichen Seiten. Andere sind sensibel, wie zum Beispiel Kundennamen, Passwörter und Bankinformationen, oder interne Algorithmen und private Produktinformationen.
 
-Empfindliche Informationen müssen geschützt werden, und darauf liegt der Fokus der Web-Sicherheit. Falls diese Informationen in die falschen Hände gelangen, könnten sie verwendet werden, um:
+Sensible Informationen müssen geschützt werden, und darauf liegt der Fokus der Websicherheit. Wenn diese Informationen in die falschen Hände gelangen, könnten sie genutzt werden, um:
 
-- Unternehmen durch Weitergabe ihrer Informationen an Wettbewerber in eine nachteilige Position zu bringen.
-- Ihre Dienste zu deaktivieren oder zu kapern, was zu ernsthaften Betriebsproblemen führen könnte.
-- Die [Privatsphäre](/de/docs/Web/Privacy) ihrer Kunden zu gefährden, wodurch sie anfällig für Profiling, Targeting, Datenverlust, Identitätsdiebstahl oder sogar finanzielle Verluste werden.
+- Unternehmen durch das Teilen ihrer Informationen mit Wettbewerbern einen Wettbewerbsnachteil zu verschaffen.
+- Ihre Dienste zu deaktivieren oder zu kapern und damit ernste Probleme für den Betrieb zu verursachen.
+- Die [Privatsphäre](/de/docs/Web/Privacy) ihrer Kunden zu gefährden, wodurch sie anfällig für Profiling, gezielte Angriffe, Datenverlust, Identitätsdiebstahl oder sogar finanziellen Verlust werden.
 
-Moderne Browser verfügen bereits über mehrere Funktionen, um die Sicherheit der Nutzer im Web zu gewährleisten. Entwickler müssen jedoch auch Best Practices anwenden und sorgfältigen Code schreiben, um sicherzustellen, dass ihre Websites sicher sind. Selbst einfache Fehler im Code können zu Schwachstellen führen, die von Schadakteuren ausgenutzt werden können, um Daten zu stehlen und unbefugte Kontrolle über Dienste zu erlangen.
+Moderne Browser verfügen bereits über mehrere Funktionen, um die Sicherheit der Nutzer im Web zu schützen, aber Entwickler müssen auch bewährte Praktiken anwenden und sorgfältig programmieren, um sicherzustellen, dass ihre Websites sicher sind. Selbst einfache Fehler im Code können zu Schwachstellen führen, die von böswilligen Akteuren ausgenutzt werden können, um Daten zu stehlen und unbefugte Kontrolle über Dienste zu erlangen.
 
-Dieser Artikel bietet eine Einführung in die Web-Sicherheit, einschließlich Konzepten, die Ihnen helfen, Website-Schwachstellen zu verstehen, und praktischen Anleitungen, wie Sie sie sichern können.
+Dieser Artikel bietet eine Einführung in die Websicherheit, einschließlich konzeptioneller Informationen, die Ihnen helfen, Website-Schwachstellen zu verstehen, sowie praktischen Leitfäden zur Sicherung solcher Schwachstellen.
 
 ## Beziehung zwischen Sicherheit und Privatsphäre
 
-Sicherheit und Privatsphäre sind unterschiedliche, aber eng verwandte Themen. Es lohnt sich, die Unterschiede zwischen beiden und ihre Beziehung zueinander zu kennen.
+Sicherheit und Privatsphäre sind voneinander getrennte, aber eng verwandte Themen. Es ist wichtig, die Unterschiede zwischen beiden und ihre Beziehung zueinander zu kennen.
 
-- **Sicherheit** ist der Akt, private Daten und Systeme gegen unbefugten Zugriff zu schützen. Dies betrifft sowohl Unternehmensdaten (interne) als auch Benutzer- und Partnerdaten (externe).
+- **Sicherheit** ist der Akt, private Daten und Systeme vor unbefugtem Zugriff zu schützen. Dies umfasst sowohl Unternehmensdaten (interne) als auch Benutzer- und Partnerdaten (externe).
 
-- **Privatsphäre** bezieht sich darauf, den Nutzern die Kontrolle darüber zu geben, wie ihre Daten gesammelt, gespeichert und verwendet werden, während gleichzeitig sichergestellt wird, dass sie nicht unverantwortlich genutzt werden. Beispielsweise sollten Sie Ihren Nutzern mitteilen, welche Daten Sie von ihnen erheben, mit welchen Parteien sie geteilt werden und wie sie genutzt werden. Nutzer müssen die Möglichkeit haben, Ihrer Datenschutzrichtlinie zuzustimmen, Zugang zu ihren gespeicherten Daten zu erhalten und sie bei Bedarf zu löschen.
+- **Privatsphäre** bezieht sich auf den Akt, den Nutzern die Kontrolle darüber zu geben, wie ihre Daten gesammelt, gespeichert und genutzt werden, und sicherzustellen, dass sie nicht verantwortungslos genutzt werden. Beispielsweise sollten Sie Ihre Nutzer darüber informieren, welche Daten Sie von ihnen sammeln, mit welchen Parteien sie geteilt werden und wie sie verwendet werden. Benutzer müssen die Möglichkeit erhalten, Ihrer Datenschutzrichtlinie zuzustimmen, auf ihre bei Ihnen gespeicherten Daten zuzugreifen und diese bei Bedarf zu löschen.
 
-Gute Sicherheit ist essentiell für gute Privatsphäre. Sie könnten alle Ratschläge in unserem [Leitfaden zur Privatsphäre im Web](/de/docs/Web/Privacy) befolgen, aber mit Integrität handeln und eine robuste Datenschutzrichtlinie haben ist sinnlos, wenn Ihre Seite nicht sicher ist und Angreifer die Daten ohnehin stehlen können.
+Gute Sicherheit ist für gute Privatsphäre unerlässlich. Sie könnten alle Ratschläge aus unserem [Privatsphäre im Web](/de/docs/Web/Privacy) Leitfaden befolgen, aber Integrität und eine robuste Datenschutzrichtlinie sind zwecklos, wenn Ihre Seite nicht sicher ist und Angreifer ohnehin Daten stehlen können.
 
-## Sicherheitsfunktionen von Browsern
+## Sicherheitsfunktionen, die von Browsern bereitgestellt werden
 
-Webbrowser folgen einem strikten Sicherheitsmodell, das starke Sicherheit für Inhalte, Verbindungen zwischen Browser und Server sowie den Datentransport erzwingt. Dieser Abschnitt befasst sich mit den Funktionen, die dieses Modell untermauern.
+Webbrowser folgen einem strikten Sicherheitsmodell, das starke Sicherheit für Inhalte, Verbindungen zwischen dem Browser und dem Server sowie den Datentransport durchsetzt. In diesem Abschnitt sehen wir uns die Funktionen an, die diesem Modell zugrunde liegen.
 
-### Same-Origin-Policy und CORS
+### Same-origin policy und CORS
 
-[Same-Origin-Policy](/de/docs/Web/Security/Same-origin_policy) ist ein grundlegender Sicherheitsmechanismus des Webs, der einschränkt, wie ein Dokument oder Skript von einem {{Glossary("origin", "Ursprung")}} mit einer Ressource von einem anderen Ursprung interagieren kann. Es hilft, potenziell schädliche Dokumente zu isolieren und mögliche Angriffspunkte zu reduzieren.
+Die [Same-origin Policy](/de/docs/Web/Security/Same-origin_policy) ist ein grundlegender Sicherheitsmechanismus des Webs, der einschränkt, wie ein Dokument oder Skript, das von einem {{Glossary("origin", "Ursprung")}} geladen wird, mit einer Ressource von einem anderen Ursprung interagieren kann. Es hilft, potenziell schädliche Dokumente zu isolieren und so mögliche Angriffsvektoren zu reduzieren.
 
-Im Allgemeinen können Dokumente von einem Ursprung keine Anfragen an andere Ursprünge stellen. Das macht Sinn, weil man nicht möchte, dass Seiten miteinander interferieren und unbefugten Zugriff auf Daten haben.
+Im Allgemeinen können Dokumente von einem Ursprung keine Anfragen an andere Ursprünge stellen. Dies ist sinnvoll, da verhindert werden soll, dass Websites einander stören und unbefugten Zugriff auf Daten erhalten.
 
-Manchmal möchten Sie diese Einschränkung jedoch lockern; beispielsweise, wenn Sie mehrere Websites haben, die miteinander interagieren. Sie können ihnen erlauben, Ressourcen voneinander anzufordern, indem Sie [`fetch()`](/de/docs/Web/API/Window/fetch) verwenden. Dies kann durch [Cross-Origin Resource Sharing (CORS)](/de/docs/Web/HTTP/CORS) ermöglicht werden, einen auf HTTP-Headern basierenden Mechanismus, der einem Server erlaubt, anzugeben, welche Ursprünge (Domäne, Schema oder Port) außer seiner eigenen erlaubt sind, um Ressourcen zu laden.
+In manchen Fällen möchten Sie diese Einschränkung jedoch lockern, z. B. wenn Sie mehrere Websites haben, die miteinander interagieren. Dann könnten Sie es ihnen erlauben, Ressourcen voneinander anzufordern, indem Sie [`fetch()`](/de/docs/Web/API/Window/fetch) verwenden. Dies kann durch [Cross-Origin Resource Sharing (CORS)](/de/docs/Web/HTTP/CORS) ermöglicht werden, einem HTTP-Header-basierten Mechanismus, der es einem Server erlaubt, Browsern mitzuteilen, welche Ursprünge (Domain, Schema oder Port) von seinem eigenen abweichend sind, von denen das Laden von Ressourcen erlaubt sein sollte.
 
-### HTTP-Kommunikationsmodell
+### HTTP-Modell für die Kommunikation
 
-Das [HTTP](/de/docs/Web/HTTP)-Protokoll wird von Webbrowsern und Servern genutzt, um miteinander zu kommunizieren, Ressourcen anzufordern, Antworten bereitzustellen (zum Beispiel eine angeforderte Ressource bereitzustellen oder die Gründe zu detaillieren, warum eine Anfrage fehlgeschlagen ist) und Sicherheitsfunktionen für diese Kommunikation zu bieten.
+Das [HTTP](/de/docs/Web/HTTP)-Protokoll wird von Webbrowsern und Servern verwendet, um miteinander zu kommunizieren, Ressourcen anzufordern, Antworten bereitzustellen (z. B. um eine angeforderte Ressource bereitzustellen oder zu erläutern, warum eine Anfrage fehlgeschlagen ist) und Sicherheitsfunktionen für diese Kommunikation bereitzustellen.
 
-Transport Layer Security (TLS) bietet Sicherheit und Privatsphäre, indem es Daten während des Transports über das Netzwerk verschlüsselt, und ist die Technologie hinter dem {{Glossary("HTTPS", "HTTPS")}}-Protokoll. TLS ist gut für die Privatsphäre, da es verhindert, dass Dritte übertragene Daten abfangen und missbräuchlich verwenden können.
+Transport Layer Security (TLS) bietet Sicherheit und Privatsphäre, indem Daten während des Transports über das Netzwerk verschlüsselt werden, und ist die Technologie hinter dem {{Glossary("HTTPS", "HTTPS")}}-Protokoll. TLS ist gut für die Privatsphäre, da es Dritten verwehrt, übertragene Daten abzufangen und diese böswillig zu nutzen.
 
-Alle Browser bewegen sich in Richtung einer standardmäßigen Anforderung von HTTPS; in der Praxis ist dies bereits der Fall, da man ohne dieses Protokoll im Web nicht viel tun kann.
+Alle Browser bewegen sich in Richtung einer verpflichtenden Nutzung von HTTPS als Standard; dies ist bereits fast der Fall, da auf dem Web ohne dieses Protokoll nicht viel unternommen werden kann.
 
 Verwandte Themen:
 
 - [Transport Layer Security](/de/docs/Web/Security/Transport_Layer_Security) (TLS)
-  - : Das TLS-Protokoll ist der Standard, um zwei vernetzten Anwendungen oder Geräten eine private und robuste Informationsübermittlung zu ermöglichen. Anwendungen, die TLS verwenden, können ihre Sicherheitsparameter wählen, was erhebliche Auswirkungen auf die Sicherheit und Zuverlässigkeit der Daten haben kann.
+  - : Das TLS-Protokoll ist der Standard für die sichere und robuste Übermittlung von Informationen zwischen zwei Netzwerkanwendungen oder -geräten. Anwendungen, die TLS nutzen, können ihre Sicherheitsparameter selbst wählen, was erhebliche Auswirkungen auf die Sicherheit und Zuverlässigkeit der Daten haben kann.
 - [HTTP Strict-Transport-Security](/de/docs/Web/HTTP/Headers/Strict-Transport-Security)
-  - : Der `Strict-Transport-Security` [HTTP](/de/docs/Web/HTTP)-Header lässt eine Website spezifizieren, dass sie nur über HTTPS zugänglich sein darf.
+  - : Der `Strict-Transport-Security` [HTTP](/de/docs/Web/HTTP)-Header erlaubt es einer Website zu spezifizieren, dass sie nur über HTTPS zugänglich sein darf.
 - [Certificate Transparency](/de/docs/Web/Security/Certificate_Transparency)
-  - : Certificate Transparency (CT) ist ein offenes Rahmenwerk, das entwickelt wurde, um gegen die fehlerhafte Ausstellung von Zertifikaten zu schützen und diese zu überwachen. Neu ausgestellte Zertifikate werden in öffentlich betriebenen, oft unabhängigen CT-Logs protokolliert. Diese bieten append-only, kryptographisch abgesicherte Aufzeichnungen der ausgestellten TLS-Zertifikate.
+  - : Certificate Transparency (CT) ist ein offenes Framework, das entwickelt wurde, um Zertifikatsmissbrauch zu verhindern und zu überwachen. Neu ausgegebene Zertifikate werden in öffentlich betriebenen, oft unabhängigen CT-Protokollen 'geloggt'. Diese bieten unveränderliche, kryptografisch gesicherte Aufzeichnungen über ausgegebene TLS-Zertifikate.
 - [Mixed Content](/de/docs/Web/Security/Mixed_content)
-  - : Eine HTTPS-Seite, die Inhalte einbindet, die über {{Glossary("Plaintext", "Klartext")}} HTTP abgerufen werden, wird als **mixed content** Seite bezeichnet. Solche Seiten sind nur teilweise verschlüsselt und lassen den unverschlüsselten Inhalt angreifbar für Abhörer und Man-in-the-Middle-Angreifer.
+  - : Eine HTTPS-Seite, die Inhalte enthält, die über {{Glossary("Plaintext", "Klartext")}} HTTP abgerufen werden, wird als **Mixed Content**-Seite bezeichnet. Solche Seiten sind nur teilweise verschlüsselt, was den unverschlüsselten Inhalt für Lauscher und Man-in-the-Middle-Angreifer zugänglich macht.
 - [Schwache Signaturalgorithmen](/de/docs/Web/Security/Weak_Signature_Algorithm)
-  - : Die Stärke des Hash-Algorithmus, der bei der {{Glossary("Signature/Security", "Signierung")}} eines {{Glossary("digital_certificate", "digitalen Zertifikats")}} verwendet wird, ist ein kritisches Element der Sicherheit des Zertifikats. Einige Signaturalgorithmen sind dafür bekannt, schwach zu sein und sollten vermieden werden, wenn es angebracht ist.
+  - : Die Stärke des Hash-Algorithmus, der bei der {{Glossary("Signature/Security", "Signierung")}} eines {{Glossary("digital_certificate", "Digitalzertifikats")}} verwendet wird, ist ein entscheidendes Element für die Sicherheit des Zertifikats. Einige Signaturalgorithmen sind bekanntlich schwach und sollten, wenn angebracht, vermieden werden.
 
-### Sichere Kontexte und Funktionsberechtigungen
+### Sichere Kontexte und Feature-Berechtigungen
 
-Browser kontrollieren die Nutzung von "leistungsstarken Features" auf unterschiedliche Weise. Diese "leistungsstarken Features" umfassen das Generieren von Systembenachrichtigungen auf einer Website, die Nutzung der Webcam eines Benutzers, um Zugriff auf einen Medienstrom zu erhalten, die Manipulation der System-GPU und die Verwendung von Web-Zahlungen. Wenn eine Website einfach die APIs nutzen könnte, die solche Features kontrollieren, ohne Einschränkungen, könnten böswillige Entwickler versuchen, folgendes zu tun:
+Browser kontrollieren die Nutzung von "leistungsstarken Funktionen" auf unterschiedliche Weise. Diese "leistungsstarken Funktionen" umfassen das Erstellen von Systembenachrichtigungen auf einer Website, die Nutzung der Webcam eines Benutzers, um Zugriff auf einen Medienstream zu erhalten, das Manipulieren der System-GPU und die Nutzung von Webzahlungen. Wenn eine Website einfach so die APIs nutzen könnte, die diese Funktionen steuern, könnten böswillige Entwickler versuchen, Folgendes zu tun:
 
-- Nutzer mit unnötigen Benachrichtigungen und anderen UI-Funktionen nerven.
-- Ihre Webcam ohne Warnung einschalten, um sie auszuspionieren.
-- Ihren Browser/System belasten, um {{Glossary("denial_of_service", "Denial of Service")}}-Angriffe (DoS) zu erstellen.
-- Daten oder Geld stehlen.
+- Benutzer mit unnötigen Benachrichtigungen und anderen UI-Funktionen zu belästigen.
+- Ihre Webcam ohne Vorwarnung einzuschalten, um sie auszuspionieren.
+- Ihren Browser/System zu überlasten, um {{Glossary("denial_of_service", "Denial of Service")}} (DoS)-Angriffe durchzuführen.
+- Daten oder Geld zu stehlen.
 
-Diese "leistungsstarken Features" werden auf folgende Weise kontrolliert:
+Diese "leistungsstarken Funktionen" werden auf folgende Weise kontrolliert:
 
-- Die Nutzung solcher Features ist nur in [sicheren Kontexten](/de/docs/Web/Security/Secure_Contexts) erlaubt. Ein sicherer Kontext ist ein [`window`](/de/docs/Web/API/Window) oder ein [`worker`](/de/docs/Web/API/WorkerGlobalScope), bei dem es eine hinreichende Gewissheit gibt, dass die Inhalte sicher (über HTTPS/TLS) geliefert wurden. In einem sicheren Kontext ist das Potenzial für die Kommunikation mit Kontexten, die **nicht** sicher sind, begrenzt. Sichere Kontexte helfen auch dabei, [Man-in-the-Middle-Angreifer](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) daran zu hindern, leistungsstarke Features zu nutzen.
+- Die Nutzung solcher Funktionen ist nur in [sicheren Kontexten](/de/docs/Web/Security/Secure_Contexts) erlaubt. Ein sicherer Kontext ist ein [`window`](/de/docs/Web/API/Window) oder ein [`worker`](/de/docs/Web/API/WorkerGlobalScope), bei dem eine angemessene Sicherheit angenommen werden kann, dass die Inhalte sicher übermittelt wurden (via HTTPS/TLS). In einem sicheren Kontext ist das Potenzial für die Kommunikation mit Kontexten, die **nicht** sicher sind, begrenzt. Sichere Kontexte helfen auch, die Nutzung leistungsstarker Funktionen durch [Man-in-the-Middle-Angreifer](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) zu verhindern.
 
-  Eine Liste von Web-Plattform-Features, die nur in sicheren Kontexten verfügbar sind, finden Sie unter [Features restricted to secure contexts](/de/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts).
+  Eine Liste der Webplattformfunktionen, die nur in sicheren Kontexten verfügbar sind, finden Sie unter [Features restricted to secure contexts](/de/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts).
 
-- Die Nutzung dieser Features wird durch ein Benutzergenehmigungssystem gesteuert: Nutzer müssen ausdrücklich zustimmen, Zugang zu solchen Features zu gewähren, was bedeutet, dass sie nicht automatisch genutzt werden können. Benutzerberechtigungsanfragen erfolgen automatisch, und Sie können den Status einer API-Berechtigung mithilfe der [Permissions API](/de/docs/Web/API/Permissions_API) abfragen.
+- Die Nutzung dieser Funktionen hängt von einem System von Benutzerberechtigungen ab: Benutzer müssen ausdrücklich zustimmen, Zugriff auf solche Funktionen zu gewähren, was bedeutet, dass sie nicht automatisch genutzt werden können. Benutzerberechtigungsanfragen erfolgen automatisch, und Sie können den Status einer API-Berechtigung abfragen, indem Sie die [Permissions API](/de/docs/Web/API/Permissions_API) verwenden.
 
-- Mehrere andere Browser-Funktionen können nur als Reaktion auf eine Benutzeraktion verwendet werden, wie zum Beispiel das Klicken auf einen Button, was bedeutet, dass sie innerhalb eines geeigneten Ereignishandlers aufgerufen werden müssen. Dies wird als **transiente Aktivierung** bezeichnet. Siehe [Features gated by user activation](/de/docs/Web/Security/User_activation) für weitere Informationen.
+- Mehrere andere Browserfunktionen können nur als Reaktion auf eine Benutzeraktion wie das Klicken auf eine Schaltfläche genutzt werden, was bedeutet, dass sie innerhalb eines entsprechenden Event-Handlers aufgerufen werden müssen. Dies wird als **transiente Aktivierung** bezeichnet. Weitere Informationen finden Sie unter [Features gated by user activation](/de/docs/Web/Security/User_activation).
 
-## Sicherheitsüberlegungen auf hoher Ebene
+## Wichtige Sicherheitsüberlegungen
 
-Es gibt viele Aspekte der Web-Sicherheit, die sowohl auf der Server- als auch auf der Client-Seite bedacht werden müssen. Dieser Abschnitt konzentriert sich hauptsächlich auf sicherheitsrelevante Überlegungen auf der Client-Seite. Eine nützliche Zusammenfassung der Sicherheit aus serverseitiger Perspektive, die auch Beschreibungen häufiger Angriffe enthält, auf die Sie achten sollten, finden Sie unter [Website-Sicherheit](/de/docs/Learn/Server-side/First_steps/Website_security) (Teil unseres [Programmiermoduls für die serverseitige Website-Entwicklung](/de/docs/Learn/Server-side)).
+Es gibt viele Aspekte der Websicherheit, die sowohl auf der Server- als auch auf der Client-Seite berücksichtigt werden müssen. Dieser Abschnitt konzentriert sich hauptsächlich auf Sicherheitsüberlegungen auf der Client-Seite. Sie können eine nützliche Zusammenfassung von Sicherheitsperspektiven auf der Server-Seite finden, die auch Beschreibungen häufiger Angriffe enthält, auf die man achten sollte, unter [Websitesicherheit](/de/docs/Learn/Server-side/First_steps/Website_security) (Teil unseres Lernmoduls [Serverseitige Webseitenprogrammierung](/de/docs/Learn/Server-side)).
 
-### Speichern Sie clientseitige Daten verantwortungsbewusst
+### Clientseitige Daten verantwortungsvoll speichern
 
-Der verantwortungsvolle Umgang mit Daten konzentriert sich hauptsächlich auf die Reduzierung der Nutzung von [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und darauf, vorsichtig mit den Daten zu sein, die Sie speichern und weitergeben. Traditionell haben Webentwickler Cookies benutzt, um alle Arten von Daten zu speichern, und es war für Angreifer einfach, diese Neigungen auszunutzen. Infolgedessen haben Browser begonnen, einzuschränken, was mit cookiesähnlichen Daten getan werden kann, mit dem Ziel, den Zugang zu ihnen in Zukunft vollständig zu entfernen.
+Ein verantwortungsvoller Umgang mit Daten betrifft größtenteils die Reduzierung der Nutzung von [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies) und die sorgfältige Handhabung der Daten, die Sie speichern und mit ihnen teilen. Traditionell haben Webentwickler Cookies verwendet, um alle möglichen Daten zu speichern, und es war für Angreifer einfach, diese Tendenz auszunutzen. Infolgedessen haben Browser begonnen, die Nutzung von Cross-Site-Cookies einzuschränken, mit dem Ziel, den Zugriff auf sie in Zukunft vollständig zu entfernen.
 
-Sie sollten sich auf die Entfernung von cookiesähnlichen Daten aus Dritthand vorbereiten, indem Sie die Anzahl der Tracking-Aktivitäten, auf die Sie sich verlassen, beschränken und/oder die Persistence der gewünschten Informationen auf andere Weise implementieren. Siehe [Übergang von Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies#transitioning_from_third-party_cookies) und [Ersetzung von Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies#replacing_third-party_cookies) für mehr Informationen.
+Sie sollten sich auf die Entfernung von Cross-Site-Cookies vorbereiten, indem Sie die Anzahl der Tracking-Aktivitäten einschränken, auf die Sie angewiesen sind, und/oder die Persistenz der gewünschten Informationen auf andere Weise implementieren. Siehe [Übergang von Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies#transitioning_from_third-party_cookies) und [Ersetzen von Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies#replacing_third-party_cookies) für weitere Informationen.
 
-### Schützen Sie die Benutzeridentität und verwalten Sie Logins
+### Benutzeridentität schützen und Anmeldungen verwalten
 
-Wenn Sie eine sichere Lösung implementieren, die die Erfassung von Daten beinhaltet, insbesondere wenn es sich um sensible Daten wie Anmeldedaten handelt, ist es sinnvoll, eine seriöse Lösung zu verwenden. Beispielsweise bietet jedes angesehene serverseitige Framework integrierte Funktionen zum Schutz vor häufigen Schwachstellen. Sie könnten auch erwägen, ein spezialisiertes Produkt für Ihren Zweck zu verwenden, zum Beispiel eine Identitätsprovider-Lösung oder einen sicheren Online-Umfrageanbieter.
+Wenn Sie eine sichere Lösung implementieren, die Datenerfassung beinhaltet, insbesondere wenn die Daten sensibel sind, wie beispielsweise Anmeldeinformationen, ist es sinnvoll, eine seriöse Lösung zu verwenden. Zum Beispiel wird ein respektiertes serverseitiges Framework eingebaute Funktionen zum Schutz vor häufigen Schwachstellen bieten. Sie könnten auch in Erwägung ziehen, ein spezielles Produkt für Ihren Zweck zu verwenden, zum Beispiel eine Identitätsanbieterlösung oder einen sicheren Online-Umfrageanbieter.
 
-Wenn Sie Ihre eigene Lösung zum Sammeln von Benutzerdaten entwickeln möchten, stellen Sie sicher, dass Sie alle Aspekte und Anforderungen verstehen. Beauftragen Sie einen erfahrenen serverseitigen Entwickler und/oder Sicherheitsingenieur, um das System zu implementieren, und stellen Sie sicher, dass es gründlich getestet wird. Verwenden Sie Multi-Faktor-Authentifizierung (MFA), um besseren Schutz zu bieten. Ziehen Sie in Betracht, eine dedizierte API wie [Web Authentication](/de/docs/Web/API/Web_Authentication_API) oder [Federated Credential Management](/de/docs/Web/API/FedCM_API) zu nutzen, um die clientseitige App zu optimieren.
+Wenn Sie Ihre eigene Lösung zur Erfassung von Benutzerdaten entwickeln möchten, stellen Sie sicher, dass Sie alle Aspekte und Anforderungen verstehen. Engagieren Sie einen erfahrenen serverseitigen Entwickler und/oder Sicherheitstechniker, um das System zu implementieren, und sorgen Sie dafür, dass es gründlich getestet wird. Verwenden Sie Multi-Faktor-Authentifizierung (MFA) zur besseren Absicherung. Ziehen Sie die Verwendung einer speziellen API wie [Web Authentication](/de/docs/Web/API/Web_Authentication_API) oder [Federated Credential Management](/de/docs/Web/API/FedCM_API) in Erwägung, um die clientseitige App zu optimieren.
 
-Hier sind einige andere Tipps für sichere Logins:
+Hier sind einige weitere Tipps, um sichere Anmeldungen bereitzustellen:
 
-- Bei der Erfassung von Benutzeranmeldeinformationen sollten Sie starke Passwörter durchsetzen, damit die Kontodaten Ihrer Nutzer nicht leicht erraten werden können. Schwache Passwörter sind eine der Hauptursachen für Sicherheitsverletzungen. Außerdem sollten Sie Ihre Nutzer dazu ermutigen, einen Passwort-Manager zu verwenden, damit sie komplexere Passwörter nutzen können, sich nicht daran erinnern müssen und kein Sicherheitsrisiko eingehen, indem sie sie aufschreiben. Siehe dazu auch unseren Artikel über [unsichere Passwörter](/de/docs/Web/Security/Insecure_passwords).
-- Sie sollten Ihre Nutzer auch über **Phishing** aufklären. Phishing ist der Akt, einem Nutzer eine Nachricht zu senden (zum Beispiel eine E-Mail oder SMS), die einen Link zu einer Website enthält, die wie eine bekannte Seite aussieht, aber nicht ist. Der Link ist von einer Nachricht begleitet, die den Nutzer dazu bringen soll, seine Benutzerdaten und sein Passwort einzugeben, damit diese gestohlen und von einem Angreifer für böswillige Zwecke verwendet werden können.
+- Wenn Sie Benutzeranmeldeinformationen sammeln, erzwingen Sie starke Passwörter, damit die Kontodaten Ihrer Benutzer nicht leicht erraten werden können. Schwache Passwörter sind eine der Hauptursachen für Sicherheitsverstöße. Darüber hinaus sollten Sie Ihre Benutzer ermutigen, einen Passwort-Manager zu verwenden, damit sie komplexere Passwörter nutzen können, sich keine Sorgen um das Merken dieser machen müssen und keine Sicherheitsrisiko durch das Aufschreiben erzeugen. Siehe auch unseren Artikel zu [Unsicheren Passwörtern](/de/docs/Web/Security/Insecure_passwords).
+- Sie sollten Ihre Benutzer auch über **Phishing** aufklären. Phishing ist der Akt des Versendens einer Nachricht an einen Benutzer (z. B. eine E-Mail oder eine SMS), die einen Link zu einer Webseite enthält, die aussieht wie eine, die sie täglich nutzen, es aber nicht ist. Der Link wird von einer Nachricht begleitet, die darauf abzielt, Benutzer dazu zu verleiten, ihren Benutzernamen und ihr Passwort auf der Webseite einzugeben, damit es gestohlen und dann von einem Angreifer für böswillige Zwecke verwendet werden kann.
 
   > [!NOTE]
-  > Einige Phishing-Seiten können sehr ausgeklügelt und schwer von einer echten Website zu unterscheiden sein. Sie sollten Ihre Nutzer daher darauf hinweisen, nicht blindlings Links in E-Mails oder SMS zu vertrauen. Erhalten sie eine Nachricht mit einer Aufforderung wie "Dringend, Sie müssen sich jetzt einloggen, um ein Problem zu lösen", sollten sie die Seite in einem neuen Tab direkt aufrufen und versuchen, sich direkt einzuloggen, anstatt den Link in der Nachricht zu klicken. Oder sie könnten Sie anrufen oder eine E-Mail senden, um die erhaltene Nachricht zu besprechen.
+  > Einige Phishing-Websites können sehr ausgeklügelt sein und sich nur schwer von echten Websites unterscheiden lassen. Sie sollten Ihre Benutzer daher darauf schulen, keine zufälligen Links in E-Mails und SMS-Nachrichten zu vertrauen. Wenn sie eine Nachricht im Sinne von "Dringend, Sie müssen sich jetzt einloggen, um ein Problem zu lösen" erhalten, sollten sie die Seite direkt in einem neuen Tab aufrufen und sich direkt einloggen, anstatt auf den Link in der Nachricht zu klicken. Alternativ könnten sie Sie anrufen oder Ihnen eine E-Mail senden, um die erhaltene Nachricht zu besprechen.
 
-- Schützen Sie Login-Seiten gegen Brute-Force-Angriffe durch {{Glossary("rate_limit", "Rate Limiting")}}, Konto-Sperrungen nach einer bestimmten Anzahl fehlgeschlagener Versuche und [CAPTCHA-Herausforderungen](https://en.wikipedia.org/wiki/CAPTCHA).
-- Verwalten Sie Benutzersitzungen mit eindeutigen [Sitzungs-IDs](https://en.wikipedia.org/wiki/Session_ID) und melden Sie Nutzer nach Inaktivitätsperioden automatisch ab.
+- Schützen Sie Anmeldeseiten vor Brute-Force-Angriffen durch {{Glossary("rate_limit", "Ratenbegrenzung")}}, Kontosperrungen nach einer bestimmten Anzahl erfolgloser Versuche und [CAPTCHA-Herausforderungen](https://en.wikipedia.org/wiki/CAPTCHA).
+- Verwenden Sie für die Verwaltung von Benutzeranmeldesitzungen eindeutige [Session-IDs](https://en.wikipedia.org/wiki/Session_ID) und melden Sie Benutzer automatisch nach längeren Inaktivitätsphasen ab.
 
-### Sensible Daten nicht in URL-Query-Strings einfügen
+### Sensible Daten nicht in URL-Abfragezeichenfolgen einfügen
 
-Als allgemeine Regel sollten Sie [sensible Daten nicht in URL-Query-Strings einfügen](https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url), da, wenn eine dritte Partei die URL abfängt (zum Beispiel über den {{httpheader("Referer")}}-HTTP-Header), diese Informationen gestohlen werden könnten. Noch gravierender ist die Tatsache, dass diese URLs von öffentlichen Webcrawlern, HTTP-Proxys und Archivierungstools wie dem [Internet-Archiv](https://web.archive.org/) indexiert werden können, was bedeutet, dass Ihre sensiblen Daten auf öffentlich zugänglichen Ressourcen gespeichert werden könnten.
+Als allgemeine Regel sollten Sie [sensible Daten nicht in URL-Abfragezeichenfolgen einfügen](https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url), da ein Drittanbieter die URL abfangen könnte (zum Beispiel über den {{httpheader("Referer")}} HTTP-Header) und diese Informationen stehlen könnte. Noch ernster ist die Tatsache, dass diese URLs von öffentlichen Web-Crawlern, HTTP-Proxys und Archivierungswerkzeugen wie dem [Internetarchiv](https://web.archive.org/) indexiert werden können, was bedeutet, dass Ihre sensiblen Daten auf öffentlich zugänglichen Ressourcen bestehen bleiben könnten.
 
-Verwenden Sie `POST`-Anfragen statt `GET`-Anfragen, um diese Probleme zu vermeiden. Unser Artikel [Referer-Header-Richtlinie: Datenschutz- und Sicherheitsbedenken](/de/docs/Web/Security/Referer_header:_privacy_and_security_concerns) beschreibt ausführlich die Privatsphäre- und Sicherheitsrisiken im Zusammenhang mit dem `Referer`-Header und bietet Ratschläge zur Minderung dieser Risiken.
+Verwenden Sie `POST`-Anfragen statt `GET`-Anfragen, um diese Probleme zu vermeiden. Unser Artikel [Referer-Header-Richtlinie: Datenschutz- und Sicherheitsbedenken](/de/docs/Web/Security/Referer_header:_privacy_and_security_concerns) beschreibt detaillierter die Datenschutz- und Sicherheitsrisiken, die mit dem Referer-Header verbunden sind, und bietet Ratschläge zur Minderung dieser Risiken.
 
 > [!NOTE]
-> Das Vermeiden der Übermittlung sensibler Daten in URLs über `GET`-Anfragen kann auch dazu beitragen, sich gegen {{Glossary("CSRF", "Cross-Site-Request-Forgery")}} und [Replay-Angriffe](https://en.wikipedia.org/wiki/Replay_attack) zu schützen.
+> Vermeiden Sie die Übertragung sensibler Daten in URLs über `GET`-Anfragen, dies kann auch helfen, {{Glossary("CSRF", "Cross-site-Request-Forgery")}} und [Replay-Angriffe](https://en.wikipedia.org/wiki/Replay_attack) zu verhindern.
 
 ### Nutzungsrichtlinien durchsetzen
 
-Erwägen Sie die Verwendung von Webplattform-Funktionen wie [Content Security Policy](/de/docs/Web/HTTP/CSP) (CSP) und [Permissions Policy](/de/docs/Web/HTTP/Permissions_Policy), um eine Reihe von Nutzungsregeln für Features und Ressourcen auf Ihrer Website durchzusetzen, die es schwieriger machen, Schwachstellen einzuführen.
+Erwägen Sie die Nutzung von Webplattform-Funktionen wie [Content Security Policy](/de/docs/Web/HTTP/CSP) (CSP) und [Permissions Policy](/de/docs/Web/HTTP/Permissions_Policy), um eine Reihe von Regeln für die Nutzung von Funktionen und Ressourcen auf Ihrer Website durchzusetzen, die es erschweren, Schwachstellen einzuführen.
 
-CSP ermöglicht Ihnen eine zusätzliche Sicherheitsschicht, indem Sie beispielsweise festlegen, dass Bilder oder Skripte nur von bestimmten vertrauenswürdigen Ursprüngen geladen werden dürfen. Dies hilft, bestimmte Arten von Angriffen zu erkennen und zu mindern, einschließlich Cross-Site-Scripting ({{Glossary("Cross-site_scripting", "XSS")}}) und Dateninjektionsangriffe. Diese Angriffe umfassen eine Reihe von böswilligen Aktivitäten, einschließlich Datendiebstahl, Webseitenschändung und Verteilung von Malware.
+CSP erlaubt es Ihnen, eine zusätzliche Sicherheitsebene hinzuzufügen, indem Sie zum Beispiel festlegen, dass Bilder oder Skripte nur von bestimmten vertrauenswürdigen Ursprüngen geladen werden dürfen. Dies hilft dabei, bestimmte Arten von Angriffen zu erkennen und abzuschwächen, darunter Cross-Site-Scripting ({{Glossary("Cross-site_scripting", "XSS")}}) und Dateninjektionsangriffe. Diese Angriffe umfassen eine Reihe von bösartigen Aktivitäten, einschließlich Datendiebstahl, Website-Defacement und der Verteilung von Malware.
 
-Die Berechtigungspolitik funktioniert auf ähnliche Weise, konzentriert sich jedoch mehr darauf, den Zugriff auf bestimmte "leistungsstarke Features" ([wie zuvor erwähnt](#sichere_kontexte_und_funktionsberechtigungen)) zu erlauben oder zu blockieren.
+Die Berechtigungsrichtlinie funktioniert auf ähnliche Weise, ist jedoch mehr darauf ausgerichtet, den Zugang zu spezifischen "leistungsstarken Funktionen" ([wie bereits erwähnt](#sichere_kontexte_und_feature-berechtigungen)) zu erlauben oder zu blockieren.
 
 > [!NOTE]
-> Solche Richtlinien sind sehr nützlich, um Websites sicher zu halten, insbesondere wenn Sie viel Drittcode auf Ihrer Seite verwenden. Beachten Sie jedoch, dass, wenn Sie die Nutzung eines Features blockieren, auf das ein Drittanbieter-Skript angewiesen ist, Sie möglicherweise die Funktionalität Ihrer Website beeinträchtigen können.
+> Solche Richtlinien sind sehr nützlich, um Websites sicher zu halten, insbesondere wenn Sie viel Fremdcode auf Ihrer Website verwenden. Beachten Sie jedoch, dass wenn Sie die Nutzung einer Funktion blockieren, auf die ein Drittskript angewiesen ist, um zu funktionieren, es sein kann, dass Sie die Funktionalität Ihrer Seite beeinträchtigen.
 
-### Datenintegrität wahren
+### Datenintegrität aufrechterhalten
 
-Aufbauend auf dem vorhergehenden Abschnitt sollten Sie, wenn Sie die Nutzung von Features und Ressourcen auf Ihrer Site erlauben, sicherstellen, dass die Ressourcen nicht manipuliert wurden.
+Aufbauend auf dem vorherigen Abschnitt sollten Sie, wenn Sie die Nutzung von Funktionen und Ressourcen auf Ihrer Seite erlauben, versuchen sicherzustellen, dass Ressourcen nicht manipuliert wurden.
 
 Verwandte Themen:
 
-- [Integrität von Subressourcen](/de/docs/Web/Security/Subresource_Integrity)
-  - : **Integrität von Subressourcen** (SRI) ist eine Sicherheitsfunktion, die es Browsern ermöglicht, zu überprüfen, dass die von ihnen abgerufenen Ressourcen (zum Beispiel von einem {{Glossary("CDN", "CDN")}}) ohne unerwartete Manipulation ausgeliefert werden. Es funktioniert, indem Sie einen kryptografischen Hash angeben, den eine abgerufene Ressource erfüllen muss.
+- [Subresource Integrity](/de/docs/Web/Security/Subresource_Integrity)
+  - : **Subresource Integrity** (SRI) ist eine Sicherheitsfunktion, die es Browsern ermöglicht zu überprüfen, dass die Ressourcen, die sie abrufen (zum Beispiel von einem {{Glossary("CDN", "CDN")}}), unverändert bereitgestellt werden. Sie funktioniert, indem Sie es Ihnen erlauben, einen kryptografischen Hash bereitzustellen, den die abgerufene Ressource erfüllen muss.
 - [HTTP Access-Control-Allow-Origin](/de/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)
-  - : Der **`Access-Control-Allow-Origin`**-Antwort-Header gibt an, ob die Antwort mit dem anfordernden Code vom angegebenen {{Glossary("origin", "Ursprung")}} geteilt werden kann.
+  - : Der **`Access-Control-Allow-Origin`**-Antwortheader gibt an, ob die Antwort mit anforderndem Code aus dem angegebenen {{Glossary("origin", "Ursprung")}} geteilt werden kann.
 - [HTTP X-Content-Type-Options](/de/docs/Web/HTTP/Headers/X-Content-Type-Options)
-  - : Der **`X-Content-Type-Options`** Antwort-Header ist ein Marker, der vom Server verwendet wird, um anzugeben, dass die [MIME-Typen](/de/docs/Web/HTTP/MIME_types), die in den {{HTTPHeader("Content-Type")}}-Headern angekündigt werden, nicht geändert werden dürfen und befolgt werden müssen. Dieser Header ist ein Weg, um [MIME-Typen-Sniffing](/de/docs/Web/HTTP/MIME_types#mime_sniffing) zu vermeiden, oder mit anderen Worten, anzugeben, dass die MIME-Typen bewusst konfiguriert sind.
+  - : Der **`X-Content-Type-Options`**-Antwortheader ist ein Marker, der vom Server verwendet wird, um anzuzeigen, dass die in den {{HTTPHeader("Content-Type")}}-Headers angegebenen [MIME-Typen](/de/docs/Web/HTTP/MIME_types) nicht geändert werden dürfen und beachtet werden müssen. Dieser Header ist eine Möglichkeit, sich vom [MIME-Typ-Riechen](/de/docs/Web/HTTP/MIME_types#mime_sniffing) abzumelden, oder, mit anderen Worten, anzugeben, dass die MIME-Typen absichtlich konfiguriert sind.
 
-### Formulareingaben sanitär behandeln
+### Formularinput bereinigen
 
-Als allgemeine Regel gilt, dass man nichts vertrauen sollte, was Nutzer in Formulare eingeben. Das Ausfüllen von Online-Formularen ist kompliziert und mühsam, und es ist leicht für Nutzer, falsche Daten oder Daten im falschen Format einzugeben. Darüber hinaus sind böswillige Personen äußerst geschickt darin, spezifische Zeichenfolgen ausführbaren Codes in Formularfelder einzugeben (zum Beispiel SQL oder JavaScript). Wenn Sie nicht sorgfältig mit solchen Eingaben umgehen, könnten sie schädlichen Code auf Ihrer Seite ausführen oder Ihre Datenbanken löschen. Siehe [SQL-Injection](/de/docs/Learn/Server-side/First_steps/Website_security#sql_injection) für ein gutes Beispiel, wie dies geschehen könnte.
+Als allgemeine Regel sollten Sie nichts, was Benutzer in Formulare eingeben, als vertrauenswürdig betrachten. Das Ausfüllen von Formularen online ist kompliziert und mühsam, und es ist einfach für Benutzer, falsche Daten oder Daten im falschen Format einzugeben. Darüber hinaus sind bösartige Benutzer geschickt darin, bestimmte Zeichenfolgen ausführbaren Codes in Formularfelder einzugeben (zum Beispiel SQL oder JavaScript). Wenn Sie bei der Behandlung solcher Eingaben nicht vorsichtig sind, könnten sie entweder schädlichen Code auf Ihrer Seite ausführen oder Ihre Datenbanken löschen. Ein gutes Beispiel dafür, wie dies geschehen könnte, finden Sie unter [SQL-Injection](/de/docs/Learn/Server-side/First_steps/Website_security#sql_injection).
 
-Um sich davor zu schützen, sollten Sie die in Ihre Formulare eingegebenen Daten gründlich sanieren:
+Zum Schutz dagegen sollten Sie die in Ihre Formulare eingegebenen Daten gründlich bereinigen:
 
-- Sie sollten eine clientseitige Validierung implementieren, um Nutzer zu informieren, wenn sie Daten im falschen Format eingegeben haben. Dies können Sie mit integrierten HTML-Formularvalidierungsfunktionen tun, oder Sie können Ihren eigenen Validierungscode schreiben. Weitere Informationen finden Sie unter [Clientseitige Formularvalidierung](/de/docs/Learn/Forms/Form_validation).
-- Sie sollten eine Ausgabecodierung verwenden, wenn Sie Benutzereingaben in einer Anwendungs-UI anzeigen, um die Daten sicher genau so anzuzeigen, wie ein Nutzer sie eingegeben hat und zu verhindern, dass sie als Code ausgeführt werden. Weitere Informationen finden Sie unter [Ausgabecodierung](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding).
+- Implementieren Sie clientseitige Validierung, um Benutzer zu informieren, wenn sie Daten im falschen Format eingegeben haben. Sie können dies mithilfe integrierter HTML-Formularvalidierungsfunktionen tun, oder Sie schreiben Ihre eigene Validierung. Weitere Informationen finden Sie unter [Clientseitige Formularvalidierung](/de/docs/Learn/Forms/Form_validation).
+- Verwenden Sie eine Ausgabekodierung, wenn Sie Benutzereingaben in einer Anwendungs-UI anzeigen, um eingegebene Daten sicher genau so anzuzeigen, wie ein Benutzer sie eingegeben hat, und zu vermeiden, dass sie als Code ausgeführt werden. Weitere Informationen finden Sie unter [Ausgabekodierung](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding).
 
-Sie können sich nicht allein auf die clientseitige Validierung verlassen, um Sicherheit zu gewährleisten — sie sollte mit einer serverseitigen Validierung kombiniert werden. Die clientseitige Validierung verbessert die Benutzererfahrung, indem sie eine sofortige Validierungsrückmeldung gibt, ohne auf eine Rückrunde zum Server warten zu müssen. Die clientseitige Validierung kann jedoch leicht von einer böswilligen Partei umgangen werden (zum Beispiel durch das Deaktivieren von JavaScript im Browser, um JavaScript-basierte Validierung zu umgehen).
+Allein auf klientseitige Validierung kann man sich nicht zur Sicherheit verlassen — diese sollte mit serverseitiger Validierung kombiniert werden. Klientseitige Validierung verbessert die Benutzererfahrung und liefert sofortiges Feedback zur Validierung, ohne auf eine Rundreise zum Server warten zu müssen. Allerdings ist es für einen böswilligen Benutzer einfach, die klientseitige Validierung zu umgehen (zum Beispiel, indem er JavaScript im Browser ausschaltet, um Validierungen auf JavaScript-Basis zu umgehen).
 
-Jedes angesehene serverseitige Framework bietet Funktionalitäten zur Validierung von Formularübermittlungen. Zudem ist es eine gängige Best Practice, spezielle Zeichen, die Teil der ausführbaren Syntax sind, zu entwerten. Dadurch wird eingegebener Code nicht mehr ausführbar und als Klartext behandelt.
+Jedes hochwertige serverseitige Framework wird Funktionen zur Verfügung stellen, um Formulareingaben zu validieren. Eine gängige bewährte Praxis ist darüber hinaus, alle Sonderzeichen, die Teil einer ausführbaren Syntax sind, zu maskieren und so jeden eingegebenen Code nicht mehr ausführbar und als reinen Text zu behandeln.
 
-### Schutz gegen Clickjacking
+### Schutz vor Clickjacking
 
-Bei einem {{Glossary("Clickjacking", "Clickjacking")}} Angriff wird ein Benutzer dazu gebracht, auf ein UI-Element zu klicken, das eine andere Aktion ausführt, als der Benutzer erwartet, was oft dazu führt, dass die vertraulichen Informationen des Benutzers an einen böswilligen Dritten weitergegeben werden. Dieses Risiko ist bei eingebetteten Drittinhalten inhärent, daher sollten Sie sicherstellen, dass Sie dem, was in Ihre Site eingebettet wird, vertrauen. Seien Sie sich außerdem bewusst, dass Clickjacking mit Phishing-Techniken kombiniert werden kann. Sie können im vorherigen Abschnitt [Benutzeridentität schützen und Logins verwalten](#schützen_sie_die_benutzeridentität_und_verwalten_sie_logins) über Phishing lesen.
+Bei einem [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking)-Angriff wird ein Benutzer dazu verleitet, auf ein UI-Element zu klicken, das eine andere Aktion ausführt, als der Benutzer erwartet, was oft dazu führt, dass vertrauliche Informationen des Benutzers an einen böswilligen Dritten weitergegeben werden. Dieses Risiko besteht bei eingebetteten Drittanbieterinhalten, daher stellen Sie sicher, dass Sie dem vertrauen, was auf Ihrer Seite eingebettet wird. Außerdem sollten Sie beachten, dass Clickjacking mit Phishing-Techniken kombiniert werden kann. Sie können über Phishing im vorherigen Abschnitt [Benutzeridentität schützen und Anmeldungen verwalten](#benutzeridentität_schützen_und_anmeldungen_verwalten) lesen.
 
-Die folgenden Funktionen können helfen, sich gegen Clickjacking zu schützen:
+Die folgenden Funktionen können helfen, sich gegen Clickjacking zu verteidigen:
 
 - [HTTP X-Frame-Options](/de/docs/Web/HTTP/Headers/X-Frame-Options)
-  - : Der **`X-Frame-Options`** [HTTP](/de/docs/Web/HTTP)-Antwort-Header kann verwendet werden, um anzugeben, ob ein Browser erlauben sollte, eine Seite in einem [`<frame>`](/de/docs/Web/HTML/Element/frame), [`<iframe>`](/de/docs/Web/HTML/Element/iframe), [`<embed>`](/de/docs/Web/HTML/Element/embed) oder [`<object>`](/de/docs/Web/HTML/Element/object) zu rendern. Websites können dies verwenden, um sich vor {{Glossary("Clickjacking", "Clickjacking")}}-Angriffen zu schützen, indem sie sicherstellen, dass ihre Inhalte nicht in andere Websites eingebettet werden.
+  - : Der **`X-Frame-Options`** [HTTP](/de/docs/Web/HTTP)-Antwortheader kann verwendet werden, um anzugeben, ob ein Browser eine Seite in einem [`<frame>`](/de/docs/Web/HTML/Element/frame), [`<iframe>`](/de/docs/Web/HTML/Element/iframe), [`<embed>`](/de/docs/Web/HTML/Element/embed) oder [`<object>`](/de/docs/Web/HTML/Element/object) rendern darf. Websites können dies nutzen, um Clickjacking-Angriffe zu vermeiden, indem sie sicherstellen, dass ihre Inhalte nicht in andere Seiten eingebettet werden.
 - [CSP: frame-ancestors](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors)
-  - : Die HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`frame-ancestors`** Direktive spezifiziert gültige Eltern, die eine Seite mit {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}} oder {{HTMLElement("embed")}} einbetten können.
+  - : Die HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`frame-ancestors`**-Direktive spezifiziert gültige Eltern, die eine Seite mit {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}} oder {{HTMLElement("embed")}} einbetten dürfen.
 
-## Praktische Sicherheitsimplementierungsleitfäden
+## Praktische Leitfäden zur Sicherheitsimplementierung
 
-Um umfassende Anleitungen zur effektiven Implementierung von Sicherheitsfunktionen auf Websites zu erhalten und sicherzustellen, dass Sie Best Practices befolgen, siehe unser Satz von [Praktische Sicherheitsimplementierungsleitfäden](/de/docs/Web/Security/Practical_implementation_guides).
+Um umfassende Anleitungen zur effektiven Implementierung von Sicherheitsfunktionen auf Websites zu erhalten und sicherzustellen, dass Sie den bewährten Praktiken folgen, sehen Sie sich unser Set von [Praktischen Leitfäden zur Sicherheitsimplementierung](/de/docs/Web/Security/Practical_implementation_guides) an.
 
-Einige dieser Leitfäden stehen in direktem Zusammenhang mit dem [HTTP Observatory](/en-US/observatory)-Tool. Observatory führt Sicherheitsaudits auf einer Website durch und liefert eine Bewertung und Punktzahl zusammen mit Empfehlungen zur Behebung festgestellter Sicherheitsprobleme. Diese Leitfäden erklären, wie man Sicherheitsprobleme löst, die von den MDN Observatory-Tests aufgedeckt wurden: Das Tool verlinkt zum relevanten Leitfaden für jedes Problem und hilft Ihnen auf dem Weg zu einer effektiven Lösung. Interessanterweise verwenden Mozillas interne Entwicklerteams diese Anleitung bei der Implementierung von Websites, um sicherzustellen, dass Sicherheitsbest-Practices angewendet werden.
+Einige dieser Leitfäden stehen in direktem Zusammenhang mit dem [HTTP Observatory](/en-US/observatory)-Tool. Observatory führt Sicherheitsprüfungen auf einer Website durch und liefert zusammen mit Empfehlungen zur Behebung der gefundenen Sicherheitsprobleme eine Bewertung und Punktzahl. Diese Leitfäden erklären, wie man die bei den MDN Observatory-Tests aufgedeckten Probleme löst: Das Tool verweist für jedes Problem auf den entsprechenden Leitfaden, der Ihnen hilft, eine effektive Lösung zu finden. Interessanterweise verwenden Mozillas interne Entwicklerteams diese Anleitung bei der Implementierung von Websites, um sicherzustellen, dass die besten Sicherheitspraktiken angewendet werden.
 
 ## Siehe auch
 
 - [Privatsphäre im Web](/de/docs/Web/Privacy)
-- [Lernen: Website-Sicherheit](/de/docs/Learn/Server-side/First_steps/Website_security)
-- [Mozilla Security Blog](https://blog.mozilla.org/security/)
+- [Lernbereich: Websitesicherheit](/de/docs/Learn/Server-side/First_steps/Website_security)
+- [Mozilla Sicherheitsblog](https://blog.mozilla.org/security/)
 - [OWASP Cheat Sheet Serie](https://cheatsheetseries.owasp.org/index.html)
 
 <section id="Quick_links">
diff --git a/files/de/web/security/practical_implementation_guides/clickjacking/index.md b/files/de/web/security/practical_implementation_guides/clickjacking/index.md
index 4befa40a1..c6c52d7be 100644
--- a/files/de/web/security/practical_implementation_guides/clickjacking/index.md
+++ b/files/de/web/security/practical_implementation_guides/clickjacking/index.md
@@ -1,60 +1,60 @@
 ---
-title: Clickjacking-Prävention
+title: Clickjacking-Schutz
 slug: Web/Security/Practical_implementation_guides/Clickjacking
 l10n:
-  sourceCommit: 857c6f9e7f1a847e7d3466b0d047159f7b345991
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{QuickLinksWithSubpages("/de/docs/Web/Security")}}
 
-Die [Content Security Policy](/de/docs/Web/HTTP/CSP) Richtlinie [`frame-ancestors`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) und der [`X-Frame-Options`](/de/docs/Web/HTTP/Headers/X-Frame-Options) Header bieten Kontrolle darüber, wie Ihre Website innerhalb eines {{htmlelement("iframe")}} auf einer anderen Website eingebettet werden kann. Diese Funktionen helfen, Clickjacking zu verhindern.
+Die [Content Security Policy](/de/docs/Web/HTTP/CSP)- Direktive [`frame-ancestors`](/de/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) und der Header [`X-Frame-Options`](/de/docs/Web/HTTP/Headers/X-Frame-Options) bieten Kontrolle darüber, wie Ihre Website innerhalb eines {{htmlelement("iframe")}} auf einer anderen Website eingebettet werden kann. Diese Funktionen helfen, Clickjacking zu verhindern.
 
 ## Problem
 
-{{Glossary("Clickjacking", "Clickjacking")}} ist ein Angriff, bei dem bösartige Websites Benutzer dazu verleiten, auf Links oder UI-Elemente zu klicken, indem sie diese so erscheinen lassen, als würden sie zu einer vertrauenswürdigen Website gehören, die dem Benutzer bekannt ist. Dies geschieht in der Regel, indem ein Teil oder die gesamte vertrauenswürdige Website über ein `<iframe>` in die bösartige Website eingebettet wird. Ein Button, Link oder ein anderes UI-Element wird dann über diesem Inhalt positioniert, sodass der Benutzer denkt, er würde mit der vertrauenswürdigen Website interagieren, während er in Wirklichkeit mit der bösartigen Website interagiert.
+[Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) ist ein Angriff, bei dem bösartige Websites Benutzer dazu verleiten, auf Links oder UI-Elemente zu klicken, indem sie so erscheinen, als wären sie von einer vertrauten Website, die der Benutzer kennt. Dies wird normalerweise erreicht, indem ein Teil oder die gesamte vertrauenswürdige Website über ein `<iframe>` in die bösartige Website eingebettet wird. Ein Button, Link oder ein anderes UI-Feature wird dann über diesem Inhalt positioniert, um den Benutzer glauben zu lassen, dass er mit seiner vertrauten Website interagiert, während er tatsächlich mit der bösartigen Website interagiert.
 
 ## Lösung
 
 Verwenden Sie die HTTP-Header wie erforderlich:
 
-- `Content-Security-Policy: frame-ancestors` wird bevorzugt, da es eine feinere Kontrolle über die Website-Einbettung bietet. Es wird jedoch nicht in IE11 und früheren Versionen, vor-Chromium-Versionen von Edge, Safari 9.1 (Desktop) und Safari 9.2 (iOS) unterstützt.
-- `X-Frame-Options` ist weniger granular, aber es wird in der älteren Browsersammlung unterstützt, die oben aufgeführt ist.
+- `Content-Security-Policy: frame-ancestors` wird bevorzugt, da es eine granulare Kontrolle über die Einbettung von Websites bietet. Es wird jedoch nicht in IE11 und früher, vor der Chromium-Version von Edge, Safari 9.1 (Desktop) und Safari 9.2 (iOS) unterstützt.
+- `X-Frame-Options` ist weniger granular, wird aber in dem oben genannten älteren Browser-Set unterstützt.
 
-Es wird empfohlen, beide zu verwenden, es sei denn, Sie wissen, dass Sie keine Unterstützung für die ältere Browsersammlung benötigen.
+Die Empfehlung ist, beide zu verwenden, es sei denn, Sie wissen, dass Sie keine Unterstützung für das ältere Browser-Set benötigen.
 
-Sie sollten alle Versuche, Ihre Website einzubetten, ablehnen, es sei denn, dies ist wirklich notwendig. Wenn eine Einbettung erforderlich ist, geben Sie die minimal notwendige Einbettungserlaubnis. Websites, die die Möglichkeit benötigen, in einem `<iframe>` eingebettet zu werden, müssen JavaScript-Verteidigungen und eine robuste {{HTTPHeader("Content-Security-Policy")}} verwenden, um Clickjacking von bösartigen Ursprüngen zu verhindern. [`Window.confirm()`](/de/docs/Web/API/Window/confirm) kann als Teil Ihrer JavaScript-Verteidigungen verwendet werden, um den Benutzer über die Aktion zu informieren, die er ausführen wird: Siehe [`window.confirm()` Protection](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html#windowconfirm-protection).
+Sie sollten alle Versuche, Ihre Website einzubetten, ablehnen, es sei denn, es ist wirklich erforderlich. Wenn eine Einbettung erforderlich ist, sollten Sie das minimale Erlaubnisniveau bereitstellen, das notwendig ist. Websites, die die Fähigkeit erfordern, in einem `<iframe>` eingebettet zu werden, müssen JavaScript-Abwehrmechanismen und eine robuste {{HTTPHeader("Content-Security-Policy")}} verwenden, um Clickjacking von bösartigen Ursprüngen zu verhindern. [`Window.confirm()`](/de/docs/Web/API/Window/confirm) kann als Teil Ihrer JavaScript-Abwehrmechanismen verwendet werden, um den Benutzer über die Aktion zu informieren, die er ausführt: Siehe [`window.confirm()` Protection](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html#windowconfirm-protection).
 
 Die entsprechenden Optionen für jede Einstellung sind wie folgt:
 
-| CSP-Wert                              | `X-Frame-Options` Wert          | Beschreibung                                                 |
-| ------------------------------------- | ------------------------------- | ------------------------------------------------------------ |
-| `frame-ancestors 'none'`              | `DENY`                          | Lehnen Sie alle Einbettungsversuche ab.                      |
-| `frame-ancestors 'self'`              | `SAMEORIGIN`                    | Erlauben Sie nur gleiche Ursprungs-Einbettungsversuche.      |
-| `frame-ancestors https://example.org` | `ALLOWFROM https://example.org` | Erlauben Sie Einbettungsversuche von der angegebenen Domain. |
+| CSP-Wert                              | `X-Frame-Options` Wert          | Beschreibung                                             |
+| ------------------------------------- | ------------------------------- | -------------------------------------------------------- |
+| `frame-ancestors 'none'`              | `DENY`                          | Alle Einbettungsversuche ablehnen.                       |
+| `frame-ancestors 'self'`              | `SAMEORIGIN`                    | Nur gleichherige Einbettungsversuche zulassen.           |
+| `frame-ancestors https://example.org` | `ALLOWFROM https://example.org` | Einbettungsversuche von der angegebenen Domain zulassen. |
 
 > [!NOTE]
-> Die Syntax `X-Frame-Options: ALLOWFROM https://example.org` ist veraltet, und die meisten Browser ignorieren sie. Es wird empfohlen, stattdessen `DENY` zu setzen und/oder sich auf das CSP-Äquivalent zu verlassen.
+> Die Syntax `X-Frame-Options: ALLOWFROM https://example.org` ist veraltet, und die meisten Browser ignorieren sie. Es wird empfohlen, in solchen Fällen `DENY` zu setzen und/oder sich auf das CSP-Äquivalent zu verlassen.
 
 > [!NOTE]
-> Das Setzen von Cookies mit der [`SameSite`](/de/docs/Web/Security/Practical_implementation_guides/Cookies#samesite) Direktive ist auch nützlich in Clickjacking-Fällen, die darauf angewiesen sind, dass der Benutzer authentifiziert ist.
+> Das Setzen von Cookies mit der [`SameSite`](/de/docs/Web/Security/Practical_implementation_guides/Cookies#samesite)-Direktive ist ebenfalls nützlich in Clickjacking-Fällen, die davon abhängen, dass der Benutzer authentifiziert ist.
 
 ## Beispiele
 
-Verhindern Sie die Einbettung der Website, indem Sie `X-Frame-Options` und CSP verwenden:
+Blockieren Sie die Einbettung der Website, indem Sie `X-Frame-Options` und CSP verwenden:
 
 ```http
 Content-Security-Policy: frame-ancestors 'none'
 X-Frame-Options: DENY
 ```
 
-Erlauben Sie, dass die Website nur auf Seiten mit demselben Ursprung eingebettet wird:
+Erlauben Sie, dass die Website nur auf gleichherigen Seiten eingebettet wird:
 
 ```http
 Content-Security-Policy: frame-ancestors 'self'
 X-Frame-Options: SAMEORIGIN
 ```
 
-Erlauben Sie nur `example.org`, die Website einzubetten:
+Nur `example.org` darf die Website einbetten:
 
 ```http
 Content-Security-Policy: frame-ancestors https://example.org
@@ -65,4 +65,4 @@ X-Frame-Options: DENY
 ## Siehe auch
 
 - [Clickjacking Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) auf `owasp.org`
-- [Clickjacking-Angriffe und wie man sie verhindert](https://auth0.com/blog/preventing-clickjacking-attacks/) auf `auth0.com` (2020)
+- [Clickjacking Attacks and How to Prevent Them](https://auth0.com/blog/preventing-clickjacking-attacks/) auf `auth0.com` (2020)
diff --git a/files/de/web/security/practical_implementation_guides/cookies/index.md b/files/de/web/security/practical_implementation_guides/cookies/index.md
index 9c3ca8586..fa1ecce92 100644
--- a/files/de/web/security/practical_implementation_guides/cookies/index.md
+++ b/files/de/web/security/practical_implementation_guides/cookies/index.md
@@ -1,72 +1,72 @@
 ---
-title: Sicheres Cookie-Konfiguration
+title: Sichere Cookie-Konfiguration
 slug: Web/Security/Practical_implementation_guides/Cookies
 l10n:
-  sourceCommit: 58e3ead4baff54bd562049b4a70f5b7df368f242
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{QuickLinksWithSubpages("/de/docs/Web/Security")}}
 
-Begrenzen Sie den Zugriff auf Cookies so weit wie möglich.
+Beschränken Sie den Zugriff auf Cookies so weit wie möglich.
 
 ## Problem
 
-Cookies enthalten häufig Sitzungs-IDs oder andere sensible Informationen. Unbefugter Zugriff auf Cookies kann daher eine Vielzahl von Problemen verursachen, einschließlich [Datenschutz](/de/docs/Web/Privacy)problemen, ({{Glossary("Cross-site_scripting", "Cross-Site Scripting (XSS)")}})-Angriffen, Cross-Site Request Forgery ({{Glossary("CSRF", "CSRF")}})-Angriffen und mehr.
+Cookies enthalten oft Sitzungskennungen oder andere sensible Informationen. Unbefugter Zugriff auf Cookies kann daher eine Vielzahl von Problemen verursachen, einschließlich [Datenschutz](/de/docs/Web/Privacy)-Problemen, ({{Glossary("Cross-site_scripting", "Cross-Site Scripting (XSS)")}}) Angriffen, Cross-Site Request Forgery ({{Glossary("CSRF", "CSRF")}}) Angriffen und mehr.
 
 ## Lösung
 
-Um die Anfälligkeit Ihrer Website für Cookie-Schwachstellen zu minimieren, sollten Sie den Zugriff auf Cookies so weit wie möglich beschränken. Dies kann durch eine sinnvolle Verwendung der folgenden Direktiven des [`Set-Cookie`](/de/docs/Web/HTTP/Headers/Set-Cookie)-Headers geschehen:
+Um die Anfälligkeit von Cookies auf Ihrer Website zu minimieren, sollten Sie den Zugriff auf Cookies so weit wie möglich einschränken. Dies kann durch die sinnvolle Verwendung der folgenden Direktiven des [`Set-Cookie`](/de/docs/Web/HTTP/Headers/Set-Cookie) Headers erfolgen:
 
 - `Name`
-  - : Cookienamen sollten mit entweder `__Secure-` oder `__Host-` versehen werden, um zu verhindern, dass Cookies von unsicheren Quellen überschrieben werden.
-    - Verwenden Sie `__Host-` für alle Cookies, die nur auf einer bestimmten Domain benötigt werden (keine Subdomains), bei der `Path` auf `/` gesetzt ist.
+  - : Cookienamen sollten mit `__Secure-` oder `__Host-` beginnen, um zu verhindern, dass Cookies durch unsichere Quellen überschrieben werden.
+    - Verwenden Sie `__Host-` für alle Cookies, die nur für eine bestimmte Domain (ohne Subdomains) benötigt werden, bei der `Path` auf `/` gesetzt ist.
     - Verwenden Sie `__Secure-` für alle anderen Cookies, die von sicheren Ursprüngen ({{Glossary("HTTPS", "HTTPS")}}) gesendet werden.
 - `Secure`
-  - : Alle Cookies müssen mit der Direktive `Secure` gesetzt werden, was anzeigt, dass sie nur über HTTPS gesendet werden sollten. [HTTP Strict Transport Security](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security_implementation) (HSTS) kann ebenfalls verwendet werden, um die Übertragung über HTTP zu verhindern, aber idealerweise sollte `Secure` auch auf Cookies gesetzt werden.
+  - : Alle Cookies müssen mit der `Secure`-Direktive gesetzt werden, was anzeigt, dass sie nur über HTTPS gesendet werden sollten. [HTTP Strict Transport Security](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security_implementation) (HSTS) kann ebenfalls verwendet werden, um die Übertragung über HTTP zu verhindern, aber idealerweise sollte `Secure` auch bei Cookies gesetzt sein.
 - `HttpOnly`
-  - : Cookies, die keinen Zugriff von JavaScript erfordern, sollten die Direktive `HttpOnly` haben, um den Zugriff zu blockieren, zum Beispiel von [`Document.cookie`](/de/docs/Web/API/Document/cookie). Es ist besonders wichtig, dass Sitzungs-IDs keinen JavaScript-Zugang haben, um Angriffe wie CSRF zu verhindern.
+  - : Cookies, die keinen Zugriff von JavaScript erfordern, sollten die `HttpOnly`-Direktive gesetzt haben, um den Zugriff zu blockieren, wie zum Beispiel von [`Document.cookie`](/de/docs/Web/API/Document/cookie). Es ist besonders wichtig, dass Sitzungskennungen keinen JavaScript-Zugriff haben, um Angriffe wie CSRF zu verhindern.
 - `Expires` und `Max-Age`
-  - : Cookies sollten ablaufen, sobald sie nicht mehr benötigt werden. Sitzungs-IDs im Besonderen sollten so schnell wie möglich ablaufen. `Expires` wird bevorzugt, es sei denn, Sie müssen IE < 8 unterstützen, in diesem Fall verwenden Sie `Max-Age`.
+  - : Cookies sollten ablaufen, sobald sie nicht mehr benötigt werden. Insbesondere Sitzungskennungen sollten so schnell wie möglich ablaufen. `Expires` wird bevorzugt, es sei denn, Sie müssen IE < 8 unterstützen, in diesem Fall verwenden Sie `Max-Age`.
     - `Expires`: Setzt ein absolutes Ablaufdatum für ein gegebenes Cookie.
     - `Max-Age`: Setzt ein relatives Ablaufdatum für ein gegebenes Cookie.
-      > **Hinweis:** `Expires` ist länger verfügbar als `Max-Age`; jedoch ist `Max-Age` weniger fehleranfällig und hat Vorrang, wenn beide gesetzt sind. Der Grund dafür ist, dass beim Setzen eines `Expires`-Datums und einer Uhrzeit diese relativ zu dem Client sind, auf dem das Cookie gesetzt wird. Wenn der Server auf eine andere Zeit eingestellt ist, könnte dies zu Fehlern führen.
+      > **Hinweis:** `Expires` ist länger verfügbar als `Max-Age`; jedoch ist `Max-Age` weniger fehleranfällig und hat Vorrang, wenn beide gesetzt sind. Der Grund dafür ist, dass beim Setzen eines `Expires`-Datums und einer Uhrzeit diese relativ zum Client sind, auf dem das Cookie gesetzt wird. Wenn der Server auf eine andere Zeit eingestellt ist, kann dies zu Fehlern führen.
 - `Domain`
-  - : Cookies sollten nur dann eine `Domain` gesetzt haben, wenn sie auf anderen Domains zugänglich sein müssen; dies sollte auf die restriktivste Domain möglich gesetzt werden.
+  - : Cookies sollten nur ein `Domain`-Attribut haben, wenn sie auf anderen Domains zugänglich sein müssen; dies sollte auf die restriktivste Domain gesetzt werden.
 - `Path`
   - : Cookies sollten auf den restriktivsten `Path` gesetzt werden.
 - `SameSite`
 
-  - : Verbieten Sie das Senden von Cookies über Cross-Origin-Anfragen (z. B. von {{htmlelement("img")}}-Elementen) mithilfe von `SameSite`. Sie sollten einen der folgenden zwei Werte verwenden:
+  - : Verbieten Sie das Senden von Cookies über Cross-Origin-Anfragen (zum Beispiel von {{htmlelement("img")}}-Elementen) mithilfe von `SameSite`. Sie sollten einen der folgenden beiden Werte verwenden:
 
-    - `SameSite=Strict`: Senden Sie das Cookie nur in gleichen Site-Kontexten (Navigations- und andere Anfragen). Cookies werden bei Cross-Site-Anfragen (z. B. Einbetten von Bildern oder anderen Ressourcen von anderen Seiten) und Cross-Site-Navigation (z. B. wenn ein Link von einer anderen Webseite gefolgt wird) ausgelassen. Dies ist eine sehr strikte Einstellung, bietet jedoch starken [CSRF](/de/docs/Web/Security/Practical_implementation_guides/CSRF_prevention)-Schutz, also verwenden Sie diesen Wert, wenn möglich.
-    - `SameSite=Lax`: Senden Sie das Cookie bei gleichen Site-Anfragen und bei der Navigation _zu_ Ihrer Website. Dies sollte verwendet werden, wenn `Strict` zu restriktiv ist.
+    - `SameSite=Strict`: Senden Sie das Cookie nur in Same-Site-Kontexten (Navigationen und andere Anfragen). Cookies werden in Cross-Site-Anfragen (z. B. Einbetten von Bildern oder anderen Ressourcen von anderen Websites) und in Cross-Site-Navigation (z. B. beim Folgen eines Links von einer anderen Webseite) ausgelassen. Dies ist eine sehr strikte Einstellung, bietet jedoch einen starken Schutz gegen [CSRF](/de/docs/Web/Security/Practical_implementation_guides/CSRF_prevention), nutzen Sie diesen Wert, wenn möglich.
+    - `SameSite=Lax`: Senden Sie das Cookie in Same-Site-Anfragen und beim Navigieren _zu_ Ihrer Website. Dies sollte verwendet werden, wenn `Strict` zu restriktiv ist.
 
-    Beide oben genannten Werte sind nützlich zum Schutz vor {{Glossary("Clickjacking", "Clickjacking")}}-Angriffen in Fällen, die davon abhängen, dass der Benutzer authentifiziert ist.
+    Beide der oben genannten Werte sind nützlich, um [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) Angriffe in Fällen zu verhindern, die davon abhängen, dass der Benutzer authentifiziert ist.
 
     > [!NOTE]
-    > In der Theorie sollte `SameSite=Strict` nützlicher sein, als es in der Praxis ist. Es führt oft zu Navigationsabbrüchen — zum Beispiel, wenn Benutzer auf einen Link zu einer Website klicken, auf der sie bereits eingeloggt sind (d. h. ein gültiges Sitzungs-Cookie gesetzt ist), erscheint es, als wären sie nicht eingeloggt, weil der Browser das Sitzungs-Cookie absichtlich ausgelassen hat. Der beste Mittelweg ist, `SameSite=Strict` nur bei Tokens zu verwenden, bei denen CSRF ein Problem darstellt, oder `SameSite=Strict` überall zu verwenden, aber die Seite neu zu laden und mit JavaScript eine Cookie-Überprüfung durchzuführen, wenn ein Hinweis darauf besteht, dass der Benutzer eingeloggt ist, aber erforderliche Cookies nicht gesendet werden.
+    > In der Theorie sollte `SameSite=Strict` nützlicher sein, als es in der Praxis ist. Es bricht oft Navigationen – zum Beispiel, wenn Benutzer auf einen Link zu einer Website klicken, auf der sie bereits eingeloggt sind (d. h. ein gültiges Sitzungscookie ist gesetzt), scheinen sie nicht eingeloggt zu sein, weil der Browser das Sitzungscookie absichtlich nicht gesendet hat. Der beste Kompromiss ist die Verwendung von `SameSite=Strict` nur bei Tokens, bei denen CSRF ein Problem darstellt, oder die Verwendung von `SameSite=Strict` überall, jedoch die Seite neu zu laden und einen Cookie-Check in JavaScript durchzuführen, wenn es einen Hinweis darauf gibt, dass der Benutzer eingeloggt ist, aber erforderliche Cookies nicht gesendet werden.
 
 ## Beispiele
 
-Setzen Sie ein Sitzungs-ID-Cookie, das nur auf dem aktuellen Host zugänglich ist und abläuft, wenn der Benutzer seinen Browser schließt:
+Ein Sitzungkennung-Cookie setzen, das nur auf dem aktuellen Host zugänglich ist und abläuft, wenn der Benutzer den Browser schließt:
 
 ```http
 Set-Cookie: MOZSESSIONID=980e5da39d4b472b9f504cac9; Path=/; Secure; HttpOnly
 ```
 
-Verwenden Sie das Präfix `__Secure-`, um eine Sitzungs-ID für alle `example.org`-Seiten zu setzen, die nach 30 Tagen abläuft. Dieses Cookie wird nicht über Cross-Origin gesendet, aber beim Navigieren zu einer beliebigen Seite von einer anderen Website:
+Verwenden Sie das `__Secure-` Präfix, um eine Sitzungkennung für alle `example.org`-Seiten zu setzen, die nach 30 Tagen abläuft. Dieses Cookie wird nicht cross-origin gesendet, aber beim Navigieren zu einer beliebigen Seite von einer anderen Seite:
 
 ```http
 Set-Cookie: __Secure-MOZSESSIONID=7307d70a86bd4ab5a00499762; Max-Age=2592000; Domain=example.org; Path=/; Secure; HttpOnly; SameSite=Lax
 ```
 
-Setzen Sie ein langlebiges Cookie für den aktuellen Host, das von JavaScript zugänglich ist, wenn der Benutzer die Nutzungsbedingungen akzeptiert. Dieses Cookie wird gesendet, wenn Sie von einer anderen Website zu Ihrer Seite navigieren, z. B. durch Klicken auf einen Link:
+Setzen Sie ein langlebiges Cookie für den aktuellen Host, das durch JavaScript zugänglich ist, wenn der Benutzer die Nutzungsbedingungen akzeptiert. Dieses Cookie wird beim Navigieren zu Ihrer Website von einer anderen Website gesendet, zum Beispiel durch Klicken auf einen Link:
 
 ```http
 Set-Cookie: __Host-ACCEPTEDTOS=true; Expires=Fri, 31 Dec 9999 23:59:59 GMT; Path=/; Secure; SameSite=Lax
 ```
 
-Verwenden Sie eine Sitzungs-ID für eine sichere (HTTPS) Seite. Sie wird nicht von Cross-Origin-Anfragen gesendet, noch beim Navigieren zu Ihrer Seite von einer anderen Website. In Verbindung mit anderen Anti-CSRF-Maßnahmen bietet dies eine sehr starke Verteidigung für Ihre Seite gegen CSRF-Angriffe:
+Verwenden Sie eine Sitzungkennung für eine sichere (HTTPS) Website. Sie wird nicht von cross-origin Anfragen gesendet, noch beim Navigieren zu Ihrer Website von einer anderen Website. In Verbindung mit anderen Anti-CSRF-Maßnahmen bietet dies einen sehr starken Schutz Ihrer Website vor CSRF-Angriffen:
 
 ```http
 Set-Cookie: __Host-BMOSESSIONID=YnVnemlsbGE=; Max-Age=2592000; Path=/; Secure; HttpOnly; SameSite=Strict
@@ -75,6 +75,6 @@ Set-Cookie: __Host-BMOSESSIONID=YnVnemlsbGE=; Max-Age=2592000; Path=/; Secure; H
 ## Siehe auch
 
 - [Verwendung von HTTP-Cookies](/de/docs/Web/HTTP/Cookies)
-- [Cookies von Drittanbietern](/de/docs/Web/Privacy/Third-party_cookies)
+- [Drittanbieter-Cookies](/de/docs/Web/Privacy/Third-party_cookies)
 - [`Document.cookie`: Sicherheit](/de/docs/Web/API/Document/cookie#security)
-- [RFC 6265 (HTTP-Cookies)](https://datatracker.ietf.org/doc/html/rfc6265) (2011)
+- [RFC 6265 (HTTP Cookies)](https://datatracker.ietf.org/doc/html/rfc6265) (2011)
diff --git a/files/de/web/security/practical_implementation_guides/index.md b/files/de/web/security/practical_implementation_guides/index.md
index 065d741d7..cb29cf34f 100644
--- a/files/de/web/security/practical_implementation_guides/index.md
+++ b/files/de/web/security/practical_implementation_guides/index.md
@@ -1,43 +1,43 @@
 ---
-title: Praktische Sicherheitsimplementierungsleitfäden
+title: Praktische Sicherheitsleitfäden zur Implementierung
 slug: Web/Security/Practical_implementation_guides
 l10n:
-  sourceCommit: 5e894978a337d4b81bd28374a4111b5e20b5398b
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{QuickLinksWithSubpages("/de/docs/Web/Security")}}
 
-Benutzer geben häufig sensible Daten auf Websites ein, wie z.B. Namen, Adressen, Passwörter und Bankdaten. Als Webentwickler ist es entscheidend, diese Informationen vor böswilligen Akteuren zu schützen, die eine Vielzahl von Exploits nutzen, um solche Informationen zu stehlen und für persönliche Zwecke zu verwenden. Der Fokus von [Web-Sicherheit](/de/docs/Web/Security) liegt darauf, Ihnen zu helfen, Ihre Website gegen diese Exploits zu schützen und die sensiblen Daten Ihrer Benutzer zu sichern.
+Benutzer geben häufig sensible Daten auf Websites ein, wie Namen, Adressen, Passwörter und Bankdaten. Als Webentwickler ist es entscheidend, diese Informationen vor böswilligen Akteuren zu schützen, die eine Vielzahl von Exploits verwenden, um solche Informationen zu stehlen und sie für persönliche Zwecke zu nutzen. Der Schwerpunkt der [Websicherheit](/de/docs/Web/Security) liegt darin, Ihnen zu helfen, Ihre Website vor diesen Exploits zu schützen und die sensiblen Daten Ihrer Benutzer zu sichern.
 
-Diese Seite listet Leitfäden auf, die Best Practices für die Implementierung von Sicherheitsfunktionen auf Websites detailliert beschreiben. Auch wenn diese Leitfäden nicht alle möglichen Sicherheitsszenarien abdecken und keine vollständige Sicherheit Ihrer Website garantieren können, wird die Befolgung der Informationen und Best Practices in diesen Leitfäden Ihre Websites deutlich sicherer machen.
+Diese Seite listet Leitfäden auf, die bewährte Methoden zur Implementierung von Sicherheitsfunktionen auf Websites detailliert beschreiben. Obwohl diese Leitfäden nicht alle möglichen Sicherheitsszenarien abdecken und die vollständige Sicherheit Ihrer Website nicht garantieren können, wird durch die Beachtung der Informationen und bewährten Methoden in diesen Leitfäden Ihre Website erheblich sicherer.
 
-## Grundlagen der Inhaltssicherheit
+## Grundlagen der Inhaltsicherheit
 
-Die meisten dieser Leitfäden stehen in direktem Zusammenhang mit dem [HTTP Observatory](/en-US/observatory) Tool. Observatory führt Sicherheitsprüfungen auf einer Website durch und bietet eine Bewertung und eine Punktzahl sowie Empfehlungen zur Behebung der gefundenen Sicherheitsprobleme. Diese Leitfäden erklären, wie man Probleme löst, die bei den HTTP Observatory Tests festgestellt werden: Das Tool verlinkt zu den relevanten Leitfäden für jedes Problem und hilft Ihnen, eine effektive Lösung zu finden. Interessanterweise verwenden Mozillas interne Entwicklerteams diese Anleitungen beim Implementieren von Websites, um sicherzustellen, dass die besten Sicherheitspraktiken angewandt werden.
+Die meisten dieser Leitfäden stehen in direktem Zusammenhang mit dem Werkzeug [HTTP Observatory](/en-US/observatory). Observatory führt Sicherheitsprüfungen auf einer Website durch und liefert eine Bewertung und Punktzahl zusammen mit Empfehlungen zur Behebung der gefundenen Sicherheitsprobleme. Diese Leitfäden erklären, wie man Probleme löst, die durch die HTTP Observatory-Tests aufgedeckt werden: Das Werkzeug verlinkt auf den jeweiligen Leitfaden für jedes Problem und hilft Ihnen bei der effektiven Lösung. Interessanterweise verwenden Mozillas interne Entwicklerteams diese Anleitungen bei der Implementierung von Websites, um sicherzustellen, dass bewährte Sicherheitspraktiken angewendet werden.
 
-Die Leitfäden in der folgenden Tabelle sind in der Reihenfolge aufgelistet, in der wir empfehlen, die beschriebenen Sicherheitsfunktionen zu implementieren. Diese Reihenfolge basiert auf einer Kombination aus der Sicherheitsauswirkung jeder Funktion und der Leichtigkeit ihrer Implementierung aus sowohl operativer als auch entwicklungsbezogener Perspektive. Die Tabelle bietet Informationen über die Auswirkungen jeder Funktion, den Schwierigkeitsgrad der Implementierung, ob sie erforderlich ist oder nicht, und eine kurze Beschreibung.
+Die Leitfäden in der folgenden Tabelle sind in der Reihenfolge aufgelistet, in der wir empfehlen, die von ihnen beschriebenen Sicherheitsfunktionen zu implementieren. Diese Reihenfolge basiert auf einer Kombination aus dem Einfluss jeder Funktion auf die Sicherheit und der Einfachheit ihrer Implementierung sowohl aus operativer als auch aus entwicklungsbezogener Perspektive. Die Tabelle bietet Informationen über die Auswirkungen jeder Funktion, die Schwierigkeit der Implementierung, ob sie erforderlich ist, und eine kurze Beschreibung.
 
-| Leitfaden                                                                                                                            | Auswirkung | Schwierigkeitsgrad | Erforderlich | Beschreibung                                                                                                                                                                                                              |
-| ------------------------------------------------------------------------------------------------------------------------------------ | ---------- | ------------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [TLS-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/TLS#tls_configuration)                                     | Mittel     | Mittel             | Ja           | Verwenden Sie die sicherste verfügbare {{Glossary("TLS", "Transport Layer Security")}} (TLS)-Konfiguration für Ihre Benutzer.                                                                                             |
-| TLS: [Ressourcenladen](/de/docs/Web/Security/Practical_implementation_guides/TLS#resource_loading)                                   | Maximal    | Niedrig            | Ja           | Laden Sie sowohl passive als auch aktive Ressourcen über HTTPS.                                                                                                                                                           |
-| TLS: [HTTP-Umleitung](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_redirection)                                    | Maximal    | Niedrig            | Ja           | Websites müssen auf HTTPS umleiten; API-Endpunkte sollten HTTP vollständig deaktivieren.                                                                                                                                  |
-| TLS: [HSTS-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security_implementation) | Hoch       | Niedrig            | Ja           | Benachrichtigen Sie Benutzeragenten, sich nur über HTTPS mit Websites zu verbinden, auch wenn das ursprünglich gewählte Schema HTTP war, indem Sie HTTP Strict Transport Security (HSTS) verwenden.                       |
-| [Verhinderung von Clickjacking](/de/docs/Web/Security/Practical_implementation_guides/Clickjacking)                                  | Hoch       | Niedrig            | Ja           | Kontrollieren Sie, wie Ihre Website innerhalb eines {{htmlelement("iframe")}} gerahmt werden kann, um {{Glossary("Clickjacking", "Clickjacking")}} zu verhindern.                                                         |
-| [Verhinderung von CSRF](/de/docs/Web/Security/Practical_implementation_guides/CSRF_prevention)                                       | Hoch       | Unbekannt          | Variiert     | Schützen Sie sich vor {{Glossary("CSRF", "Cross-site request forgery")}} (CSRF) mit `SameSite` Cookies und Anti-CSRF Tokens.                                                                                              |
-| [Sichere Cookie-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Cookies)                                        | Hoch       | Mittel             | Ja           | Setzen Sie alle Cookies so restriktiv wie möglich.                                                                                                                                                                        |
-| [CORP-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/CORP)                                                   | Hoch       | Mittel             | Ja           | Schützen Sie sich vor spekulativen Seitenkanalangriffen, indem Sie die Cross-Origin Resource Policy (CORP) verwenden.                                                                                                     |
-| [MIME-Typ-Verifizierung](/de/docs/Web/Security/Practical_implementation_guides/MIME_types)                                           | Niedrig    | Niedrig            | Nein         | Stellen Sie sicher, dass alle Ihre Websites die richtigen {{Glossary("MIME_type", "MIME-Typen")}} für alle Ressourcen setzen.                                                                                             |
-| [CSP-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/CSP)                                                     | Hoch       | Hoch               | Ja           | Bieten Sie eine feingranulare Kontrolle darüber, von wo aus Site-Ressourcen mit {{Glossary("CSP", "Content Security Policy")}} (CSP) geladen werden können.                                                               |
-| [CORS-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/CORS)                                                     | Hoch       | Niedrig            | Ja           | Definieren Sie die nicht gleichen Ursprünge, die erlaubt sind, auf den Inhalt von Seiten zuzugreifen und Ressourcen von ihnen zu laden, indem Sie {{Glossary("CORS", "Cross-Origin Resource Sharing")}} (CORS) verwenden. |
-| [Referrer-Policy-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Referrer_policy)                               | Niedrig    | Niedrig            | Ja           | Verbessern Sie die Privatsphäre von Benutzern und verhindern Sie das Leaken interner URLs über den {{httpheader("Referer")}} Header.                                                                                      |
-| [robots.txt-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Robots_txt)                                         | Niedrig    | Niedrig            | Nein         | Weisen Sie Roboter (z.B. Suchmaschinenindexer) an, wie sie sich verhalten sollen, indem Sie ihnen sagen, bestimmte Pfade auf der Website nicht zu crawlen.                                                                |
-| [SRI-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/SRI)                                                     | Niedrig    | Niedrig            | Nein         | Überprüfen Sie, dass abgerufene Ressourcen (z.B. von einem CDN) ohne unerwartete Manipulation geliefert werden, indem Sie {{Glossary("SRI", "Subresource Integrity")}} (SRI) verwenden.                                   |
+| Leitfaden                                                                                                                            | Einfluss | Schwierigkeit | Erforderlich | Beschreibung                                                                                                                                                                                                                        |
+| ------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [TLS-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/TLS#tls_configuration)                                     | Mittel   | Mittel        | Ja           | Verwenden Sie die sicherste verfügbare {{Glossary("TLS", "Transport Layer Security")}} (TLS)-Konfiguration für Ihre Benutzerbasis.                                                                                                  |
+| TLS: [Ressourcenladen](/de/docs/Web/Security/Practical_implementation_guides/TLS#resource_loading)                                   | Maximal  | Niedrig       | Ja           | Laden Sie sowohl passive als auch aktive Ressourcen über HTTPS.                                                                                                                                                                     |
+| TLS: [HTTP-Weiterleitung](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_redirection)                                | Maximal  | Niedrig       | Ja           | Websites müssen auf HTTPS umleiten; API-Endpunkte sollten HTTP vollständig deaktivieren.                                                                                                                                            |
+| TLS: [HSTS-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security_implementation) | Hoch     | Niedrig       | Ja           | Benachrichtigen Sie Benutzeragenten, sich nur über HTTPS mit Websites zu verbinden, auch wenn das ursprünglich gewählte Schema HTTP war, durch die Verwendung von HTTP Strict Transport Security (HSTS).                            |
+| [Clickjacking-Prävention](/de/docs/Web/Security/Practical_implementation_guides/Clickjacking)                                        | Hoch     | Niedrig       | Ja           | Kontrollieren Sie, wie Ihre Website innerhalb eines {{htmlelement("iframe")}} gerahmt werden darf, um [Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) zu verhindern.                                                     |
+| [CSRF-Prävention](/de/docs/Web/Security/Practical_implementation_guides/CSRF_prevention)                                             | Hoch     | Unbekannt     | Variiert     | Schützen Sie sich vor {{Glossary("CSRF", "Cross-site request forgery")}} (CSRF) durch die Verwendung von `SameSite` Cookies und Anti-CSRF-Tokens.                                                                                   |
+| [Sichere Cookie-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Cookies)                                        | Hoch     | Mittel        | Ja           | Setzen Sie alle Cookies so restriktiv wie möglich.                                                                                                                                                                                  |
+| [CORP-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/CORP)                                                   | Hoch     | Mittel        | Ja           | Schützen Sie sich vor spekulativen Seitenkanalangriffen durch Verwendung der Cross-Origin Resource Policy (CORP).                                                                                                                   |
+| [MIME-Typ-Überprüfung](/de/docs/Web/Security/Practical_implementation_guides/MIME_types)                                             | Niedrig  | Niedrig       | Nein         | Überprüfen Sie, dass alle Ihre Websites die richtigen {{Glossary("MIME_type", "MIME-Typen")}} für alle Ressourcen setzen.                                                                                                           |
+| [CSP-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/CSP)                                                     | Hoch     | Hoch          | Ja           | Bieten Sie eine fein abgestimmte Steuerung, von wo aus Website-Ressourcen mit der {{Glossary("CSP", "Content Security Policy")}} (CSP) geladen werden können.                                                                       |
+| [CORS-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/CORS)                                                     | Hoch     | Niedrig       | Ja           | Definieren Sie die Nicht-Same-Origin-Quellen, die Zugriff auf den Inhalt von Seiten erhalten und Ressourcen von diesen geladen werden dürfen, indem Sie das {{Glossary("CORS", "Cross-Origin Resource Sharing")}} (CORS) verwenden. |
+| [Referrer-Policy-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Referrer_policy)                               | Niedrig  | Niedrig       | Ja           | Verbessern Sie die Privatsphäre der Benutzer und verhindern Sie das Auslaufen interner URLs über den {{httpheader("Referer")}}-Header.                                                                                              |
+| [robots.txt-Konfiguration](/de/docs/Web/Security/Practical_implementation_guides/Robots_txt)                                         | Niedrig  | Niedrig       | Nein         | Weisen Sie Roboter (wie Suchmaschinenindexer) an, nicht bestimmte Pfade auf der Website zu crawlen.                                                                                                                                 |
+| [SRI-Implementierung](/de/docs/Web/Security/Practical_implementation_guides/SRI)                                                     | Niedrig  | Niedrig       | Nein         | Stellen Sie sicher, dass abgerufene Ressourcen (zum Beispiel von einem CDN) ohne unerwartete Manipulation geliefert werden, indem Sie {{Glossary("SRI", "Subresource Integrity")}} (SRI) verwenden.                                 |
 
-## Sicherheit von Benutzerdaten
+## Sicherheit der Benutzerinformationen
 
-- [Anleitung zur Deaktivierung der Formular-Autovervollständigung](/de/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion)
-  - : Formularfelder unterstützen die Autovervollständigung; das heißt, ihre Werte können gespeichert und automatisch ausgefüllt werden, wenn ein Benutzer Ihre Seite erneut besucht. Für bestimmte Datentypen möchten Sie diese Funktion möglicherweise deaktivieren; dieser Artikel erklärt, wie.
+- [Anleitung zum Ausschalten der Formular-Autovervollständigung](/de/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion)
+  - : Formularfelder unterstützen die Autovervollständigung; das heißt, ihre Werte können gespeichert und beim nächsten Besuch automatisch ausgefüllt werden. Für bestimmte Arten von Daten möchten Sie möglicherweise diese Funktion deaktivieren; dieser Artikel erklärt, wie.
 
 ## Siehe auch
 
diff --git a/files/de/web/security/types_of_attacks/index.md b/files/de/web/security/types_of_attacks/index.md
index 7ef41d9c5..7f1f0d4f0 100644
--- a/files/de/web/security/types_of_attacks/index.md
+++ b/files/de/web/security/types_of_attacks/index.md
@@ -2,48 +2,48 @@
 title: Arten von Angriffen
 slug: Web/Security/Types_of_attacks
 l10n:
-  sourceCommit: 6acc0b4325c55fd77dc578c5bd7fde008cf26310
+  sourceCommit: be3f184d89979d413204b8f9cbecfc8dd0e5ecf9
 ---
 
 {{QuickLinksWithSubpages("/de/docs/Web/Security")}}
 
-Dieser Artikel beschreibt verschiedene Arten von Sicherheitsangriffen und Techniken zu deren Abwehr.
+Dieser Artikel beschreibt verschiedene Arten von Sicherheitsangriffen und Techniken zu deren Minderung.
 
-## Click-Jacking
+## Clickjacking
 
-{{Glossary("Clickjacking", "Click-Jacking")}} ist die Praxis, einen Benutzer dazu zu bringen, auf einen Link, Button usw. zu klicken, der etwas anderes ist, als der Benutzer denkt. Dies kann beispielsweise dazu verwendet werden, Anmeldedaten zu stehlen oder um die unwissentliche Erlaubnis des Benutzers zu erhalten, ein Stück Schadsoftware zu installieren. (Click-Jacking wird manchmal auch als "Benutzeroberflächen-Neuausrichtung" bezeichnet, obwohl dies ein Missbrauch des Begriffs "Neuausrichtung" ist.)
+[Clickjacking](/de/docs/Web/Security/Attacks/Clickjacking) ist die Praxis, einen Benutzer dazu zu verleiten, auf einen Link, Knopf usw. zu klicken, der etwas anderes ist, als was der Benutzer denkt. Dies kann zum Beispiel dazu verwendet werden, Anmeldedaten zu stehlen oder die unwissentliche Erlaubnis des Benutzers zu erhalten, ein Stück Malware zu installieren. (Clickjacking wird manchmal als "Benutzeroberflächen-Manipulation" bezeichnet, obwohl dies eine falsche Verwendung des Begriffs "Manipulation" ist.)
 
 ## Cross-Site-Scripting (XSS)
 
-Cross-Site-Scripting (XSS) ist ein Sicherheitsangriff, der es einem Angreifer ermöglicht, bösartigen clientseitigen Code in eine Website einzufügen. Dieser Code wird von den Opfern ausgeführt und ermöglicht es den Angreifern, Zugangsbeschränkungen zu umgehen und sich als Benutzer auszugeben. Laut dem Open Web Application Security Project war XSS [die siebt häufigste Web-App-Sicherheitslücke](https://owasp.org/www-project-top-ten/2017/Top_10) im Jahr 2017.
+Cross-Site-Scripting (XSS) ist ein Sicherheitsangriff, der es einem Angreifer ermöglicht, in eine Webseite schädlichen clientseitigen Code einzuschleusen. Dieser Code wird von den Opfern ausgeführt und ermöglicht es Angreifern, Zugangskontrollen zu umgehen und Benutzer zu imitieren. Laut dem Open Web Application Security Project war XSS 2017 die [siebt häufigste Schwachstelle bei Webanwendungen](https://owasp.org/www-project-top-ten/2017/Top_10).
 
-Diese Angriffe gelingen, wenn die Web-App nicht ausreichend validiert oder codiert wird. Der Browser des Benutzers kann nicht erkennen, dass das bösartige Skript nicht vertrauenswürdig ist, und gewährt ihm so Zugriff auf Cookies, Sitzungs-Token oder andere sensible sitespezifische Informationen oder erlaubt dem bösartigen Skript, den {{Glossary("HTML", "HTML")}}-Inhalt neu zu schreiben.
+Diese Angriffe sind erfolgreich, wenn die Webanwendung nicht genügend Validierung oder Kodierung verwendet. Der Browser des Benutzers kann das bösartige Skript nicht als unzuverlässig erkennen und ermöglicht ihm den Zugriff auf Cookies, Sitzungstokens oder andere sensible, sitzungsbezogene Informationen oder lässt das bösartige Skript das {{Glossary("HTML", "HTML")}}-Inhalt überschreiben.
 
-Cross-Site-Scripting-Angriffe treten normalerweise auf, wenn 1) Daten über eine nicht vertrauenswürdige Quelle in eine Web-App gelangen (häufig eine Web-Anfrage) oder 2) dynamischer Inhalt an einen Web-Benutzer gesendet wird, ohne auf bösartige Inhalte überprüft zu werden.
+Cross-Site-Scripting-Angriffe treten normalerweise auf, wenn 1) Daten aus einer nicht vertrauenswürdigen Quelle (meistens eine Webanforderung) in eine Webanwendung gelangen oder 2) dynamische Inhalte an einen Webbenutzer gesendet werden, ohne auf bösartige Inhalte geprüft zu werden.
 
-Der bösartige Inhalt umfasst oft {{Glossary("JavaScript", "JavaScript")}}, manchmal jedoch auch HTML, Flash oder jeden anderen Code, den der Browser ausführen kann. Die Vielfalt der auf XSS basierenden Angriffe ist nahezu unbegrenzt, aber sie umfassen häufig die Übertragung privater Daten wie Cookies oder anderer Sitzungsinformationen an den Angreifer, die Weiterleitung des Opfers auf eine vom Angreifer kontrollierte Webseite oder das Ausführen anderer bösartiger Operationen auf dem Computer des Benutzers unter dem Deckmantel der anfälligen Seite.
+Der bösartige Inhalt umfasst oft {{Glossary("JavaScript", "JavaScript")}}, manchmal jedoch auch HTML, Flash oder anderen Code, den der Browser ausführen kann. Die Vielfalt der auf XSS basierenden Angriffe ist nahezu unbegrenzt, sie umfassen jedoch häufig das Übermitteln privater Daten wie Cookies oder anderer Sitzungsinformationen an den Angreifer, das Weiterleiten des Opfers zu einer von dem Angreifer kontrollierten Webseite oder das Durchführen anderer bösartiger Operationen auf dem Computer des Benutzers unter dem Deckmantel der verwundbaren Seite.
 
-XSS-Angriffe können in drei Kategorien eingeteilt werden: gespeichert (auch persistent genannt), reflektiert (auch nicht-persistent genannt) oder DOM-basiert.
+XSS-Angriffe können in drei Kategorien unterteilt werden: gespeichert (auch persistent genannt), reflektiert (auch nicht-persistent genannt) oder DOM-basiert.
 
 - Gespeicherte XSS-Angriffe
-  - : Das injizierte Skript wird dauerhaft auf den Zielservern gespeichert. Das Opfer ruft dann dieses bösartige Skript vom Server ab, wenn der Browser eine Datenanforderung sendet.
+  - : Das injizierte Skript wird dauerhaft auf den Zielservern gespeichert. Das Opfer ruft dieses bösartige Skript dann vom Server ab, wenn der Browser eine Anfrage nach Daten sendet.
 - Reflektierte XSS-Angriffe
-  - : Wenn ein Benutzer dazu gebracht wird, auf einen bösartigen Link zu klicken, ein speziell gestaltetes Formular abzusenden oder eine bösartige Seite zu besuchen, gelangt der injizierte Code zur anfälligen Website. Der Web-Server reflektiert das injizierte Skript zurück an den Browser des Benutzers, beispielsweise in einer Fehlermeldung, einem Suchergebnis oder einer anderen Antwort, die Daten enthält, die als Teil der Anfrage an den Server gesendet wurden. Der Browser führt den Code aus, da er annimmt, die Antwort stamme von einem "vertrauenswürdigen" Server, mit dem der Benutzer bereits interagiert hat.
+  - : Wenn ein Benutzer dazu verleitet wird, auf einen bösartigen Link zu klicken, ein speziell gestaltetes Formular abzuschicken oder eine bösartige Webseite zu besuchen, wird der injizierte Code an die verwundbare Webseite gesendet. Der Webserver spiegelt das injizierte Skript an den Browser des Benutzers zurück, beispielsweise in einer Fehlermeldung, einem Suchergebnis oder einer anderen Antwort, die die als Teil der Anfrage an den Server gesendeten Daten enthält. Der Browser führt den Code aus, da er annimmt, dass die Antwort von einem "vertrauenswürdigen" Server stammt, mit dem der Benutzer bereits interagiert hat.
 - DOM-basierte XSS-Angriffe
-  - : Die Nutzlast wird ausgeführt, indem das DOM-Umfeld (im Browser des Opfers) geändert wird, das vom ursprünglichen clientseitigen Skript verwendet wird. Das heißt, die Seite selbst ändert sich nicht, aber der clientseitige Code in der Seite wird aufgrund der bösartigen Änderungen am DOM-Umfeld auf unerwartete Weise ausgeführt.
+  - : Der Payload wird als Ergebnis der Änderung der DOM-Umgebung (im Browser des Opfers) ausgeführt, die vom ursprünglichen clientseitigen Skript verwendet wird. Das heißt, die Seite selbst ändert sich nicht, aber der in der Seite enthaltene clientseitige Code wird aufgrund der bösartigen Änderungen an der DOM-Umgebung auf unerwartete Weise ausgeführt.
 
 ## Cross-Site-Request-Forgery (CSRF)
 
-CSRF (manchmal auch XSRF genannt) gehört zu einer verwandten Klasse von Angriffen. Der Angreifer veranlasst den Browser des Benutzers, eine Anfrage an das Backend der Website zu senden, ohne die Zustimmung oder das Wissen des Benutzers. Ein Angreifer kann eine XSS-Nutzlast verwenden, um einen CSRF-Angriff zu starten.
+CSRF (manchmal auch XSRF genannt) ist eine verwandte Klasse von Angriffen. Der Angreifer veranlasst den Browser des Benutzers, eine Anfrage an das Backend der Website zu senden, ohne dass der Benutzer zustimmt oder davon Kenntnis hat. Ein Angreifer kann eine XSS-Nutzlast verwenden, um einen CSRF-Angriff auszuführen.
 
-Wikipedia erwähnt ein gutes Beispiel für CSRF. In dieser Situation fügt jemand ein Bild ein, das eigentlich kein Bild ist (zum Beispiel in einem ungefilterten Chat oder Forum), sondern tatsächlich eine Anfrage an den Server Ihrer Bank, um Geld abzuheben:
+Wikipedia nennt ein gutes Beispiel für CSRF. In dieser Situation fügt jemand ein Bild ein, das kein echtes Bild ist (zum Beispiel in einem ungefilterten Chat oder Forum), sondern tatsächlich eine Anfrage an den Server Ihrer Bank ist, um Geld abzuheben:
 
 ```html
 <img
   src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />
 ```
 
-Wenn Sie nun in Ihr Bankkonto eingeloggt sind und Ihre Cookies noch gültig sind (und es keine andere Validierung gibt), überweisen Sie Geld, sobald Sie das HTML laden, das dieses Bild enthält. Für Endpunkte, die eine POST-Anfrage erfordern, ist es möglich, programmatisch einen `<form>`-Abschnitt beim Laden der Seite auszulösen (vielleicht in einem unsichtbaren `<iframe>`):
+Nun, wenn Sie in Ihrem Bankkonto angemeldet sind und Ihre Cookies noch gültig sind (und es keine weitere Validierung gibt), werden Sie Geld überweisen, sobald Sie das HTML laden, das dieses Bild enthält. Für Endpunkte, die eine POST-Anfrage erfordern, ist es möglich, programmatisch ein `<form>`-Übermittlung auszulösen (vielleicht in einem unsichtbaren `<iframe>`), wenn die Seite geladen wird:
 
 ```html
 <form action="https://bank.example.com/withdraw" method="POST">
@@ -58,41 +58,40 @@ Wenn Sie nun in Ihr Bankkonto eingeloggt sind und Ihre Cookies noch gültig sind
 </script>
 ```
 
-Es gibt einige Techniken, die angewendet werden sollten, um dies zu verhindern:
+Es gibt einige Techniken, die verwendet werden sollten, um dies zu verhindern:
 
-- GET-Endpunkte sollten idempotent sein – Aktionen, die eine Änderung bewirken und keine Daten abrufen, sollten das Senden einer POST- (oder einer anderen HTTP-Methode) Anfrage erfordern. POST-Endpunkte sollten nicht austauschbar GET-Anfragen mit Parametern im Abfrage-String akzeptieren.
-- Ein sitzungsbasierter CSRF-Token sollte vom Server an den Browser bereitgestellt werden. Dieser Token kann dann immer dann eingefügt werden, wenn ein Formular vom Browser abgesendet wird (in einem versteckten Eingabefeld im `<form>`-Element). Für alle nicht-GEGET-Anfragen, die möglicherweise eine Aktion durchführen könnten, vergleicht der Server den gesendeten Token mit seinem gespeicherten Wert für die Sitzung. Wenn es eine Abweichung gibt, wird die Anfrage abgebrochen.
-- Diese Schutzmethode hängt davon ab, dass ein Angreifer nicht in der Lage ist, den zugewiesenen CSRF-Token des Benutzers vorherzusagen. Der Token sollte bei der Anmeldung neu generiert werden.
-- Cookies, die für sensible Aktionen verwendet werden (wie Sitzungscookies), sollten eine kurze Lebensdauer haben und das [`SameSite`-Attribut](/de/docs/Web/HTTP/Cookies#controlling_third-party_cookies_with_samesite) sollte auf `Strict` oder `Lax` gesetzt sein. In unterstützenden Browsern wird sichergestellt, dass das Sitzungscookie nicht zusammen mit Cross-Site-Anfragen gesendet wird und diese das Anwendungsserver effektiv unauthentifiziert machen.
-- Sowohl CSRF-Token als auch `SameSite`-Cookies sollten eingesetzt werden. Dadurch werden alle Browser geschützt und es wird Schutz geboten, wo `SameSite`-Cookies nicht helfen können (wie Angriffe von einer separaten Subdomain).
+- GET-Endpunkte sollten idempotent sein – Aktionen, die eine Änderung bewirken und keine Daten abrufen, sollten erfordern, dass eine POST- (oder andere HTTP-Methode) Anfrage gesendet wird. POST-Endpunkte sollten nicht austauschbar GET-Anfragen mit Parametern in der Abfragezeichenfolge akzeptieren.
+- Ein sitzungs-einzigartiger CSRF-Token sollte vom Server an den Browser bereitgestellt werden. Dieser Token kann dann immer dann eingeschlossen werden, wenn ein Formular vom Browser gesendet wird (in einem versteckten Eingabefeld im `<form>`-Element). Bei allen Nicht-GET-Anfragen, die potenziell eine Aktion ausführen können, vergleicht der Server den gesendeten Token mit seinem gespeicherten Wert für die Sitzung. Wenn es eine Abweichung gibt, wird die Anfrage abgebrochen.
+- Diese Schutzmethode beruht darauf, dass ein Angreifer den dem Benutzer zugewiesenen CSRF-Token nicht vorhersagen kann. Der Token sollte bei der Anmeldung neu generiert werden.
+- Cookies, die für sensible Aktionen verwendet werden (wie Sitzungscookies), sollten eine kurze Lebensdauer mit dem [`SameSite`-Attribut](/de/docs/Web/HTTP/Cookies#controlling_third-party_cookies_with_samesite) haben, das auf `Strict` oder `Lax` gesetzt ist. In unterstützenden Browsern stellt dies sicher, dass das Sitzungscookie nicht mit standortübergreifenden Anfragen gesendet wird und dass die Anfrage für den Anwendungsserver effektiv nicht authentifiziert ist.
+- Sowohl CSRF-Token als auch `SameSite`-Cookies sollten eingesetzt werden. Dies stellt sicher, dass alle Browser geschützt sind und bietet Schutz, wo `SameSite`-Cookies nicht helfen können (wie Angriffe von einer separaten Subdomain).
 
-Für weitere Präventionstipps siehe das OWASP CSRF Prevention Cheat Sheet.
+Weitere Präventionstipps finden Sie im OWASP CSRF-Präventionsleitfaden.
 
 ## Man-in-the-middle (MitM)
 
-Eine dritte Partei fängt den Datenverkehr zwischen einem Web-Server und einem Client (Browser) ab und gibt sich als Web-Server aus, um Daten (wie Anmeldeinformationen oder Kreditkarteninformationen) zu erfassen. Der Datenverkehr wird eventuell mit Änderungen durchgeleitet. Offene Wi-Fi-Netzwerke sind typische Mittel zur Durchführung dieses Angriffs.
+Eine dritte Partei fängt den Datenverkehr zwischen einem Webserver und einem Client (Browser) ab und gibt vor, der Webserver zu sein, um Daten (wie Anmeldedaten oder Kreditkarteninformationen) zu erfassen. Der Datenverkehr wird durchgeleitet, möglicherweise mit Änderungen. Offene WLAN-Netzwerke sind typische Mittel zur Ausführung dieses Angriffs.
 
-## Sitzungshijacking
+## Sitzungs-Hijacking
 
-Sitzungshijacking besteht darin, Zugriff auf und den Missbrauch einer authentifizierten Sitzung des Benutzers zu erlangen. Dies kann geschehen, indem ein Cookie für eine vorhandene Sitzung gestohlen wird oder der Benutzer (oder sein Browser) dazu gebracht wird, ein Cookie mit einer vorher festgelegten Sitzungs-ID zu setzen.
+Sitzungs-Hijacking besteht darin, Zugriff auf die authentifizierte Sitzung eines Benutzers zu erlangen und diese zu missbrauchen. Dies kann durch Stehlen eines Cookies für eine bestehende Sitzung geschehen oder indem der Benutzer (oder sein Browser) dazu gebracht wird, ein Cookie mit einer vorherbestimmten Sitzungs-ID zu setzen.
 
-Exfiltrationsmöglichkeiten können durch den Einsatz einer strikten Content-Security-Policy eingeschränkt werden.
+Die Möglichkeiten der Exfiltration können durch den Einsatz einer strengen Content-Security-Policy eingeschränkt werden.
 
-### Sitzungsfixierung
+### Sitzungs-Fixierung
 
-Eine dritte Partei ist in der Lage, den Sitzungsbezeichner eines Benutzers zu bestimmen (z. B. durch Lesen oder Setzen), und kann deshalb mit dem Server als dieser Benutzer interagieren. Das Stehlen von Cookies ist eine Möglichkeit, dies zu tun.
+Eine dritte Partei kann den Sitzungsbezeichner eines Benutzers (d.h. durch das Lesen oder Setzen) bestimmen und daher mit dem Server als dieser Benutzer interagieren. Das Stehlen von Cookies ist eine Möglichkeit, dies zu tun.
 
-Erinnern Sie sich daran, dass eine Subdomain wie application.example.com ein Cookie setzen kann, das mit Anfragen an example.com oder andere Subdomains gesendet wird, indem das `Domain`-Attribut gesetzt wird:
+Denken Sie daran, dass eine Subdomain wie application.example.com ein Cookie setzen kann, das mit Anfragen an example.com oder andere Subdomains gesendet wird, indem das `Domain`-Attribut festgelegt wird:
 
 ```http
 Set-Cookie: CSRF=e8b667; Secure; Domain=example.com
 ```
 
-Wenn eine anfällige Anwendung auf einer Subdomain verfügbar ist, kann dieser Mechanismus in einem Sitzungsfixierungsangriff missbraucht werden. Wenn der Benutzer eine Seite auf der übergeordneten Domain (oder einer anderen Subdomain) besucht, könnte die Anwendung den vorhandenen Wert im Cookie des Benutzers vertrauen. Dies könnte einem Angreifer erlauben, CSRF-Schutz zu umgehen oder eine Sitzung zu kapern, nachdem der Benutzer sich anmeldet.
-Alternativ, wenn die übergeordnete Domain nicht {{Glossary("HSTS", "HTTP Strict-Transport-Security")}} mit `includeSubdomains` verwendet, könnte ein Benutzer, der einem aktiven MitM ausgesetzt ist (möglicherweise aufgrund einer Verbindung zu einem offenen Wi-Fi-Netzwerk), eine Antwort mit einem Set-Cookie-Header von einer nicht existierenden Subdomain erhalten. Das Endergebnis wäre viel das Gleiche, wobei der Browser das illegitime Cookie speichert und mit allen anderen Seiten unter example.com sendet.
+Wenn eine anfällige Anwendung auf einer Subdomain verfügbar ist, kann dieser Mechanismus in einem Sitzungs-Fixierungsangriff missbraucht werden. Wenn der Benutzer eine Seite auf der Elterndomain (oder einer anderen Subdomain) besucht, kann die Anwendung den vorhandenen Wert im Cookie des Benutzers vertrauen. Dies könnte einem Angreifer erlauben, den CSRF-Schutz zu umgehen oder eine Sitzung zu kapern, nachdem der Benutzer sich angemeldet hat. Alternativ, wenn die Elterndomain kein {{Glossary("HSTS", "HTTP Strict-Transport-Security")}} mit `includeSubdomains` gesetzt verwendet, könnte ein Benutzer, der einem aktiven MitM (vielleicht verbunden mit einem offenen WLAN-Netzwerk) unterliegt, eine Antwort mit einem Set-Cookie-Header von einer nicht vorhandenen Subdomain erhalten. Das Endergebnis wäre ähnlich, mit dem Browser, der das illegitime Cookie speichert und es an alle anderen Seiten unter example.com sendet.
 
-Sitzungsfixierung sollte in erster Linie durch Regenerierung von Sitzungs-Cookie-Werten verhindert werden, wenn sich der Benutzer authentifiziert (auch wenn bereits ein Cookie vorhanden ist), und indem ein CSRF-Token an den Benutzer gebunden wird.
+Sitzungs-Fixierung sollte hauptsächlich dadurch gemildert werden, dass die Werte der Sitzungscookies neu generiert werden, wenn der Benutzer authentifiziert wird (auch wenn ein Cookie bereits existiert) und indem ein CSRF-Token an den Benutzer gebunden wird.
 
-### Seitliches Sitzunghijacking
+### Sitzung-Sidejacking
 
-### Malware zur Browser-Entführung
+### Browser-Hijacking-Malware