Fixes for gene1wood review comments

mdn · chrisdavidmills · Jun 24, 2024 · May 28, 2024 · May 28, 2024 · May 28, 2024
commit 05299298b43860a7e8ce0cb0221a1a1894abffda
@@ -10,7 +10,7 @@ Limit access to cookies as much as possible.
 
 ## Problem
 
-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.
+Cookies often contain session identifiers or other sensitive information. Unauthorized 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
 
@@ -32,9 +32,9 @@ To minimize the scope for cookie vulnerabilities on your site, limit access to c
 - `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.
 - `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. `SameSite` is also useful in protecting against [Clickjacking](/en-US/docs/Glossary/Clickjacking) attacks, in cases that rely on the user being authenticated. You should use one of the following two values:
+ - : Forbid sending cookies via cross-origin requests (for example from {{htmlelement("img")}} elements) using `SameSite`. This is a strong [anti-CSRF](/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention) measure. `SameSite` is also useful in protecting against [Clickjacking](/en-US/docs/Glossary/Clickjacking) attacks in cases that rely on the user being authenticated. 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.
 

@@ -6,7 +6,7 @@ page-type: guide
 
 {{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
 
-Users frequently input sensitive data on websites, such as names, addresses, and banking details. As a web developer, it's crucial to protect this information from bad actors who use a wide range of exploits to steal such information and use it for personal gain. The focus of [web security](/en-US/docs/Web/Security) is to help you protect your website against these exploits and secure your users' sensitive data.
+Users frequently input sensitive data on websites, such as names, addresses, passwords, and banking details. As a web developer, it's crucial to protect this information from bad actors who use a wide range of exploits to steal such information and use it for personal gain. The focus of [web security](/en-US/docs/Web/Security) is to help you protect your website against these exploits and secure your users' sensitive data.
 
 This page lists guides that detail the best practices for implementing security features on websites. While these guides do not cover all possible security scenarios and cannot guarantee complete security of your website, following the information and best practices in these guides will make your sites significantly more secure.
 

@@ -16,7 +16,9 @@ Many factors can increase the load on your website; this includes web crawlers.
 
 Use `robots.txt` to reduce website load and stop unsuitable content appearing in search results.
 
-Using `robots.txt` is optional and sites should use it only for these purposes. It should not be used as a way to prevent the disclosure of private information or to hide portions of a website. While using this file can prevent these sites from appearing in search engine results, it does not secure websites against attackers who can still determine such details because `robots.txt` is publicly accessible.
+Using `robots.txt` is optional and sites should use it only for these purposes. It should not be used as a way to prevent the disclosure of private information or to hide portions of a website. While using this file can prevent pages from appearing in search engine results, it does not secure websites against attackers. In fact, it can help them: `robots.txt` is publicly accessible, and by adding your sensitive page paths to it, you are showing attackers exactly where they are.
+
+Also be aware that some robots will ignore your `robots.txt` file, for example, malware robots and email address harvesters.
 
 ## Examples
 
@@ -36,4 +38,4 @@ Disallow: /secret/admin-interface
 
 ## See also
 
-- [About /robots.txt](https://www.robotstxt.org/robotstxt.html) on `robotstxt.org`.
+- [About /robots.txt](https://www.robotstxt.org/robotstxt.html) on `robotstxt.org`
@@ -10,9 +10,9 @@ page-type: guide
 
 ## Problem
 
-Attackers can modify the contents of JavaScript libraries hosted on content delivery networks (CDNs), creating vulnerabilities in all websites that use these libraries.
+If an attacker exploited a content delivery network (CDN) and modified the contents of JavaScript libraries hosted on that CDN, it would create vulnerabilities in all websites that use those libraries.
 
-For example, JavaScript code hosted on `library.org` that is loaded from `example.org` can access the entire contents of `example.org`. If an attacker modifies this resource to include malicious code, it could alter download links, deface the site, steal credentials, cause denial-of-service (DoS) attacks, and so on.
+For example, JavaScript hosted on `library.org` that is loaded from `example.org` can access the entire contents of `example.org`. If an attacker modifies that hosted JavaScript to include malicious code, it could alter download links, deface the site, steal credentials, cause denial-of-service (DoS) attacks, and so on.
 
 ## Solution
 

@@ -6,19 +6,19 @@ page-type: guide
 
 {{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
 
-[Transport Layer Security (TLS)](/en-US/docs/Glossary/TLS) provides assurances about the confidentiality, authentication, and integrity of all communications, and as such, should be used for all inbound and outbound website communications.
+[Transport Layer Security (TLS)](/en-US/docs/Glossary/TLS) provides assurances about the confidentiality, authenticity, and integrity of all communications, and as such, should be used for all inbound and outbound website communications.
 
 ## TLS configuration
 
 ### Problem
 
-If data is sent over the web unencrypted, it can be intercepted and read by third parties, who can modify and/or steal the data — this is often known as a [manipulator-in-the-middle](/en-US/docs/Glossary/MitM) (MiTM) attack. MiTM attacks have severe consequences for the security of your system.
+If data is sent over the web unencrypted, it can be intercepted by third parties, who can access and modify the data — this is often known as a [manipulator-in-the-middle](/en-US/docs/Glossary/MitM) (MiTM) attack. MiTM attacks have severe consequences for the security of your system.
 
-All requests and responses should, therefore, be sent over HTTPS. The modern web practically enforces this — all browsers are moving towards requiring [HTTPS](/en-US/docs/Glossary/HTTPS) by default, and many web features can only be used in a [secure context](/en-US/docs/Web/Security/Secure_Contexts).
+All requests and responses should therefore be sent over HTTPS, which uses TLS to encrypt the data. The modern web practically enforces this — all browsers are moving towards requiring [HTTPS](/en-US/docs/Glossary/HTTPS) by default, and many web features can only be used in a [secure context](/en-US/docs/Web/Security/Secure_Contexts).
 
 ### Solution
 
-You should set up your server software to use a robust TLS configuration that enforces HTTPS. There are several TLS configuration generators available that can help with this, for example, the Mozilla [SSL Configuration Generator](https://ssl-config.mozilla.org/). This tool provides several options based on Mozilla's [TLS guidelines](https://wiki.mozilla.org/Security/Server_Side_TLS).
+You should set up your server software to use a secure configuration that enforces the use of HTTPS with safe TLS settings. There are several TLS configuration generators available that can help with this, for example, the Mozilla [SSL Configuration Generator](https://ssl-config.mozilla.org/). This tool provides several options based on Mozilla's [TLS guidelines](https://wiki.mozilla.org/Security/Server_Side_TLS).
 
 ## Resource loading
 
@@ -38,7 +38,7 @@ Similarly, attempts to load passive content such as images insecurely, although
 <img src="http://very.badssl.com/image.jpg" />
 ```
 
-Although modern browsers make it evident when websites are loading resources insecurely, these errors still occur with significant frequency.
+Although modern browsers make it evident when websites are loading resources insecurely, these errors still occur across the web with significant frequency.
 
 ### Solution
 
@@ -56,9 +56,9 @@ In this example, HTTPS is being used correctly to load a JavaScript library:
 
 ### Problem
 
-Websites may continue to listen on port 80 (HTTP) to prevent connection errors when users type a URL into their address bar, as initial browser connections are made via HTTP. This poses an initial security risk during the first connection to sites.
+Websites may continue to listen on port 80 (HTTP) to prevent connection errors when users type a URL into their address bar, as initial browser connections are often made via HTTP. This poses an initial security risk during the first connection to sites as that connection is not protected by TLS.
 
-In addition, sites should avoid redirections from HTTP to HTTPS on a different host, as this prevents `Strict-Transport-Security` from being set (see [HTTP Strict Transport Security](#http_strict_transport_security)).
+In addition, sites should avoid redirections from HTTP on one host to HTTPS on a different host, as this prevents `Strict-Transport-Security` from being set for the first host (see [HTTP Strict Transport Security](#http_strict_transport_security)).
 
 ### Solution
 
@@ -96,26 +96,26 @@ Redirect `site.example.org` from HTTP to HTTPS, using Apache:
 
 ### Problem
 
-To prevent [manipulator-in-the-middle](/en-US/docs/Glossary/MitM) (MiTM) attacks, browsers should only connect to sites via HTTPS, regardless of the chosen protocol.
+To prevent [manipulator-in-the-middle](/en-US/docs/Glossary/MitM) (MiTM) attacks, browsers should only connect to sites via HTTPS.
 
 ### Solution
 
-HTTP [`Strict-Transport-Security`](/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (HSTS) is an HTTP header that notifies browsers to connect to a given site only over HTTPS, even if the originally specified scheme was HTTP. Browsers with HSTS set for a given site will automatically upgrade all requests to HTTPS. HSTS also tells browsers to treat TLS and certificate-related errors more strictly by disabling the ability to bypass the error page.
+HTTP [`Strict-Transport-Security`](/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (HSTS) is an HTTP header that notifies browsers to connect to a given site only over HTTPS, even if the originally specified scheme was HTTP. Browsers with HSTS set for a given site will automatically upgrade all requests to HTTPS for that site. HSTS also tells browsers to treat TLS and certificate-related errors more strictly by disabling the ability to bypass the certificate error page.
 
 `Strict-Transport-Security` supports the following directives:
 
 - `max-age`
  - : Sets the duration, in seconds, for which browsers will redirect to HTTPS.
 - `includeSubDomains` {{optional_inline}}
- - : Specifies whether browsers should upgrade requests on all subdomains to HTTPS. For example, setting `includeSubDomains` on `domain.example.com` will ensure that requests to `host1.domain.example.com` and `host2.domain.example.com` are upgraded.
+ - : Specifies whether browsers should upgrade requests on all subdomains to HTTPS. For example, setting `includeSubDomains` on `domain.example.com` will ensure that requests to `host1.domain.example.com` and `host2.domain.example.com` are upgraded in addition to `domain.example.com`.
 - `preload` {{optional_inline}}
- - : Specifies whether the site should be preloaded. Including this directive means your site will be included in the [HSTS preload list](https://hstspreload.org/).
+ - : Specifies whether the site should be preloaded. Including this directive means your site can be included in the [HSTS preload list](https://hstspreload.org/).
 
 Follow these steps to correctly implement HSTS on your website:
 
 1. Set a `max-age` value of at least six months (`15768000`). Longer periods, such as two years (`63072000`), are recommended. Once this value is set, the site must continue to support HTTPS until the expiry time is reached.
 2. If possible, set `includeSubDomains` to improve security on all subdomains. Careful testing is needed when setting this directive because it could disable sites on subdomains that don't yet have HTTPS enabled.
-3. If possible, set `preload` to include your website in the [HSTS preload list](https://hstspreload.org/). Web browsers will perform HTTPS upgrades to preloaded sites before receiving the initial `Strict-Transport-Security` header. This prevents [downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) upon first use and is recommended for all high-risk websites. Note that being included in the HSTS preload list also requires `includeSubDomains` to be set and `max-age` to be set to a minimum of 1 year (`31536000`).
+3. If possible, set `preload` to make it possible to include your website in the HSTS preload list. To add it to the list, visit https://hstspreload.org/ and enter your site URL into the form at the top of the page, fixing any issues that it mentions. Web browsers will perform HTTPS upgrades to preloaded sites before receiving the initial `Strict-Transport-Security` header. This prevents [downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) upon first use and is recommended for all high-risk websites. Note that being included in the HSTS preload list also requires `includeSubDomains` to be set and `max-age` to be set to a minimum of 1 year (`31536000`).
 
 ### Examples