Add Observatory docs to MDN

files/en-us/learn/server-side/apache_configuration_htaccess/index.md

@@ -494,7 +494,7 @@ To prevent referrer leakage entirely, specify the `no-referrer` value instead. N
 
 Use services like the ones below to check your `Referrer-Policy`:
 
-- [MDN Observatory](/en-US/observatory/)
+- [HTTP Observatory](/en-US/observatory/)
 - [securityheaders.com](https://securityheaders.com/)
 
 ```apacheconf

files/en-us/web/http/headers/x-content-type-options/index.md

@@ -72,7 +72,7 @@ X-Content-Type-Options: nosniff
 
 - {{HTTPHeader("Content-Type")}}
 - The [original definition](https://docs.microsoft.com/archive/blogs/ie/ie8-security-part-vi-beta-2-update) of X-Content-Type-Options by Microsoft.
-- Use [MDN Observatory](/en-US/observatory/) to test the security configuration of websites (including this header).
+- Use [HTTP Observatory](/en-US/observatory/) to test the security configuration of websites (including this header).
 - [Mitigating MIME Confusion Attacks in Firefox](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/)
 - [Cross-Origin Read Blocking (CORB)](https://fetch.spec.whatwg.org/#corb)
 - [Google Docs CORB explainer](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md)

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

@@ -53,7 +53,7 @@ Helpful tools and resources for understanding and debugging HTTP.
 
 - [Firefox Developer Tools](https://firefox-source-docs.mozilla.org/devtools-user/index.html)
   - : [Network monitor](https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/index.html)
-- [Mozilla Observatory](https://observatory.mozilla.org/)
+- [HTTP Observatory](/en-US/observatory/)
   - : A project designed to help developers, system administrators, and security professionals configure their sites safely and securely.
 - [RedBot](https://redbot.org/)
   - : Tools to check your cache-related headers.

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

@@ -163,7 +163,7 @@ The following features can help guard against clickjacking:
 
 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_guides).
 
-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.
+Some of these guides are directly related to the [HTTP 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.
 
 ## See also
 

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

@@ -34,9 +34,13 @@ To minimize the scope for cookie vulnerabilities on your site, limit access to c
 - `Path`
   - : Cookies should be set to the most restrictive `Path` possible.
 - `SameSite`
-  - : 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.
+
+  - : Forbid sending cookies via cross-origin requests (for example from {{htmlelement("img")}} elements) using `SameSite`. You should use one of the following two values:
+
+    - `SameSite=Strict`: Only send the cookie when your site is directly navigated to. This is a strong [anti-CSRF](/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention) measure, so use this value if possible.
+    - `SameSite=Lax`: Additionally send the cookie when navigating to your site from another site. This is the default behavior used in modern browsers if no `SameSite` directive is set, and should only 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.
 
 ## Examples
 

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

@@ -6,28 +6,51 @@ page-type: guide
 
 {{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
 
-Cross-Origin Resource Policy is set by the {{httpheader("Cross-Origin-Resource-Policy")}} header, which lets websites and applications opt in to protection against certain requests from other origins (such as those issued with elements like {{htmlelement("script")}} and {{htmlelement("img")}}).
+Cross-Origin Resource Policy (CORP) is set by the {{httpheader("Cross-Origin-Resource-Policy")}} header, which lets websites and applications opt in to protection against certain cross-origin requests (such as those made by the {{htmlelement("script")}} and {{htmlelement("img")}} elements).
 
 ## Problem
 
-Side-channel hardware vulnerabilities such as [Meltdown](<https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)>) and [Spectre](<https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>) allow sensitive data disclosure due to a race condition arising as part of speculative execution functionality designed to improve performance.
+Some side-channel hardware vulnerabilities (also known as Cross-site leaks, or XS-Leaks), such as [Meltdown](<https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)>) and [Spectre](<https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>), exploit a race condition arising as part of speculative execution functionality of modern processors. This functionality is designed to improve performance but can be manipulated to disclose sensitive data.
 
 ## Solution
 
-Use `Cross-Origin-Resource-Policy` to block [`no-cors`](/en-US/docs/Web/API/fetch#mode) cross-origin and/or cross-site requests to the given resource. Use the most restrictive value possible for your site: `same-site` or `same-origin` are recommended.
+Use `Cross-Origin-Resource-Policy` to block [`no-cors`](/en-US/docs/Web/API/fetch#mode) cross-origin requests to given resources. As this policy is expressed via a response header, the actual request is not prevented. Instead, the browser prevents the result from being leaked by stripping the response body.
 
-As this policy is expressed via a response header, the actual request is not prevented — rather, the browser prevents the result from being leaked by stripping the response body.
+The possible values are:
+
+- `same-origin`
+  - : Limits resource access to requests coming from the same origin. This is recommended for requests for sensitive user information, or requests to private APIs.
+- `same-site`
+  - : Limits resource access to requests coming from the same site. This is recommended for requests to origins whose functionality is shared across several other same-site origins. Examples include a company CDN that serves static resources, and a single sign-on (SSO) app that handles authentication.
+- `cross-origin`
+  - : Allows resources to be accessed by cross-origin requests. This is recommended only for requests to widely-used origins, such as public CDNs or widgets. This is the default value if `Cross-Origin-Resource-Policy` is not set.
+
+Set the most restrictive value possible for your site.
+
+If your use case requires `cross-origin` access, opt into a better default by sending a {{httpheader("Cross-Origin-Embedder-Policy")}} header. This will prevent loading of cross-origin resources that don't also explicitly send a `Cross-Origin-Resource-Policy: cross-origin` header.
 
 ## Examples
 
-Instruct browsers to disallow cross-origin no-cors requests:
+Instruct browsers to disallow cross-origin requests made in `no-cors` mode:
 
 ```http
 Cross-Origin-Resource-Policy: same-origin
 ```
 
+Instruct browsers to allow cross-origin resource access, including access to features with unthrottled timers (such as {{jsxref("SharedArrayBuffer")}} objects or {{domxref("Performance.now()")}}):
+
+```http
+Cross-Origin-Resource-Policy: same-origin
+Cross-Origin-Embedder-Policy: require-corp
+```
+
+This also permits such resources to be embedded.
+
 ## See also
 
+- [Consider deploying Cross-Origin Resource Policy](resourcepolicy.fyi)
+- [XS-Leaks Wiki](https://xsleaks.dev/)
 - [`Access-Control-Allow-Origin`](/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)
-- [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/CORS)
 - [`Cross-Origin-Embedder-Policy`](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)
+- [`Cross-Origin-Opener-Policy`](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy)
+- [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/CORS)