diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt
index 18fa2020f6cac78..680dd34208ab5e8 100644
--- a/files/en-us/_redirects.txt
+++ b/files/en-us/_redirects.txt
@@ -3557,6 +3557,7 @@
 /en-US/docs/Glossary/Bézier_curve	/en-US/docs/Glossary/Bezier_curve
 /en-US/docs/Glossary/CSS_property	/en-US/docs/Glossary/property/CSS
 /en-US/docs/Glossary/Cleartext	/en-US/docs/Glossary/Plaintext
+/en-US/docs/Glossary/Clickjacking	/en-US/docs/Web/Security/Attacks/Clickjacking
 /en-US/docs/Glossary/Client_hints	/en-US/docs/Web/HTTP/Client_hints
 /en-US/docs/Glossary/Condition	/en-US/docs/Glossary/Conditional
 /en-US/docs/Glossary/Content_type	/en-US/docs/Glossary/MIME_type
diff --git a/files/en-us/glossary/clickjacking/index.md b/files/en-us/glossary/clickjacking/index.md
deleted file mode 100644
index 825a62f045bf449..000000000000000
--- a/files/en-us/glossary/clickjacking/index.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Clickjacking
-slug: Glossary/Clickjacking
-page-type: glossary-definition
----
-
-{{GlossarySidebar}}
-
-**Clickjacking** is an interface-based attack that tricks website users into unwittingly clicking on malicious links. In clickjacking, the attackers embed their malicious links into buttons or legitimate pages in a website. In an infected {{glossary("Site")}}, whenever a user clicks on a legitimate link, the attacker gets the confidential information of that user, which ultimately compromises the user's privacy on the Internet.
-
-Clickjacking can be prevented by implementing a [Content Security Policy (frame-ancestors)](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) and implementing [Set-Cookie attributes](/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes).
-
-## See also
-
-- [Web security: clickjacking protection](/en-US/docs/Web/Security/Practical_implementation_guides/Clickjacking)
-- [Clickjacking](https://en.wikipedia.org/wiki/Clickjacking) on Wikipedia
-- [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking) on OWASP
diff --git a/files/en-us/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md b/files/en-us/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
index e749e333252b673..d4a55d4bc184555 100644
--- a/files/en-us/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
+++ b/files/en-us/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
@@ -257,9 +257,9 @@ Above we mentioned security concerns — let's go into this in a bit more detail
 
 Browser makers and Web developers have learned the hard way that iframes are a common target (official term: **attack vector**) for bad people on the Web (often termed **hackers**, or more accurately, **crackers**) to attack if they are trying to maliciously modify your webpage, or trick people into doing something they don't want to do, such as reveal sensitive information like usernames and passwords. Because of this, spec engineers and browser developers have developed various security mechanisms for making `<iframe>`s more secure, and there are also best practices to consider — we'll cover some of these below.
 
-> **Note:** [Clickjacking](/en-US/docs/Glossary/Clickjacking) is one kind of common iframe attack where hackers embed an invisible iframe into your document (or embed your document into their own malicious website) and use it to capture users' interactions. This is a common way to mislead users or steal sensitive data.
+> **Note:** [Clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) is one kind of common iframe attack where hackers embed an invisible iframe into your document (or embed your document into their own malicious website) and use it to capture users' interactions. This is a common way to mislead users or steal sensitive data.
 
-A quick example first though — try loading the previous example we showed above into your browser — you can [find it live on GitHub](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) ([see the source code](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) too.) Instead of the page you expected, you'll probably see some kind of message to the effect of "I can't open this page", and if you look at the _Console_ in the [browser developer tools](/en-US/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools), you'll see a message telling you why. In Firefox, you'll get told something like _The loading of "https\://developer.mozilla.org/en-US/docs/Glossary" in a frame is denied by "X-Frame-Options" directive set to "DENY"_. This is because the developers that built MDN have included a setting on the server that serves the website pages to disallow them from being embedded inside `<iframe>`s (see [Configure CSP directives](#configure_csp_directives), below.) This makes sense — an entire MDN page doesn't really make sense to be embedded in other pages unless you want to do something like embed them on your site and claim them as your own — or attempt to steal data via [clickjacking](/en-US/docs/Glossary/Clickjacking), which are both really bad things to do. Plus if everybody started to do this, all the additional bandwidth would start to cost Mozilla a lot of money.
+A quick example first though — try loading the previous example we showed above into your browser — you can [find it live on GitHub](https://mdn.github.io/learning-area/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) ([see the source code](https://github.com/mdn/learning-area/blob/main/html/multimedia-and-embedding/other-embedding-technologies/iframe-detail.html) too.) Instead of the page you expected, you'll probably see some kind of message to the effect of "I can't open this page", and if you look at the _Console_ in the [browser developer tools](/en-US/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools), you'll see a message telling you why. In Firefox, you'll get told something like _The loading of "https\://developer.mozilla.org/en-US/docs/Glossary" in a frame is denied by "X-Frame-Options" directive set to "DENY"_. This is because the developers that built MDN have included a setting on the server that serves the website pages to disallow them from being embedded inside `<iframe>`s (see [Configure CSP directives](#configure_csp_directives), below.) This makes sense — an entire MDN page doesn't really make sense to be embedded in other pages unless you want to do something like embed them on your site and claim them as your own — or attempt to steal data via clickjacking, which are both really bad things to do. Plus if everybody started to do this, all the additional bandwidth would start to cost Mozilla a lot of money.
 
 #### Only embed when necessary
 
@@ -294,7 +294,7 @@ If absolutely required, you can add permissions back one by one (inside the `san
 
 #### Configure CSP directives
 
-{{Glossary("CSP")}} stands for **[content security policy](/en-US/docs/Web/HTTP/CSP)** and provides [a set of HTTP Headers](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) (metadata sent along with your web pages when they are served from a web server) designed to improve the security of your HTML document. When it comes to securing `<iframe>`s, you can _[configure your server to send an appropriate `X-Frame-Options` header.](/en-US/docs/Web/HTTP/Headers/X-Frame-Options)_ This can prevent other websites from embedding your content in their web pages (which would enable [clickjacking](/en-US/docs/Glossary/Clickjacking) and a host of other attacks), which is exactly what the MDN developers have done, as we saw earlier on.
+{{Glossary("CSP")}} stands for **[content security policy](/en-US/docs/Web/HTTP/CSP)** and provides [a set of HTTP Headers](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) (metadata sent along with your web pages when they are served from a web server) designed to improve the security of your HTML document. When it comes to securing `<iframe>`s, you can _[configure your server to send an appropriate `X-Frame-Options` header.](/en-US/docs/Web/HTTP/Headers/X-Frame-Options)_ This can prevent other websites from embedding your content in their web pages (which would enable [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) and a host of other attacks), which is exactly what the MDN developers have done, as we saw earlier on.
 
 > [!NOTE]
 > You can read Frederik Braun's post [On the X-Frame-Options Security Header](https://blog.mozilla.org/security/2013/12/12/on-the-x-frame-options-security-header/) for more background information on this topic. Obviously, it's rather out of scope for a full explanation in this article.
diff --git a/files/en-us/learn/server-side/apache_configuration_htaccess/index.md b/files/en-us/learn/server-side/apache_configuration_htaccess/index.md
index 088fdb271f982c2..b31f2858c053172 100644
--- a/files/en-us/learn/server-side/apache_configuration_htaccess/index.md
+++ b/files/en-us/learn/server-side/apache_configuration_htaccess/index.md
@@ -367,7 +367,7 @@ The following might not be a good idea if you use "real" subdomains for certain
 
 ## Frame options
 
-The example below sends the `X-Frame-Options` response header with DENY as the value, informing browsers not to display the content of the web page in any frame to protect the website against [clickjacking](/en-US/docs/Glossary/Clickjacking).
+The example below sends the `X-Frame-Options` response header with DENY as the value, informing browsers not to display the content of the web page in any frame to protect the website against [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking).
 
 This might not be the best setting for everyone. You should read about [the other two possible values for the `X-Frame-Options` header](https://datatracker.ietf.org/doc/html/rfc7034#section-2.1): `SAMEORIGIN` and `ALLOW-FROM`.
 
@@ -467,7 +467,7 @@ Be aware that Strict Transport Security is not revokable, and you must ensure be
 3. Only allows form submissions are from the current origin with: `form-action 'self'`
 4. Prevents all websites (including your own) from embedding your webpages within e.g. the `<iframe>` or `<object>` element by setting: `frame-ancestors 'none'`.
 
-   - The `frame-ancestors` directive helps avoid [clickjacking](/en-US/docs/Glossary/Clickjacking) attacks and is similar to the `X-Frame-Options` header
+   - The `frame-ancestors` directive helps avoid [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) attacks and is similar to the `X-Frame-Options` header
    - Browsers that support the CSP header will ignore `X-Frame-Options` if `frame-ancestors` is also specified
 
 5. Forces the browser to treat all the resources that are served over HTTP as if they were loaded securely over HTTPS by setting the `upgrade-insecure-requests` directive
diff --git a/files/en-us/learn/server-side/django/introduction/index.md b/files/en-us/learn/server-side/django/introduction/index.md
index 51c651a629e5fb2..f23f2b8ca061d56 100644
--- a/files/en-us/learn/server-side/django/introduction/index.md
+++ b/files/en-us/learn/server-side/django/introduction/index.md
@@ -47,7 +47,7 @@ Django helps you write software that is:
 
     _A password hash is a fixed-length value created by sending the password through a [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function). Django can check if an entered password is correct by running it through the hash function and comparing the output to the stored hash value. However due to the "one-way" nature of the function, even if a stored hash value is compromised it is hard for an attacker to work out the original password._
 
-    Django enables protection against many vulnerabilities by default, including SQL injection, cross-site scripting, cross-site request forgery and [clickjacking](/en-US/docs/Glossary/Clickjacking) (see [Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) for more details of such attacks).
+    Django enables protection against many vulnerabilities by default, including SQL injection, cross-site scripting, cross-site request forgery and [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) (see [Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) for more details of such attacks).
 
 - Scalable
   - : Django uses a component-based "[shared-nothing](https://en.wikipedia.org/wiki/Shared_nothing_architecture)" architecture (each part of the architecture is independent of the others, and can hence be replaced or changed if needed). Having a clear separation between the different parts means that it can scale for increased traffic by adding hardware at any level: caching servers, database servers, or application servers. Some of the busiest sites have successfully scaled Django to meet their demands (e.g. Instagram and Disqus, to name just two).
diff --git a/files/en-us/learn/server-side/django/web_application_security/index.md b/files/en-us/learn/server-side/django/web_application_security/index.md
index da38178c8669c8b..4c1e5a301ced9f6 100644
--- a/files/en-us/learn/server-side/django/web_application_security/index.md
+++ b/files/en-us/learn/server-side/django/web_application_security/index.md
@@ -161,7 +161,7 @@ Django also provides other forms of protection (most of which would be hard or n
 - SQL injection protection
   - : SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified, or deleted irrespective of the user's permissions. In almost every case you'll be accessing the database using Django's querysets/models, so the resulting SQL will be properly escaped by the underlying database driver. If you do need to write raw queries or custom SQL then you'll need to explicitly think about preventing SQL injection.
 - Clickjacking protection
-  - : In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials in an invisible [`<iframe>`](/en-US/docs/Web/HTML/Element/iframe) controlled by the attacker. Django contains [clickjacking](/en-US/docs/Glossary/Clickjacking) protection in the form of the [`X-Frame-Options` middleware](https://docs.djangoproject.com/en/4.0/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware) which, in a supporting browser, can prevent a site from being rendered inside a frame.
+  - : In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials in an invisible [`<iframe>`](/en-US/docs/Web/HTML/Element/iframe) controlled by the attacker. Django contains [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) protection in the form of the [`X-Frame-Options` middleware](https://docs.djangoproject.com/en/4.0/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware) which, in a supporting browser, can prevent a site from being rendered inside a frame.
 - Enforcing TLS/HTTPS
   - : TLS/HTTPS can be enabled on the web server in order to encrypt all traffic between the site and browser, including authentication credentials that would otherwise be sent in plain text (enabling HTTPS is highly recommended). If HTTPS is enabled then Django provides a number of other protections you can use:
     - [`SECURE_PROXY_SSL_HEADER`](https://docs.djangoproject.com/en/5.0/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER) can be used to check whether content is secure, even if it is incoming from a non-HTTP proxy.
diff --git a/files/en-us/learn/server-side/first_steps/website_security/index.md b/files/en-us/learn/server-side/first_steps/website_security/index.md
index fe9f34f9d2de697..2ddc5f69ecfc40d 100644
--- a/files/en-us/learn/server-side/first_steps/website_security/index.md
+++ b/files/en-us/learn/server-side/first_steps/website_security/index.md
@@ -118,7 +118,7 @@ Web frameworks often include such CSRF prevention mechanisms.
 
 Other common attacks/vulnerabilities include:
 
-- [Clickjacking](/en-US/docs/Glossary/Clickjacking). In this attack, a malicious user hijacks clicks meant for a visible top-level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials into an invisible {{htmlelement("iframe")}} controlled by the attacker. Clickjacking could also be used to get the user to click a button on a visible site, but in doing so actually unwittingly click a completely different button. As a defense, your site can prevent itself from being embedded in an iframe in another site by setting the appropriate HTTP headers.
+- [Clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking). In this attack, a malicious user hijacks clicks meant for a visible top-level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials into an invisible {{htmlelement("iframe")}} controlled by the attacker. Clickjacking could also be used to get the user to click a button on a visible site, but in doing so actually unwittingly click a completely different button. As a defense, your site can prevent itself from being embedded in an iframe in another site by setting the appropriate HTTP headers.
 - [Denial of Service](/en-US/docs/Glossary/Distributed_Denial_of_Service) (DoS). DoS is usually achieved by flooding a target site with fake requests so that access to a site is disrupted for legitimate users. The requests may be numerous, or they may individually consume large amounts of resource (e.g., slow reads or uploading of large files). DoS defenses usually work by identifying and blocking "bad" traffic while allowing legitimate messages through. These defenses are typically located before or in the web server (they are not part of the web application itself).
 - [Directory Traversal](https://en.wikipedia.org/wiki/Directory_traversal_attack) (File and disclosure). In this attack, a malicious user attempts to access parts of the web server file system that they should not be able to access. This vulnerability occurs when the user is able to pass filenames that include file system navigation characters (for example, `../../`). The solution is to sanitize input before using it.
 - [File Inclusion](https://en.wikipedia.org/wiki/File_inclusion_vulnerability). In this attack, a user is able to specify an "unintended" file for display or execution in data passed to the server. When loaded, this file might be executed on the web server or the client-side (leading to an XSS attack). The solution is to sanitize input before using it.
diff --git a/files/en-us/web/api/document/requeststorageaccess/index.md b/files/en-us/web/api/document/requeststorageaccess/index.md
index 85bbc8160338c41..66d40ec850a50cd 100644
--- a/files/en-us/web/api/document/requeststorageaccess/index.md
+++ b/files/en-us/web/api/document/requeststorageaccess/index.md
@@ -13,7 +13,7 @@ The **`requestStorageAccess()`** method of the {{domxref("Document")}} interface
 To check whether permission to access third-party cookies has already been granted, you can call {{domxref("Permissions.query()")}}, specifying the feature name `"storage-access"`.
 
 > [!NOTE]
-> Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server. In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics, or prompting the user for explicit permission.
+> Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server. In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) heuristics, or prompting the user for explicit permission.
 
 ## Syntax
 
diff --git a/files/en-us/web/api/document/requeststorageaccessfor/index.md b/files/en-us/web/api/document/requeststorageaccessfor/index.md
index 103a31ea6b650b1..ebb7a1b80bc1013 100644
--- a/files/en-us/web/api/document/requeststorageaccessfor/index.md
+++ b/files/en-us/web/api/document/requeststorageaccessfor/index.md
@@ -67,7 +67,7 @@ navigator.permissions.query({
 ```
 
 > [!NOTE]
-> Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server (the same one that controls the rest of the Storage Access API). In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, or anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics.
+> Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server (the same one that controls the rest of the Storage Access API). In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, or anti-[clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) heuristics.
 
 ## Examples
 
diff --git a/files/en-us/web/api/storage_access_api/index.md b/files/en-us/web/api/storage_access_api/index.md
index c68f0fe98b04546..331d25e3db19e97 100644
--- a/files/en-us/web/api/storage_access_api/index.md
+++ b/files/en-us/web/api/storage_access_api/index.md
@@ -89,7 +89,7 @@ Several different security measures could cause a {{domxref("Document.requestSto
 6. Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server.
 
 > [!NOTE]
-> The document may also be required to pass additional browser-specific checks. Examples: allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics, or prompting the user for explicit permission.
+> The document may also be required to pass additional browser-specific checks. Examples: allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) heuristics, or prompting the user for explicit permission.
 
 ## Browser-specific variations
 
diff --git a/files/en-us/web/http/headers/x-frame-options/index.md b/files/en-us/web/http/headers/x-frame-options/index.md
index b31314a6fa5ba24..e3146f11bf1c43b 100644
--- a/files/en-us/web/http/headers/x-frame-options/index.md
+++ b/files/en-us/web/http/headers/x-frame-options/index.md
@@ -12,7 +12,7 @@ browser-compat: http.headers.X-Frame-Options
 > [!WARNING]
 > Instead of this header, use the {{HTTPHeader("Content-Security-Policy/frame-ancestors", "frame-ancestors")}} directive in a {{HTTPHeader("Content-Security-Policy")}} header.
 
-The HTTP **`X-Frame-Options`** {{Glossary("response header")}} can be used to indicate whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}. Sites can use this to avoid [click-jacking](/en-US/docs/Web/Security/Types_of_attacks#click-jacking) attacks, by ensuring that their content is not embedded into other sites.
+The HTTP **`X-Frame-Options`** {{Glossary("response header")}} can be used to indicate whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} or {{HTMLElement("object")}}. Sites can use this to avoid [clickjacking](/en-US/docs/Web/Security/Types_of_attacks#clickjacking) attacks, by ensuring that their content is not embedded into other sites.
 
 The added security is provided only if the user accessing the document is using a browser that supports `X-Frame-Options`.
 
diff --git a/files/en-us/web/security/attacks/clickjacking/index.md b/files/en-us/web/security/attacks/clickjacking/index.md
index e7b2b7528fdd958..476ca81cc4a5a5c 100644
--- a/files/en-us/web/security/attacks/clickjacking/index.md
+++ b/files/en-us/web/security/attacks/clickjacking/index.md
@@ -49,6 +49,23 @@ If the user tries to click "Click here for a free kitten!", they will actually b
 
 ## Clickjacking defenses
 
-Clickjacking depends on the target website being embedded in the attacker's decoy site inside an `<iframe>`, and the defense is to disallow this by deploying a [content security policy](/en-US/docs/Web/HTTP/CSP) that [sets the `frame-ancestors` directive](/en-US/docs/Web/HTTP/CSP#clickjacking_protection). This enables you to control the sites that are allowed to embed a page in an `<iframe>` or to deny embedding entirely.
+Clickjacking depends on the target website being embedded in the attacker's decoy site inside an `<iframe>`. The main defense is to disallow or at least control this capability.
 
-The `frame-ancestors` directive is a replacement for the {{httpheader("X-Frame-Options")}} response header.
+There are two relevant tools here:
+
+- The [`frame-ancestors` directive](/en-US/docs/Web/HTTP/CSP#clickjacking_protection) in a [content security policy](/en-US/docs/Web/HTTP/CSP)
+- The {{httpheader("X-Frame-Options")}} response header.
+
+The `frame-ancestors` directive is a replacement for `X-Frame-Options`. By setting `X-Frame-Options` as well as `frame-ancestors`, you can prevent embedding in browsers that don't support `frame-ancestors`. However, [browser support for `frame-ancestors` is very good](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors#browser_compatibility), so this is not a major concern.
+
+If `frame-ancestors` and `X-Frame-Options` are both set, then browsers that support `frame-ancestors` will ignore `X-Frame-Options`.
+
+As an additional partial mitigation, sites should set the [`SameSite`](/en-US/docs/Web/HTTP/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.
+
+## See also
+
+- [Clickjacking Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) at [owasp.org](https://owasp.org/)
+
+<section id="Quick_links">
+{{ListSubpages("/en-US/docs/Web/Security", "1", "0", "1")}}
+</section>
diff --git a/files/en-us/web/security/index.md b/files/en-us/web/security/index.md
index bdde4c47a07cb0a..3a378a6e8de384f 100644
--- a/files/en-us/web/security/index.md
+++ b/files/en-us/web/security/index.md
@@ -153,12 +153,12 @@ Any reputable server-side framework will provide functionality for validating fo
 
 ### Protect against clickjacking
 
-In a [clickjacking](/en-US/docs/Glossary/Clickjacking) attack, a user is fooled into clicking a UI element that performs an action different from what the user expects, often resulting in the user's confidential information being passed to a malicious third party. This risk is inherent in embedded third-party content, so make sure you trust what is being embedded into your site. Additionally, be aware that clickjacking can be combined with phishing techniques. You can read about phishing in the previous section [Protect user identity and manage logins](#protect_user_identity_and_manage_logins).
+In a [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) attack, a user is fooled into clicking a UI element that performs an action different from what the user expects, often resulting in the user's confidential information being passed to a malicious third party. This risk is inherent in embedded third-party content, so make sure you trust what is being embedded into your site. Additionally, be aware that clickjacking can be combined with phishing techniques. You can read about phishing in the previous section [Protect user identity and manage logins](#protect_user_identity_and_manage_logins).
 
 The following features can help guard against clickjacking:
 
 - [HTTP X-Frame-Options](/en-US/docs/Web/HTTP/Headers/X-Frame-Options)
-  - : The **`X-Frame-Options`** [HTTP](/en-US/docs/Web/HTTP) response header can be used to indicate whether a browser should be allowed to render a page in a [`<frame>`](/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](/en-US/docs/Web/HTML/Element/iframe), [`<embed>`](/en-US/docs/Web/HTML/Element/embed) or [`<object>`](/en-US/docs/Web/HTML/Element/object). Sites can use this to avoid [clickjacking](/en-US/docs/Glossary/Clickjacking) attacks, by ensuring that their content is not embedded into other sites.
+  - : The **`X-Frame-Options`** [HTTP](/en-US/docs/Web/HTTP) response header can be used to indicate whether a browser should be allowed to render a page in a [`<frame>`](/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](/en-US/docs/Web/HTML/Element/iframe), [`<embed>`](/en-US/docs/Web/HTML/Element/embed) or [`<object>`](/en-US/docs/Web/HTML/Element/object). Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
 - [CSP: frame-ancestors](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors)
   - : The HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`frame-ancestors`** directive specifies valid parents that may embed a page using {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, or {{HTMLElement("embed")}}.
 
diff --git a/files/en-us/web/security/practical_implementation_guides/clickjacking/index.md b/files/en-us/web/security/practical_implementation_guides/clickjacking/index.md
index 6212d747ec411ae..a9e3a4e87b2101c 100644
--- a/files/en-us/web/security/practical_implementation_guides/clickjacking/index.md
+++ b/files/en-us/web/security/practical_implementation_guides/clickjacking/index.md
@@ -10,7 +10,7 @@ The [Content Security Policy](/en-US/docs/Web/HTTP/CSP) [`frame-ancestors`](/en-
 
 ## Problem
 
-[Clickjacking](/en-US/docs/Glossary/Clickjacking) is an attack whereby malicious sites trick users into clicking links or UI elements by making them appear like a trusted site the user is familiar with. This is usually done by embedding part or all of the trusted site into the malicious site via an `<iframe>`. A button, link, or other UI feature is then positioned on top of that content to make the user think they are interacting with their trusted site, when in fact they are interacting with the malicious site.
+[Clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) is an attack whereby malicious sites trick users into clicking links or UI elements by making them appear like a trusted site the user is familiar with. This is usually done by embedding part or all of the trusted site into the malicious site via an `<iframe>`. A button, link, or other UI feature is then positioned on top of that content to make the user think they are interacting with their trusted site, when in fact they are interacting with the malicious site.
 
 ## Solution
 
diff --git a/files/en-us/web/security/practical_implementation_guides/cookies/index.md b/files/en-us/web/security/practical_implementation_guides/cookies/index.md
index eefa7f66a3fe71b..26722eda74c9cc9 100644
--- a/files/en-us/web/security/practical_implementation_guides/cookies/index.md
+++ b/files/en-us/web/security/practical_implementation_guides/cookies/index.md
@@ -40,7 +40,7 @@ To minimize the scope for cookie vulnerabilities on your site, limit access to c
     - `SameSite=Strict`: Only send the cookie in same-site contexts (navigations and other requests). Cookies are omitted in cross-site requests (e.g. embedding images or other resources from other sites) and cross-site navigation (e.g. when following a link from a different web page). This is a very strict setting, but it does provide strong [CSRF](/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention) protection, so use this value if possible.
     - `SameSite=Lax`: Send the cookie in same-site requests and when navigating _to_ your website. This should be used if `Strict` is too restrictive.
 
-    Both of the above values are useful in protecting against [Clickjacking](/en-US/docs/Glossary/Clickjacking) attacks in cases that rely on the user being authenticated.
+    Both of the above values are useful in protecting against [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) attacks in cases that rely on the user being authenticated.
 
     > [!NOTE]
     > In theory, `SameSite=Strict` should be more useful than it is in practice. It often breaks navigations — for example, users clicking a link to a website on which they are already logged in (i.e. a valid session cookie is set) appear not to be logged in, because the browser has deliberately omitted the session cookie. The best middle ground is to use `SameSite=Strict` only on tokens where CSRF is a concern or use `SameSite=Strict` everywhere, but reload the page and do a cookie check in JavaScript if there's an indication that the user is logged in but required cookies are not being sent.
diff --git a/files/en-us/web/security/practical_implementation_guides/index.md b/files/en-us/web/security/practical_implementation_guides/index.md
index d378d4daac55b3f..7d9f33e11cbff7d 100644
--- a/files/en-us/web/security/practical_implementation_guides/index.md
+++ b/files/en-us/web/security/practical_implementation_guides/index.md
@@ -22,7 +22,7 @@ The guides in the table below are listed in the order that we recommend implemen
 | TLS: [Resource loading](/en-US/docs/Web/Security/Practical_implementation_guides/TLS#resource_loading)                                 | Maximum | Low        | Yes      | Load both passive and active resources via HTTPS.                                                                                                                                           |
 | TLS: [HTTP redirection](/en-US/docs/Web/Security/Practical_implementation_guides/TLS#http_redirection)                                 | Maximum | Low        | Yes      | Websites must redirect to HTTPS; API endpoints should disable HTTP entirely.                                                                                                                |
 | TLS: [HSTS implementation](/en-US/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security_implementation) | High    | Low        | Yes      | Notify user agents to connect to sites only over HTTPS, even if the original scheme chosen was HTTP, by using HTTP Strict transport security (HSTS).                                        |
-| [Clickjacking prevention](/en-US/docs/Web/Security/Practical_implementation_guides/Clickjacking)                                       | High    | Low        | Yes      | Control how your site may be framed within an {{htmlelement("iframe")}} to prevent [clickjacking](/en-US/docs/Glossary/Clickjacking).                                                       |
+| [Clickjacking prevention](/en-US/docs/Web/Security/Practical_implementation_guides/Clickjacking)                                       | High    | Low        | Yes      | Control how your site may be framed within an {{htmlelement("iframe")}} to prevent [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking).                                           |
 | [CSRF prevention](/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention)                                            | High    | Unknown    | Varies   | Protect against [Cross-site request forgery](/en-US/docs/Glossary/CSRF) (CSRF) using `SameSite` cookies and anti-CSRF tokens.                                                               |
 | [Secure cookie configuration](/en-US/docs/Web/Security/Practical_implementation_guides/Cookies)                                        | High    | Medium     | Yes      | Set all cookies as restrictively as possible.                                                                                                                                               |
 | [CORP implementation](/en-US/docs/Web/Security/Practical_implementation_guides/CORP)                                                   | High    | Medium     | Yes      | Protect against speculative side-channel attacks by using Cross-Origin Resource Policy (CORP).                                                                                              |
diff --git a/files/en-us/web/security/types_of_attacks/index.md b/files/en-us/web/security/types_of_attacks/index.md
index eb8bd64dedf458a..e534cb5abd75b42 100644
--- a/files/en-us/web/security/types_of_attacks/index.md
+++ b/files/en-us/web/security/types_of_attacks/index.md
@@ -8,9 +8,9 @@ page-type: guide
 
 This article describes various types of security attacks and techniques to mitigate them.
 
-## Click-jacking
+## Clickjacking
 
-[Clickjacking](/en-US/docs/Glossary/Clickjacking) is the practice of tricking a user into clicking on a link, button, etc. that is other than what the user thinks it is. This can be used, for example, to steal login credentials or to get the user's unwitting permission to install a piece of malware. (Click-jacking is sometimes called "user interface redressing", though this is a misuse of the term "redress".)
+[Clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) is the practice of tricking a user into clicking on a link, button, etc. that is other than what the user thinks it is. This can be used, for example, to steal login credentials or to get the user's unwitting permission to install a piece of malware. (Click-jacking is sometimes called "user interface redressing", though this is a misuse of the term "redress".)
 
 ## Cross-site scripting (XSS)