More fixes for dipikabh review comments

files/en-us/web/security/index.md

@@ -53,7 +53,7 @@ Related topics:
 - [HTTP Strict-Transport-Security](/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)
   - : The `Strict-Transport-Security` [HTTP](/en-US/docs/Web/HTTP) header lets a website specify that it may only be accessed using HTTPS.
 - [Certificate Transparency](/en-US/docs/Web/Security/Certificate_Transparency)
-  - : Certificate Transparency is an open framework designed to protect against and monitor for certificate misissuance. Newly issued certificates are 'logged' to publicly run, often independent CT logs. These provide append-only, cryptographically assured records of issued TLS certificates.
+  - : Certificate Transparency (CT) is an open framework designed to protect against and monitor for certificate misissuance. Newly issued certificates are 'logged' to publicly run, often independent CT logs. These provide append-only, cryptographically assured records of issued TLS certificates.
 - [Mixed content](/en-US/docs/Web/Security/Mixed_content)
   - : An HTTPS page that includes content fetched using [cleartext](/en-US/docs/Glossary/Plaintext) HTTP is called a **mixed content** page. Pages like this are only partially encrypted, leaving the unencrypted content accessible to sniffers and man-in-the-middle attackers.
 - [How to fix a website with blocked mixed content](/en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content)
@@ -163,7 +163,7 @@ The following features can help guard against clickjacking:
 
 ## Practical security implementation guides
 
-Our set of [Practical security implementation guides](/en-US/docs/Web/Security/Practical_implementation_guides) offer comprehensive instructions for implementing security features effectively on websites.
+To get comprehensive instructions for implementing security features effectively on websites and to ensure you're following best practices, see our set of [Practical security implementation guides](/en-US/docs/Web/Security/Practical_implementation).
 
 Some of these guides are directly related to the [MDN Observatory](/en-US/observatory/) tool. Observatory performs security audits on a website and provides a grade and score along with recommendations for fixing the security issues it finds. These guides explain how to resolve issues surfaced by the MDN Observatory tests: the tool links to the relevant guide for each issue, helping guide you towards an effective resolution. Interestingly, Mozilla's internal developer teams use this guidance when implementing websites to ensure that security best practices are applied.
 

files/en-us/web/security/practical_implementation_guides/clickjacking/index.md

@@ -4,11 +4,13 @@ slug: Web/Security/Practical_implementation_guides/Clickjacking
 page-type: guide
 ---
 
