diff --git a/files/en-us/web/security/attacks/clickjacking/index.md b/files/en-us/web/security/attacks/clickjacking/index.md
index d249eea05a6cfea..8c73de41adfe102 100644
--- a/files/en-us/web/security/attacks/clickjacking/index.md
+++ b/files/en-us/web/security/attacks/clickjacking/index.md
@@ -63,6 +63,12 @@ If `frame-ancestors` and `X-Frame-Options` are both set, then browsers that supp
 
 As an additional partial mitigation, sites should set the [`SameSite`](/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) cookie attribute for session cookies to `Lax` or `Strict`. Requests from embedded contexts such as `<iframe>` elements that are not {{glossary("Site", "same-site")}} with the top-level document will not include these cookies, and the server will therefore not treat the request as coming from a logged-in user.
 
+## Defense summary checklist
+
+- Set the [`frame-ancestors`](/en-US/docs/Web/HTTP/Guides/CSP#clickjacking_protection) CSP directive and the {{httpheader("X-Frame-Options")}} HTTP response header, in order to prevent other sites from embedding your site as an `<iframe>`, or to strictly control which sites can embed it.
+
+- Set the [`SameSite`](/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) cookie attribute for session cookies to `Lax` or `Strict`.
+
 ## See also
 
 - [Clickjacking Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) at [owasp.org](https://owasp.org/)
diff --git a/files/en-us/web/security/attacks/csrf/index.md b/files/en-us/web/security/attacks/csrf/index.md
index 41f52cceaa9b227..fff2655f26955a8 100644
--- a/files/en-us/web/security/attacks/csrf/index.md
+++ b/files/en-us/web/security/attacks/csrf/index.md
@@ -173,9 +173,7 @@ Another problem with the `SameSite` attribute is that it protects you from reque
 
 See [Bypassing SameSite cookie restrictions](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) for more details on the limitations of `SameSite`.
 
-### Defense summary checklist
-
-We can summarize the defenses above as follows:
+## Defense summary checklist
 
 - Understand where in your website you are implementing state-changing requests that use session cookies to check which user issued the request.
 - Implement at least one of the primary defenses described in this document:
diff --git a/files/en-us/web/security/attacks/mitm/index.md b/files/en-us/web/security/attacks/mitm/index.md
index 558a14ec09d3263..0ef42091117cee9 100644
--- a/files/en-us/web/security/attacks/mitm/index.md
+++ b/files/en-us/web/security/attacks/mitm/index.md
@@ -41,7 +41,7 @@ To reduce the risk of this attack, your server should also send the {{httpheader
 
 With HSTS, SSL stripping is prevented except for the first time the browser tries to connect to your site (or, since HSTS has an expiry, the first time after an HSTS record in the browser has expired). To protect your site even on first connection or HSTS record expiry, Chrome maintains a list of domains called the [HSTS preload list](https://hstspreload.org/): if a domain is on this list, then Chrome will always upgrade HTTP request to HTTPS, effectively behaving as if the server has already sent the HSTS header. Safari and Firefox have similar behavior, using a list that is derived from the Chrome list.
 
-### Defense summary checklist
+## Defense summary checklist
 
 - Serve all your site's pages and subresources over HTTPS.
 - If you want to redirect HTTP requests to HTTPS, use HSTS, and consider adding your site to the HSTS preload list.
diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md
index d57f8df6534b6ef..a1c10cf60738470 100644
--- a/files/en-us/web/security/attacks/phishing/index.md
+++ b/files/en-us/web/security/attacks/phishing/index.md
@@ -117,7 +117,7 @@ In practice there are a few difficulties with this technique:
 
 As a result of these weaknesses, this defense is rarely used: both MFA and passkeys are considered to be stronger defenses.
 
-### Defense summary checklist
+## Defense summary checklist
 
 - Set `SPF`, `DKIM`, and `DMARC` DNS records for your domains.
 - Consider using passkeys to authenticate users.
diff --git a/files/en-us/web/security/attacks/xs-leaks/index.md b/files/en-us/web/security/attacks/xs-leaks/index.md
index e7d0a5a90f9950f..12c12725c9ec83b 100644
--- a/files/en-us/web/security/attacks/xs-leaks/index.md
+++ b/files/en-us/web/security/attacks/xs-leaks/index.md
@@ -237,9 +237,9 @@ The {{httpheader("Cross-Origin-Opener-Policy")}} response header determines whet
 
 If your server sends this header and sets it to any value except the default of `"unsafe-none"`, then if a document from a different origin tries to open your page using `window.open()`, your page will be loaded into a different browsing context group. Among other things, this means that the opener will not get a reference to the `window` object for your page, and will therefore not be able to use it in a frame counting attack.
 
-### Defense summary checklist
+## Defense summary checklist
 
-As we've seen, cross-site leaks include a range of attacks targeting different parts of the web platform: a single defense doesn't work against any of them. Indeed, some leaks, such as the one that exploits CSP to leak redirects, don't have any defenses yet.
+Cross-site leaks include a range of attacks targeting different parts of the web platform. A single defense doesn't work against any of them and some leaks, such as the one that exploits CSP to leak redirects, don't have any defenses yet.
 
 In this guide we've outlined a few defenses that help to isolate your site from potential attackers, and we recommend implementing all of them:
 
diff --git a/files/en-us/web/security/attacks/xss/index.md b/files/en-us/web/security/attacks/xss/index.md
index 799b3be0b05625f..bb315794048e518 100644
--- a/files/en-us/web/security/attacks/xss/index.md
+++ b/files/en-us/web/security/attacks/xss/index.md
@@ -310,9 +310,7 @@ Output encoding and sanitization are all about preventing malicious scripts from
 
 The recommended approach to mitigating XSS with a CSP is a [strict CSP](/en-US/docs/Web/HTTP/Guides/CSP#strict_csp), which uses a [nonce](/en-US/docs/Web/HTTP/Guides/CSP#nonces) or a [hash](/en-US/docs/Web/HTTP/Guides/CSP#hashes) to indicate to the browser which scripts it expects to see in the document. If an attacker manages to insert malicious `<script>` elements, then they won't have the correct nonce or hash, and the browser will not execute them. Additionally, various common XSS vectors are disallowed completely: inline event handlers, `javascript:` URLs, and APIs like `eval()` that execute their arguments as JavaScript.
 
-### Defense summary checklist
-
-We can summarize the defenses above as follows:
+## Defense summary checklist
 
 - When interpolating input into a page, either in the browser or in the server, use a templating engine that performs output encoding.
 - Be aware of the context in which you are interpolating input, and ensure that the appropriate output encoding will be performed in that context.