diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt index 8aec61bf7ca7605..fcf30a86788edfe 100644 --- a/files/en-us/_redirects.txt +++ b/files/en-us/_redirects.txt @@ -3991,7 +3991,7 @@ /en-US/docs/HTTP_Pipelining_FAQ /en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x /en-US/docs/HTTP_Transaction_Model /en-US/docs/Web/HTTP /en-US/docs/HTTP_access_control /en-US/docs/Web/HTTP/CORS -/en-US/docs/How_to_Turn_Off_Form_Autocompletion /en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion +/en-US/docs/How_to_Turn_Off_Form_Autocompletion /en-US/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion /en-US/docs/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL /en-US/docs/Web/API/XMLHttpRequest /en-US/docs/How_to_create_a_DOM_tree /en-US/docs/Web/API/Document_Object_Model/Using_the_Document_Object_Model /en-US/docs/How_to_start_contributions_to_Mozilla /en-US/docs/MDN/Community/Contributing/Getting_started @@ -6793,7 +6793,7 @@ /en-US/docs/Security/MixedContent/fix_website_with_mixed_content /en-US/docs/Web/Security/Mixed_content#developer_console /en-US/docs/Security/Mixed_content /en-US/docs/Web/Security/Mixed_content /en-US/docs/Security/Mixed_content/How_to_fix_website_with_mixed_content /en-US/docs/Web/Security/Mixed_content#developer_console -/en-US/docs/Security/Securing_your_site /en-US/docs/Web/Security/Securing_your_site +/en-US/docs/Security/Securing_your_site /en-US/docs/Web/Security/Practical_implementation_guides /en-US/docs/Security/Weak_Signature_Algorithm /en-US/docs/Web/Security/Weak_Signature_Algorithm /en-US/docs/Security_changes_in_Firefox_3.1 /en-US/docs/Mozilla/Firefox/Releases/3.5/Security_changes /en-US/docs/Security_changes_in_Firefox_3.5 /en-US/docs/Mozilla/Firefox/Releases/3.5/Security_changes @@ -13026,7 +13026,9 @@ /en-US/docs/Web/Security/HTTP_strict_transport_security /en-US/docs/Web/HTTP/Headers/Strict-Transport-Security /en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content /en-US/docs/Web/Security/Mixed_content#developer_console /en-US/docs/Web/Security/Public_Key_Pinning /en-US/docs/Web/Security/Certificate_Transparency +/en-US/docs/Web/Security/Securing_your_site /en-US/docs/Web/Security/Practical_implementation_guides /en-US/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types /en-US/docs/Learn/Server-side/Configuring_server_MIME_types +/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion /en-US/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion /en-US/docs/Web/WebGL /en-US/docs/Web/API/WebGL_API /en-US/docs/Web/WebGL/Adding_2D_content_to_a_WebGL_context /en-US/docs/Web/API/WebGL_API/Tutorial/Adding_2D_content_to_a_WebGL_context /en-US/docs/Web/WebGL/Animating_objects_with_WebGL /en-US/docs/Web/API/WebGL_API/Tutorial/Animating_objects_with_WebGL diff --git a/files/en-us/_wikihistory.json b/files/en-us/_wikihistory.json index 270c6dadf7f32a0..1160b3187a32599 100644 --- a/files/en-us/_wikihistory.json +++ b/files/en-us/_wikihistory.json @@ -126832,6 +126832,72 @@ "evilpie" ] }, + "Web/Security/Practical_implementation": { + "modified": "2020-06-03T13:43:23.202Z", + "contributors": [ + "jswisher", + "mfuji09", + "germain", + "sideshowbarker", + "patizenyapetshop", + "larsonreever", + "SebastienParis", + "tlubitz", + "david_ross", + "mbm", + "chrisdavidmills", + "JazibZaman", + "hashedhyphen", + "marumari", + "evilpie", + "Sheppy", + "teoli" + ] + }, + "Web/Security/Practical_implementation/Turning_off_form_autocompletion": { + "modified": "2020-07-10T21:28:54.938Z", + "contributors": [ + "patrickhlauke", + "mfuji09", + "mnoorenberghe", + "leela52452", + "jswisher", + "sruthiveeragandham", + "Nomeh_Uchenna_Gabriel", + "mfluehr", + "WilliamC07", + "hjuhlin", + "chrisdavidmills", + "LouisLazaris", + "devinea2", + "steduardo", + "terrylinooo", + "kbagot", + "stutrek", + "Didglee", + "rottina", + "Delapouite", + "wbamberg", + "John99", + "Manishearth", + "Sheppy", + "ConcreteGannet", + "teoli", + "contrebis", + "dhodder", + "David-Sarah Hopwood", + "George3", + "LonelyPixel", + "Brianegge", + "NickolayBot", + "Andreas Wuest", + "Brycenesbitt", + "Callek", + "VicMan", + "Pmsyyz", + "Mathieu Deaudelin" + ] + }, "Web/Security/Referer_header:_privacy_and_security_concerns": { "modified": "2020-07-22T14:05:46.803Z", "contributors": [ @@ -126936,72 +127002,6 @@ "Annevk" ] }, - "Web/Security/Securing_your_site": { - "modified": "2020-06-03T13:43:23.202Z", - "contributors": [ - "jswisher", - "mfuji09", - "germain", - "sideshowbarker", - "patizenyapetshop", - "larsonreever", - "SebastienParis", - "tlubitz", - "david_ross", - "mbm", - "chrisdavidmills", - "JazibZaman", - "hashedhyphen", - "marumari", - "evilpie", - "Sheppy", - "teoli" - ] - }, - "Web/Security/Securing_your_site/Turning_off_form_autocompletion": { - "modified": "2020-07-10T21:28:54.938Z", - "contributors": [ - "patrickhlauke", - "mfuji09", - "mnoorenberghe", - "leela52452", - "jswisher", - "sruthiveeragandham", - "Nomeh_Uchenna_Gabriel", - "mfluehr", - "WilliamC07", - "hjuhlin", - "chrisdavidmills", - "LouisLazaris", - "devinea2", - "steduardo", - "terrylinooo", - "kbagot", - "stutrek", - "Didglee", - "rottina", - "Delapouite", - "wbamberg", - "John99", - "Manishearth", - "Sheppy", - "ConcreteGannet", - "teoli", - "contrebis", - "dhodder", - "David-Sarah Hopwood", - "George3", - "LonelyPixel", - "Brianegge", - "NickolayBot", - "Andreas Wuest", - "Brycenesbitt", - "Callek", - "VicMan", - "Pmsyyz", - "Mathieu Deaudelin" - ] - }, "Web/Security/Subdomain_takeovers": { "modified": "2020-08-25T23:27:57.222Z", "contributors": ["jswisher"] 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 6743c6595143cc1..0257608620fbe30 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 @@ -494,8 +494,8 @@ To prevent referrer leakage entirely, specify the `no-referrer` value instead. N Use services like the ones below to check your `Referrer-Policy`: +- [HTTP Observatory](/en-US/observatory/) - [securityheaders.com](https://securityheaders.com/) -- [Mozilla Observatory](https://observatory.mozilla.org/) ```apacheconf 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 4ad14aba121eee6..d150eac0d6ba819 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 @@ -181,7 +181,7 @@ The next and final step in this module about Django is to complete the [assessme ## See also - [Security in Django](https://docs.djangoproject.com/en/5.0/topics/security/) (Django docs) -- [Server side website security](/en-US/docs/Web/Security) (MDN) -- [Securing your site](/en-US/docs/Web/Security/Securing_your_site) (MDN) +- [Security on the web](/en-US/docs/Web/Security) (MDN) +- [Practical security implementation guides](/en-US/docs/Web/Security/Practical_implementation_guides) (MDN) {{PreviousMenuNext("Learn/Server-side/Django/Deployment", "Learn/Server-side/Django/django_assessment_blog", "Learn/Server-side/Django")}} diff --git a/files/en-us/web/html/attributes/autocomplete/index.md b/files/en-us/web/html/attributes/autocomplete/index.md index 1d541fbaae000b2..d42a0cc52d63603 100644 --- a/files/en-us/web/html/attributes/autocomplete/index.md +++ b/files/en-us/web/html/attributes/autocomplete/index.md @@ -50,7 +50,7 @@ The attribute value is either the keyword `off` or `on`, or a space-separated `< - : The browser is not permitted to automatically enter or select a value for this field. It is possible that the document or application provides its own autocomplete feature, or that security concerns require that the field's value not be automatically entered. - > **Note:** In most modern browsers, setting `autocomplete` to "`off`" will not prevent a password manager from asking the user if they would like to save username and password information, or from automatically filling in those values in a site's login form. See [the autocomplete attribute and login fields](/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#the_autocomplete_attribute_and_login_fields). + > **Note:** In most modern browsers, setting `autocomplete` to "`off`" will not prevent a password manager from asking the user if they would like to save username and password information, or from automatically filling in those values in a site's login form. See [Managing autofill for login fields](/en-US/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion#managing_autofill_for_login_fields). - `on` @@ -86,7 +86,7 @@ The attribute value is either the keyword `off` or `on`, or a space-separated `< - "`username`" - : A username or account name. - "`new-password`" - - : A new password. When creating a new account or changing passwords, this should be used for an "Enter your new password" or "Confirm new password" field, as opposed to a general "Enter your current password" field that might be present. This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password (see also [Preventing autofilling with autocomplete="new-password"](/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#preventing_autofilling_with_autocompletenew-password)). + - : A new password. When creating a new account or changing passwords, this should be used for an "Enter your new password" or "Confirm new password" field, as opposed to a general "Enter your current password" field that might be present. This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password. - "`current-password`" - : The user's current password. - "`one-time-code`" diff --git a/files/en-us/web/html/element/form/index.md b/files/en-us/web/html/element/form/index.md index 9fe5f9f54bb5602..d643622a737337a 100644 --- a/files/en-us/web/html/element/form/index.md +++ b/files/en-us/web/html/element/form/index.md @@ -36,7 +36,7 @@ This element includes the [global attributes](/en-US/docs/Web/HTML/Global_attrib - : Indicates whether input elements can by default have their values automatically completed by the browser. `autocomplete` attributes on form elements override it on `
`. Possible values: - - `off`: The browser may not automatically complete entries. (Browsers tend to ignore this for suspected login forms; see [The autocomplete attribute and login fields](/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#the_autocomplete_attribute_and_login_fields).) + - `off`: The browser may not automatically complete entries. (Browsers tend to ignore this for suspected login forms; see [Managing autofill for login fields](/en-US/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion#managing_autofill_for_login_fields).) - `on`: The browser may automatically complete entries. - `name` diff --git a/files/en-us/web/http/headers/x-content-type-options/index.md b/files/en-us/web/http/headers/x-content-type-options/index.md index 4213532879e51a2..5b9810ccf293050 100644 --- a/files/en-us/web/http/headers/x-content-type-options/index.md +++ b/files/en-us/web/http/headers/x-content-type-options/index.md @@ -72,8 +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. -- The [Mozilla Observatory](https://observatory.mozilla.org/) tool testing - the configuration (including this header) of websites for safety and security +- 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) diff --git a/files/en-us/web/http/index.md b/files/en-us/web/http/index.md index 3ca309101272513..d6b47cfe8fd8704 100644 --- a/files/en-us/web/http/index.md +++ b/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. diff --git a/files/en-us/web/security/index.md b/files/en-us/web/security/index.md index 33b7c3ea1829ac2..0c14c03fe11f8ad 100644 --- a/files/en-us/web/security/index.md +++ b/files/en-us/web/security/index.md @@ -12,85 +12,85 @@ Sensitive information needs to be protected, and that is the focus of web securi - Disable or hijack their services, again causing serious problems with their operation. - Put their customer's [privacy](/en-US/docs/Web/Privacy) at risk, making them vulnerable to profiling, targeting, loss of data, identity theft, or even financial loss. -Modern browsers already have several features to protect users' security on the web, but developers also need to employ best practices and code carefully to ensure that their websites are secure. Even simple bugs in your code can result in vulnerabilities that bad people can exploit to steal data and gain control over services for which they don't have authorization. +Modern browsers already have several features to protect users' security on the web, but developers also need to use best practices and code carefully to ensure that their websites are secure. Even simple bugs in your code can result in vulnerabilities that bad actors can exploit to steal data and gain unauthorized control over services. -This article provides an introduction to web security, including information that will help you understand the aspects that can make websites vulnerable and how to secure them. +This article provides an introduction to web security, including conceptual information to help you understand website vulnerabilities and practical guides on how to secure them. ## Relationship between security and privacy -Security and privacy are distinct topics, but they are also closely-related. It is worth knowing the difference between the two and how they relate. +Security and privacy are distinct yet closely related topics. It is worth knowing the differences between the two and how they relate. - **Security** is the act of keeping private data and systems protected against unauthorized access. This includes both company (internal) data and user and partner (external) data. -- **Privacy** refers to the act of giving users the right to control how their data is collected, stored, and used, and not using it irresponsibly. For example, you should clearly communicate to users of your sites the data you are collecting, with whom it will be shared, and how it will be used. Users must be given a chance to consent to your privacy policy, have access to their data you have stored, and delete their data if they no longer wish you to have it. +- **Privacy** refers to the act of giving users control over how their data is collected, stored, and used, while also ensuring that it is not used irresponsibly. For example, you should let your users know what data you are collecting from them, the parties with whom it will be shared, and how it will be used. Users must be given a chance to consent to your privacy policy, have access to their data you store, and delete it if they choose to. Good security is essential for good privacy. You could follow all the advice listed in our [Privacy on the web](/en-US/docs/Web/Privacy) guide, but acting with integrity and having a robust privacy policy are futile if your site is not secure and attackers can just steal data anyway. -## Security services provided by browsers +## Security features provided by browsers -Web browsers have a strict security model that enforces a good level of fundamental content, connection, and transport security. This section looks at the basics. +Web browsers follow a strict security model that enforces strong security for content, connections between the browser and the server, and data transportation. This section looks at the features that underpin this model. ### Same-origin policy and CORS -[Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy) is a fundamental security mechanism of the web that restricts how a document or script loaded from one {{Glossary("origin")}} can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors. +[Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy) is a fundamental security mechanism of the web that restricts how a document or a script loaded from one {{Glossary("origin")}} can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors. -In general, documents from one origin cannot make requests to other origins. This makes sense because you don't want sites to be able to interfere with one another and access things they shouldn't. It does make sense to relax this restriction in some circumstances; for example, you might have multiple sites that interact with each other, and you may want these sites to request resources from one another, such as using [`fetch()`](/en-US/docs/Web/API/fetch). +In general, documents from one origin cannot make requests to other origins. This makes sense because you don't want sites to be able to interfere with one another and access unauthorized data. -This can be permitted using [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/CORS), an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. +However, you might want to relax this restriction in some circumstances; for example, if you have multiple websites that interact with each other, you may allow them to request resources from one another using [`fetch()`](/en-US/docs/Web/API/fetch). This can be permitted using [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/CORS), an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. ### HTTP model for communication -[HTTP](/en-US/docs/Web/HTTP) protocol is used by web browsers and servers to communicate with one another, request resources, provide responses (for example, providing the requested resource or detailing why the request failed), and provide security features for that communication. +The [HTTP](/en-US/docs/Web/HTTP) protocol is used by web browsers and servers to communicate with one another, request resources, provide responses (for example, providing a requested resource or detailing why a request failed), and provide security features for that communication. -[Transport Layer Security (TLS)](/en-US/docs/Web/Security/Transport_Layer_Security) provides security and privacy by encrypting data during transport over the network and is the technology behind the [HTTPS](/en-US/docs/Glossary/HTTPS) protocol. TLS is good for privacy because it stops third parties from being able to intercept transmitted data and use it maliciously. +Transport Layer Security (TLS) provides security and privacy by encrypting data during transport over the network and is the technology behind the [HTTPS](/en-US/docs/Glossary/HTTPS) protocol. TLS is good for privacy because it stops third parties from being able to intercept transmitted data and use it maliciously. All browsers are moving towards requiring HTTPS by default; this is practically the case already because you can't do much on the web without this protocol. Related topics: -- [Transport layer security (TLS)](/en-US/docs/Web/Security/Transport_Layer_Security) - - : The Transport Layer Security ({{Glossary("TLS")}}) protocol is the standard for enabling two networked applications or devices to exchange information privately and robustly. Applications that use TLS can choose their security parameters, which can have a substantial impact on the security and reliability of data. This article provides an overview of TLS and the kinds of decisions you need to make when securing your content. +- [Transport layer security](/en-US/docs/Web/Security/Transport_Layer_Security) (TLS) + - : The TLS protocol is the standard for enabling two networked applications or devices to exchange information privately and robustly. Applications that use TLS can choose their security parameters, which can have a substantial impact on the security and reliability of data. - [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. + - : 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 which maintain an append-only, cryptographically assured record 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 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. - This page explains what you should be aware of as a web developer. + - : 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. - [Weak signature algorithms](/en-US/docs/Web/Security/Weak_Signature_Algorithm) - - : The strength of the hash algorithm used in {{Glossary("Signature/Security", "signing")}} a {{Glossary("digital certificate")}} is a critical element of the security of the certificate. This article provides some information about signature algorithms known to be weak, so you can avoid them when appropriate. + - : The strength of the hash algorithm used in {{Glossary("Signature/Security", "signing")}} a {{Glossary("digital certificate")}} is a critical element of the security of the certificate. Some signature algorithms are known to be weak, and should be avoided when appropriate. ### Secure contexts and feature permissions -Browsers control usage of several "powerful features" in a few different ways. By "powerful features", we mean things like a site generating system notifications, using a user's web cam to get access to a media stream, manipulating the system GPU, and using web payments. If a site could just use the APIs that control such features without restriction, malicious developers could for example: +Browsers control the usage of "powerful features" in different ways. These "powerful features" include generating system notifications on a website, using a user's webcam to get access to a media stream, manipulating the system GPU, and using web payments. If a site could just use the APIs that control such features without restriction, malicious developers could attempt to do the following: - Annoy users with unneeded notifications and other UI features. +- Turn their webcam on without warning to spy on them. - Clog up their browser/system to create {{glossary("denial of service", "Denial of Service")}} (DoS) attacks. - Steal data or money. -Such browser features are controlled as follows: +These "powerful features" are controlled in the following ways: -First, usage of such features is permitted only in [secure contexts](/en-US/docs/Web/Security/Secure_Contexts). A secure context is a {{domxref("Window", "window")}} or a {{domxref("WorkerGlobalScope", "worker")}} for which there is reasonable confidence that the content has been delivered securely (via HTTPS/TLS). In a secure context, the potential for communication with contexts that are **not** secure is limited. Secure contexts also help to prevent [man-in-the-middle attackers](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) from accessing the powerful APIs of the browser. +- Usage of such features is permitted only in [secure contexts](/en-US/docs/Web/Security/Secure_Contexts). A secure context is a {{domxref("Window", "window")}} or a {{domxref("WorkerGlobalScope", "worker")}} for which there is reasonable confidence that the content has been delivered securely (via HTTPS/TLS). In a secure context, the potential for communication with contexts that are **not** secure is limited. Secure contexts also help to prevent [man-in-the-middle attackers](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) from accessing powerful features. -> **Note:** See also [Features restricted to secure contexts](/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts). This reference lists web platform features available only in secure contexts. + To see a list of web platform features available only in secure contexts, see [Features restricted to secure contexts](/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts). -Second, the usage of these features is gated behind a system of user permissions — users have to explicitly opt-in to providing access to such features, meaning that these featured can't be used automatically. The user permission requests happen automatically, but you can query the state of an API permission by using the [Permissions API](/en-US/docs/Web/API/Permissions_API). +- The usage of these features is gated behind a system of user permissions: users have to explicitly opt-in to providing access to such features, meaning that they can't be used automatically. User permission requests happen automatically, and you can query the state of an API permission by using the [Permissions API](/en-US/docs/Web/API/Permissions_API). -Third, many other browser features can be used only in response to a user action such as clicking a button, meaning that they need to be invoked from inside an appropriate event handler. This is often called **transient activation**. See [Features gated by user activation](/en-US/docs/Web/Security/User_activation) for more information. +- Several other browser features can be used only in response to a user action such as clicking a button, meaning that they need to be invoked from inside an appropriate event handler. This is called **transient activation**. See [Features gated by user activation](/en-US/docs/Web/Security/User_activation) for more information. -## Security considerations for client-side developers +## High-level security considerations -There are many aspects of web security that need to be thought about on the server- and client-side. The sections below focus mainly on client-side security considerations. You can find a useful summary of security from a server-side perspective, which also includes descriptions of common attacks to watch out for, at [Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) (part of our [Server-side website programming](/en-US/docs/Learn/Server-side) learning module). +There are many aspects of web security that need to be thought about on the server- and client-side. This section focuses mainly on client-side security considerations. You can find a useful summary of security from a server-side perspective, which also includes descriptions of common attacks to watch out for, at [Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) (part of our [Server-side website programming](/en-US/docs/Learn/Server-side) learning module). -## Store client-side data responsibly +### Store client-side data responsibly Handling data responsibly is largely concerned with cutting down on [third-party cookie](/en-US/docs/Web/Privacy/Third-party_cookies) usage and being careful about the data you store and share with them. Traditionally, web developers have used cookies to store all kinds of data, and it has been easy for attackers to exploit this tendency. As a result, browsers have started to limit what you can do with cross-site cookies, with the aim of removing access to them altogether in the future. -You should prepare for the removal of cross-site cookies by limiting the amount of tracking activities you rely on and/or by implementing desired information persistence in other ways. See [Transitioning from third-party cookies](/en-US/docs/Web/Privacy/Third-party_cookies#transitioning_from_third-party_cookies) and [Replacing third-party cookies](/en-US/docs/Web/Privacy/Third-party_cookies#replacing_third-party_cookies) for more information. +You should prepare for the removal of cross-site cookies by limiting the amount of tracking activities you rely on and/or by implementing the persistence of the desired information in other ways. See [Transitioning from third-party cookies](/en-US/docs/Web/Privacy/Third-party_cookies#transitioning_from_third-party_cookies) and [Replacing third-party cookies](/en-US/docs/Web/Privacy/Third-party_cookies#replacing_third-party_cookies) for more information. -## Protect user identity and manage logins +### Protect user identity and manage logins -When implementing a secure solution that involves data collection, particularly if the data is sensitive such as log-in credentials, it makes sense to use a reputable solution from a well-respected provider. For example, any respectable server-side framework will have built-in features to protect against common vulnerabilities. You could also consider using a specialized product for your purpose, for example an identity provider solution or a secure online survey provider. +When implementing a secure solution that involves data collection, particularly if the data is sensitive such as log-in credentials, it makes sense to use a reputable solution. For example, any respectable server-side framework will have built-in features to protect against common vulnerabilities. You could also consider using a specialized product for your purpose, for example an identity provider solution or a secure online survey provider. If you want to roll your own solution for collecting user data, make sure you understand all aspects and requirements. Hire an experienced server-side developer and/or security engineer to implement the system, and ensure it is tested thoroughly. Use multi-factor authentication (MFA) to provide better protection. Consider using a dedicated API such as [Web Authentication](/en-US/docs/Web/API/Web_Authentication_API) or [Federated Credential Management](/en-US/docs/Web/API/FedCM_API) to streamline the client-side of the app. @@ -104,27 +104,27 @@ Here are some other tips for providing secure logins: - Protect against brute force attacks on login pages with [rate limiting](https://www.cloudflare.com/en-gb/learning/bots/what-is-rate-limiting/), account lockouts after a certain number of unsuccessful attempts, and [CAPTCHA challenges](https://en.wikipedia.org/wiki/CAPTCHA). - Manage user login sessions with unique [session IDs](https://en.wikipedia.org/wiki/Session_ID), and automatically log out users after periods of inactivity. -## Don't include sensitive data in URL query strings +### Don't include sensitive data in URL query strings -As a general rule you shouldn't [include sensitive data in URL query strings](https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url): if a third party intercepts the URL (for example via the {{httpheader("Referer")}} HTTP header), they could steal that information. Even more serious is that these URLs can be indexed by public web crawlers, HTTP proxies, and archiving tools such as the [internet archive](https://web.archive.org/), meaning that your sensitive data can persist on publicly accessible resources. +As a general rule, you shouldn't [include sensitive data in URL query strings](https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url) because if a third party intercepts the URL (for example, via the {{httpheader("Referer")}} HTTP header), they could steal that information. Even more serious is the fact that these URLs can be indexed by public web crawlers, HTTP proxies, and archiving tools such as the [internet archive](https://web.archive.org/), meaning that your sensitive data could persist on publicly accessible resources. Use `POST` requests rather than `GET` requests to avoid these issues. Our article [Referer header policy: Privacy and security concerns](/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns) describes in more detail the privacy and security risks associated with the `Referer` header, and offers advice on mitigating those risks. > **Note:** Steering away from transmitting sensitive data in URLs via `GET` requests can also help protect against {{glossary("CSRF", "cross-site request forgery")}} and [replay attacks](https://en.wikipedia.org/wiki/Replay_attack). -## Enforce usage policies +### Enforce usage policies -Consider using tools like [Content Security Policy](/en-US/docs/Web/HTTP/CSP) (CSP) and [Permissions policy](/en-US/docs/Web/HTTP/Permissions_Policy) to enforce a set of feature and resource usage on your site that makes it harder to introduce vulnerabilities. +Consider using web platform features like [Content Security Policy](/en-US/docs/Web/HTTP/CSP) (CSP) and [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) to enforce a set of feature and resource usage rules on your website that make it harder to introduce vulnerabilities. CSP allows you to add a layer of security by, for example, allowing images or scripts to be loaded only from specific trusted origins. This helps to detect and mitigate certain types of attacks, including Cross-Site Scripting ({{Glossary("Cross-site_scripting", "XSS")}}) and data injection attacks. These attacks involve a range of malicious activities, including data theft, site defacement, and distribution of malware. Permissions policy works in a similar way, except that it is more concerned with allowing or blocking access to specific "powerful features" ([as mentioned earlier](#secure_contexts_and_feature_permissions)). -> **Note:** Such policies are very useful to help keep sites secure, especially when you are using a lot of third party code on your site. However, keep in mind that if you block usage of a feature that a third-party script relies on to work, you may end up breaking your site's functionality. +> **Note:** Such policies are very useful to help keep sites secure, especially when you are using a lot of third-party code on your site. However, keep in mind that if you block usage of a feature that a third-party script relies on to work, you may end up breaking your site's functionality. -## Maintain data integrity +### Maintain data integrity -Following on from the previous section, when you do allow feature and resource usage on your site, you should try to ensure that resources have not been tampered with. +Following on from the previous section, when you allow feature and resource usage on your site, you should try to ensure that resources have not been tampered with. Related topics: @@ -133,24 +133,24 @@ Related topics: - [HTTP Access-Control-Allow-Origin](/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) - : The **`Access-Control-Allow-Origin`** response header indicates whether the response can be shared with requesting code from the given {{glossary("origin")}}. - [HTTP X-Content-Type-Options](/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) - - : The **`X-Content-Type-Options`** response HTTP header is a marker used by the server to indicate that the [MIME types](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should not be changed and be followed. This is a way to opt out of [MIME type sniffing](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), or, in other words, to say that the MIME types are deliberately configured. + - : The **`X-Content-Type-Options`** response header is a marker used by the server to indicate that the [MIME types](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should not be changed and must be followed. This header is a way to opt out of [MIME type sniffing](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), or, in other words, to specify that the MIME types are deliberately configured. -## Sanitize form input +### Sanitize form input -As a general rule, don't trust anything that users enter into forms. Filling out forms online is complicated and tedious, and it is easy for users to enter wrong data or data in the wrong format. In addition, malicious folks are well-versed in the art of entering specific strings of executable code into form fields (for example, SQL or JavaScript). If you're not careful about handling these types of inputs, it could either execute harmful code on your site or delete your databases. See [SQL injection](/en-US/docs/Learn/Server-side/First_steps/Website_security#sql_injection) for a good example of how this could happen. +As a general rule, don't trust anything that users enter into forms. Filling out forms online is complicated and tedious, and it is easy for users to enter incorrect data or data in the wrong format. In addition, malicious folks are skilled in the art of entering specific strings of executable code into form fields (for example, SQL or JavaScript). If you're not careful about handling such inputs, they could either execute harmful code on your site or delete your databases. See [SQL injection](/en-US/docs/Learn/Server-side/First_steps/Website_security#sql_injection) for a good example of how this could happen. To protect against this, you should thoroughly sanitize data entered into your forms: - You should implement client-side validation to inform users when they have entered data in the wrong format. You can do this using built-in HTML form validation features, or you can write your own validation code. See [Client-side form validation](/en-US/docs/Learn/Forms/Form_validation) for more information. -- You should use output encoding when displaying user input in an application UI to safely display data exactly as a user typed it in, to avoid it being executed as code. See [Output encoding](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding) for more information. +- You should use output encoding when displaying user input in an application UI to safely display data exactly as a user typed it in and avoid it being executed as code. See [Output encoding](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding) for more information. -However, you can't rely on client-side validation alone for security. It is a useful user experience enhancement for your users because it gives them instant validation feedback without having to wait for a round trip to the server. At the same time, client-side validation is too easy for a malicious party to bypass (for example, by turning off JavaScript in the browser to bypass JavaScript-based validation), so it should be combined with server-side validation. +You can't rely on client-side validation alone for security — it should be combined with server-side validation. Client-side validation enhances the user experience by providing instant validation feedback without having to wait for a round trip to the server. However, client-side validation is easy for a malicious party to bypass (for example, by turning off JavaScript in the browser to bypass JavaScript-based validation). Any reputable server-side framework will provide functionality for validating form submissions. In addition, a common best practice is to escape any special characters that form part of executable syntax, thereby making any entered code no longer executable and treated as plain text. -## Protect against clickjacking +### Protect against clickjacking -In [clickjacking](/en-US/docs/Glossary/Clickjacking), a user is fooled into clicking on a UI element that performs an action different from what the user expects. This can be a risk inherent in embedded third-party content (make sure you trust what is being embedded into your site), and it can also be combined with phishing. +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). The following features can help guard against clickjacking: @@ -159,14 +159,18 @@ The following features can help guard against clickjacking: - [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")}}. +## Practical security implementation guides + +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 [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 - [Privacy on the web](/en-US/docs/Web/Privacy) -- [Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) -- [Mozilla security blog](https://blog.mozilla.org/security/) -- [Mozilla observatory](https://observatory.mozilla.org/) -- [OWASP Cheat Sheet series](https://cheatsheetseries.owasp.org/index.html) — a series of detailed documents on different security topics, including how to protect against different types of vulnerability. -- [Mozilla web security cheat sheet](https://infosec.mozilla.org/guidelines/web_security.html#web-security-cheat-sheet) +- [Learn: Website security](/en-US/docs/Learn/Server-side/First_steps/Website_security) +- [Mozilla Security Blog](https://blog.mozilla.org/security/) +- [OWASP Cheat Sheet series](https://cheatsheetseries.owasp.org/index.html)