-The [Content Security Policy](/en-US/docs/Web/HTTP/CSP) [`frame-ancestors`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive and the [`X-Frame-Options`](/en-US/docs/Web/HTTP/Headers/X-Frame-Options) header provide control over how your site may be embedded within an {{htmlelement("iframe")}}, helping to prevent clickjacking.
+{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+
+The [Content Security Policy](/en-US/docs/Web/HTTP/CSP) [`frame-ancestors`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive and the [`X-Frame-Options`](/en-US/docs/Web/HTTP/Headers/X-Frame-Options) header provide control over how your site may be embedded within an {{htmlelement("iframe")}} on another site. These features help prevent clickjacking.
 
 ## Problem
 
-[Clickjacking](/en-US/docs/Glossary/Clickjacking) is an attack whereby malicious sites trick users into clicking links on their site by making it look 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>`, and then positioning a button, link or other UI feature on top of that content to make the user think they are interacting with their trusted site, whereas in actual fact they are interacting with the malicious site.
+[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.
 
 ## Solution
 
@@ -19,40 +21,38 @@ Use the HTTP headers as required:
 
 The recommendation is to use both unless you know you don't need support for the older browser set.
 
-You should deny all embedding attempts unless you really need to embed the site. Provide the minimum embedding allowance necessary. Sites that require the ability to be embedded in an `<iframe>` must employ JavaScript defenses and a robust {{HTTPHeader("Content-Security-Policy")}} to prevent clickjacking from malicious origins.
+You should deny all attempts to embed your site unless you really need to. When embedding is required, provide the minimum embedding allowance necessary. Sites that require the ability to be embedded in an `<iframe>` must use JavaScript defenses and a robust {{HTTPHeader("Content-Security-Policy")}} to prevent clickjacking from malicious origins.
 
-Equivalent options for each are as follows:
+The equivalent options for each setting are as follows:
 
 | CSP value                             | `X-Frame-Options` value         | Description                                         |
 | ------------------------------------- | ------------------------------- | --------------------------------------------------- |
 | `frame-ancestors 'none'`              | `DENY`                          | Deny all embedding attempts.                        |
-| `frame-ancestors 'self'`              | `SAMEORIGIN`                    | Only allow same-origin embedding attempts.          |
+| `frame-ancestors 'self'`              | `SAMEORIGIN`                    | Allow only same-origin embedding attempts.          |
 | `frame-ancestors https://example.org` | `ALLOWFROM https://example.org` | Allow embedding attempts from the specified domain. |
 
 > **Note:** The `X-Frame-Options: ALLOWFROM https://example.org` syntax is deprecated, and most browsers ignore it. You are recommend to set `DENY` in such cases instead, and/or rely on the CSP equivalent.
 
 ## Examples
 
-Block site from being embedded with X-Frame-Options and CSP:
+Block the site from being embedded using `X-Frame-Options` and CSP:
 
 ```http
 Content-Security-Policy: frame-ancestors 'none'
 X-Frame-Options: DENY
 ```
 
-Only allow the site to be embedded same-origin pages:
+Allow the site to be embedded only on same-origin pages:
 
 ```http
 Content-Security-Policy: frame-ancestors 'self'
 X-Frame-Options: SAMEORIGIN
 ```
 
-Only allow example.org to embed the site:
+Only allow `example.org` to embed the site:
 
 ```http
 Content-Security-Policy: frame-ancestors https://example.org
 # Block embedding in browsers that don't support CSP2
 X-Frame-Options: DENY
 ```
-
-{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

files/en-us/web/security/practical_implementation_guides/cookies/index.md

@@ -4,61 +4,61 @@ slug: Web/Security/Practical_implementation_guides/Cookies
 page-type: guide
 ---
 
-Access to cookies should limited as much as possible.
+{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+
+Limit access to cookies as much as possible.
 
 ## Problem
 
-Cookies often contain session identifiers or other sensitive information. Unwanted access to cookies can therefore cause a whole of problems, including [Privacy](/en-US/docs/Web/Privacy) issues, Cross-Site Scripting ({{Glossary("Cross-site_scripting", "XSS")}}) attacks, Cross-Site Request Forgery ([CSRF](/en-US/docs/Glossary/CSRF)) attacks, and more.
+Cookies often contain session identifiers or other sensitive information. Unwanted access to cookies, therefore, can cause a host of problems, including [privacy](/en-US/docs/Web/Privacy) issues, ({{Glossary("Cross-site_scripting", "Cross-site scripting (XSS)")}}) attacks, Cross-site request forgery ([CSRF](/en-US/docs/Glossary/CSRF)) attacks, and more.
 
 ## Solution
 
-To minimize the scope for cookie vulnerabilities on your site, limit access to cookies as much as possible.
-
-This can be done via sensible usage of the following directives of the [`Set-Cookie`](/en-US/docs/Web/HTTP/Headers/Set-Cookie) header:
+To minimize the scope for cookie vulnerabilities on your site, limit access to cookies as much as possible. This can be done via sensible usage of the following directives of the [`Set-Cookie`](/en-US/docs/Web/HTTP/Headers/Set-Cookie) header:
 
 - `Name`
   - : Cookie names should be prepended with either `__Secure-` or `__Host-` to prevent cookies from being overwritten by insecure sources.
     - Use `__Host-` for all cookies needed only on a specific domain (no subdomains) where `Path` is set to `/`.
-    - Use `__Secure-` for all other cookies sent from secure origins (HTTPS).
+    - Use `__Secure-` for all other cookies sent from secure origins ([HTTPS](/en-US/docs/Glossary/HTTPS)).
 - `Secure`
-  - : All cookies must be set with the `Secure` flag, indicating that they should only be sent over HTTPS. [HTTP Strict Transport Security](/en-US/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security) can also be used to prevent transmission over HTTP, but ideally `Secure` should be set on cookies as well.
+  - : All cookies must be set with the `Secure` directive, indicating that they should only be sent over HTTPS. [HTTP Strict Transport Security](/en-US/docs/Web/Security/Practical_implementation_guides/TLS#http_strict_transport_security) (HSTS) can also be used to prevent transmission over HTTP, but ideally `Secure` should be set on cookies as well.
 - `HttpOnly`
-  - : Cookies that don't require access from JavaScript should be set with the `HttpOnly` flag. It is particularly important that session identifiers don't have JavaScript access, to help prevent attacks such as CSRF.
+  - : Cookies that don't require access from JavaScript should have the `HttpOnly` directive set, to block access (for example, from {{domxref("Document.cookie")}}). It is particularly important that session identifiers don't have JavaScript access, to help prevent attacks such as CSRF.
 - `Expires` and `Max-Age`
   - : Cookies should expire as soon as they are no longer needed. Session identifiers in particular should expire as quickly as possible. `Expires` is preferred unless you need to support IE < 8, in which case use `Max-Age`.
     - `Expires`: Sets an absolute expiration date for a given cookie.
     - `Max-Age`: Sets a relative expiration date for a given cookie.
-      > **Note:** `Expires` has been available for longer than `Max-Age`, however `Max-Age` is less error-prone, and takes precedence when both are set. The rationale behind this is that when you set an `Expires` date and time, they're relative to the client the cookie is being set on. If the server is set to a different time, this could cause errors.
+      > **Note:** `Expires` has been available for longer than `Max-Age`; however, `Max-Age` is less error-prone, and takes precedence when both are set. The rationale behind this is that when you set an `Expires` date and time, they're relative to the client on which the cookie is being set. If the server is set to a different time, this could cause errors.
 - `Domain`
   - : Cookies should only have a `Domain` set if they need to be accessible on other domains; this should be set to the most restrictive domain possible.
 - `Path`
-  - : Cookies should be set to the most restrictive `Path` possible; for most applications this will be set to the root directory.
+  - : Cookies should be set to the most restrictive `Path` possible; for most applications, this will be set to the root directory.
 - `SameSite`
   - : Forbid sending the cookie via cross-origin requests (for example from {{htmlelement("img")}} element), as a strong [anti-CSRF](/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention) measure. You should use one of the following two values:
     - `SameSite=Strict`: Only send the cookie when your site is directly navigated to.
     - `SameSite=Lax`: Additionally send the cookie when navigating to your site from another site. Note that this is the default behavior used in modern browsers if no `SameSite` directive is set.
 
 ## Examples
 
-Session identifier cookie, only accessible on the current host, which gets purged when the user closes their browser:
+Set a session identifier cookie that is only accessible on the current host and expires when the user closes their browser:
 
 ```http
 Set-Cookie: MOZSESSIONID=980e5da39d4b472b9f504cac9; Path=/; Secure; HttpOnly
 ```
 
-Session identifier for all `example.org` sites that expires after 30 days, specified using the `__Secure-` prefix. This cookie is not sent cross-origin, but is sent when navigating to any site from another site:
+Set a session identifier for all `example.org` sites that expires after 30 days, using the `__Secure-` prefix. This cookie is not sent cross-origin, but is sent when navigating to any site from another site:
 
 ```http
 Set-Cookie: __Secure-MOZSESSIONID=7307d70a86bd4ab5a00499762; Max-Age=2592000; Domain=example.org; Path=/; Secure; HttpOnly; SameSite=Lax
 ```
 
-Sets a long-lived cookie for the current host, accessible by JavaScript, when the user accepts the terms of service. This cookie is sent when navigating to your site from another site, for example by clicking a link:
+Set a long-lived cookie for the current host, accessible by JavaScript, when the user accepts the terms of service. This cookie is sent when navigating to your site from another site, such as by clicking a link:
 
 ```http
 Set-Cookie: __Host-ACCEPTEDTOS=true; Expires=Fri, 31 Dec 9999 23:59:59 GMT; Path=/; Secure; SameSite=Lax
 ```
 
-Session identifier used for a secure (HTTPS) site. It isn't sent from cross-origin requests, nor is it sent when navigating to your site from another site. When used in conjunction with other anti-CSRF measures, this is a very strong way to defend your site against CSRF attacks:
+Use a session identifier for a secure (HTTPS) site. It isn't sent from cross-origin requests, nor when navigating to your site from another site. When used in conjunction with other anti-CSRF measures, this provides a very strong defense for your site against CSRF attacks:
 
 ```http
 Set-Cookie: __Host-BMOSESSIONID=YnVnemlsbGE=; Max-Age=2592000; Path=/; Secure; HttpOnly; SameSite=Strict
@@ -69,6 +69,4 @@ Set-Cookie: __Host-BMOSESSIONID=YnVnemlsbGE=; Max-Age=2592000; Path=/; Secure; H
 - [Using HTTP cookies](/en-US/docs/Web/HTTP/Cookies)
 - [Third-party cookies](/en-US/docs/Web/Privacy/Third-party_cookies)
 - [`Document.cookie`: Security](/en-US/docs/Web/API/Document/cookie#security)
-- [RFC 6265 (HTTP Cookies)](https://datatracker.ietf.org/doc/html/rfc6265)
-
-{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+- [RFC 6265 (HTTP Cookies)](https://datatracker.ietf.org/doc/html/rfc6265) (2011)

files/en-us/web/security/practical_implementation_guides/cors/index.md

@@ -4,6 +4,8 @@ slug: Web/Security/Practical_implementation_guides/CORS
 page-type: guide
 ---
 
+{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+
 Cross-origin Resource Sharing (CORS) is handled using [`Access-Control-Allow-Origin`](/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) and related headers. `Access-Control-Allow-Origin` defines which non-same origins are allowed to make requests to pages on your domain (i.e. via [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) or [`fetch()`](/en-US/docs/Web/API/fetch)).
 
 ## Problem
@@ -49,5 +51,3 @@ Access-Control-Allow-Origin: https://random-dashboard.example.org
 - [`Origin`](/en-US/docs/Web/HTTP/Headers/Origin)
 - [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/CORS)
 - [CORS for Developers](https://w3c.github.io/webappsec-cors-for-developers/) from W3C (2016)
-
-{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

files/en-us/web/security/practical_implementation_guides/csp/index.md

@@ -4,6 +4,8 @@ slug: Web/Security/Practical_implementation_guides/CSP
 page-type: guide
 ---
 
+{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+
 The [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) HTTP header provides fine-grained control over where resources on their site can be loaded from.
 
 ## Problem
@@ -113,5 +115,3 @@ Content-Security-Policy: default-src 'none'; frame-ancestors 'none'
 
 - [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP)
 - [CSP evaluator](https://csp-evaluator.withgoogle.com/)
-
-{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

files/en-us/web/security/practical_implementation_guides/csrf_prevention/index.md

@@ -4,6 +4,8 @@ slug: Web/Security/Practical_implementation_guides/CSRF_prevention
 page-type: guide
 ---
 
+{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
+
 Cross-site request forgeries ([CSRF](/en-US/docs/Glossary/CSRF)) can be protected against via `SameSite` cookies and anti-CSRF tokens.
 
 ## Problem
@@ -73,5 +75,3 @@ httpRequest.setRequestHeader("X-CSRF-Token", token); // add it as an X-CSRF-Toke
 - [Types of attacks: Cross-site request forgery (CSRF)](/en-US/docs/Web/Security/Types_of_attacks#cross-site_request_forgery_csrf)
 - [Wikipedia on CRSF Attacks and Prevention](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention)
 - [OWASP CSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
-
-{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}