diff --git a/files/en-us/glossary/hpkp/index.md b/files/en-us/glossary/hpkp/index.md index 6802f4b5360886d..6922712adf81d8c 100644 --- a/files/en-us/glossary/hpkp/index.md +++ b/files/en-us/glossary/hpkp/index.md @@ -5,7 +5,7 @@ page-type: glossary-definition sidebar: glossarysidebar --- -**HTTP Public Key Pinning** (**HPKP**) is an obsolete security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates. +**HTTP Public Key Pinning** (**HPKP**) is an obsolete security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks with forged certificates. ## See also diff --git a/files/en-us/glossary/mitm/index.md b/files/en-us/glossary/mitm/index.md index 05cfc07e6a9df7e..0c4bb7b509ea44e 100644 --- a/files/en-us/glossary/mitm/index.md +++ b/files/en-us/glossary/mitm/index.md @@ -5,7 +5,7 @@ page-type: glossary-definition sidebar: glossarysidebar --- -A **manipulator-in-the-middle attack** (MitM) intercepts a communication between two systems. For example, a Wi-Fi router can be compromised. +A **manipulator in the middle attack** (MitM) intercepts a communication between two systems. For example, a Wi-Fi router can be compromised. Comparing this to physical mail: If you're writing letters to each other, the mail carrier can intercept each letter you mail. They open it, read it, eventually modify it, and then repackage the letter and only then send it to whom you intended to sent the letter for. The original recipient would then mail you a letter back, and the mail carrier would again open the letter, read it, eventually modify it, repackage it, and give it to you. You wouldn't know there's a manipulator in the middle in your communication channel – the mail carrier is invisible to you and to your recipient. @@ -17,5 +17,7 @@ In physical mail and in online communication, MITM attacks are tough to defend. ## See also -- OWASP: [Manipulator-in-the-middle attack](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack) +- [Manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) +- [Attacks](/en-US/docs/Web/Security/Attacks) +- OWASP: [Manipulator in the middle attack](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack) - Wikipedia: [Man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) diff --git a/files/en-us/glossary/placeholder_names/index.md b/files/en-us/glossary/placeholder_names/index.md index 97109b67f63929c..5391d2de66e8169 100644 --- a/files/en-us/glossary/placeholder_names/index.md +++ b/files/en-us/glossary/placeholder_names/index.md @@ -5,10 +5,16 @@ page-type: glossary-definition sidebar: glossarysidebar --- -Placeholder names are commonly used in cryptography to indicate the participants in a conversation, without resorting to terminology such as "Party A," "eavesdropper," and "malicious attacker." +**Placeholder names** are commonly used in cryptography to indicate the participants in a conversation, without resorting to terminology such as "Party A," "eavesdropper," and "malicious attacker." The most commonly used names are: - _Alice_ and _Bob_, two parties who want to send messages to each other, occasionally joined by _Carol_, a third participant - _Eve_, a passive attacker who is eavesdropping on Alice and Bob's conversation -- _Mallory_, an active attacker ("man-in-the-middle") who is able to modify their conversation and replay old messages +- _Mallory_, an active attacker ("[manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)") who is able to modify their conversation and replay old messages + +## See also + +- [Manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) +- [Attacks](/en-US/docs/Web/Security/Attacks) +- [Security](/en-US/docs/Web/Security) diff --git a/files/en-us/glossary/session_hijacking/index.md b/files/en-us/glossary/session_hijacking/index.md index 0f608b65493f2d0..15172239e307a3f 100644 --- a/files/en-us/glossary/session_hijacking/index.md +++ b/files/en-us/glossary/session_hijacking/index.md @@ -22,7 +22,7 @@ Most authentication occurs only at the start of a {{glossary("TCP")}} session. I ## Session hijacking process -1. **Sniff**, that is perform a man-in-the-middle (MITM) attack, place yourself between victim and server. +1. **Sniff**, that is perform a [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attack, place yourself between victim and server. 2. **Monitor** packets flowing between server and user. 3. **Break** the victim machine's connection. 4. **Take control** of the session. diff --git a/files/en-us/web/api/service_worker_api/index.md b/files/en-us/web/api/service_worker_api/index.md index 1bb89d9f021b9d5..f207f0a47bc1468 100644 --- a/files/en-us/web/api/service_worker_api/index.md +++ b/files/en-us/web/api/service_worker_api/index.md @@ -20,7 +20,7 @@ Service workers run in a worker context: they therefore have no DOM access and r Service workers can't import JavaScript modules dynamically, and [`import()`](/en-US/docs/Web/JavaScript/Reference/Operators/import) will throw an error if it is called in a service worker global scope. Static imports using the [`import`](/en-US/docs/Web/JavaScript/Reference/Statements/import) statement are allowed. -Service workers are only available in [secure contexts](/en-US/docs/Web/Security/Defenses/Secure_Contexts): this means that their document is served over HTTPS, although browsers also treat `http://localhost` as a secure context, to facilitate local development. HTTP connections are susceptible to malicious code injection by {{Glossary("MitM", "man in the middle")}} attacks, and such attacks could be worse if allowed access to these powerful APIs. +Service workers are only available in [secure contexts](/en-US/docs/Web/Security/Defenses/Secure_Contexts): this means that their document is served over HTTPS, although browsers also treat `http://localhost` as a secure context, to facilitate local development. HTTP connections are susceptible to malicious code injection by [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks, and such attacks could be worse if allowed access to these powerful APIs. > [!NOTE] > On Firefox, for testing you can run service workers over HTTP (insecurely); simply check the **Enable Service Workers over HTTP (when toolbox is open)** option in the Firefox DevTools options/gear menu. diff --git a/files/en-us/web/api/web_authentication_api/authenticator_data/index.md b/files/en-us/web/api/web_authentication_api/authenticator_data/index.md index 071513200fb2e99..da93b0419619ff1 100644 --- a/files/en-us/web/api/web_authentication_api/authenticator_data/index.md +++ b/files/en-us/web/api/web_authentication_api/authenticator_data/index.md @@ -20,7 +20,7 @@ Authenticator data is made available to the browser as an {{jsxref("ArrayBuffer" An authenticator data {{jsxref("ArrayBuffer")}} is at least 37 bytes in length, and contains the following fields: - **rpIdHash** (32 bytes) - - : The SHA-256 hash of the [Relying Party ID](https://w3c.github.io/webauthn/#relying-party-identifier) that the credential is scoped to. The server will ensure that this hash matches the SHA256 hash of its own relying party ID in order to prevent phishing or other man-in-the-middle attacks. + - : The SHA-256 hash of the [Relying Party ID](https://w3c.github.io/webauthn/#relying-party-identifier) that the credential is scoped to. The server will ensure that this hash matches the SHA256 hash of its own relying party ID in order to prevent phishing or other [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks. - **flags** (1 bytes) - : A bitfield that indicates various attributes that were asserted by the authenticator. The bits are as follows, where Bit 0 is the least significant bit and all bits not specifically mentioned below are "reserved for future use": - Bit 0, User Presence (UP): If set (i.e., to `1`), the authenticator validated that the user was present through some Test of User Presence (TUP), such as touching a button on the authenticator. diff --git a/files/en-us/web/api/web_crypto_api/non-cryptographic_uses_of_subtle_crypto/index.md b/files/en-us/web/api/web_crypto_api/non-cryptographic_uses_of_subtle_crypto/index.md index 28e97f076e0085a..a5d1cba42bb704b 100755 --- a/files/en-us/web/api/web_crypto_api/non-cryptographic_uses_of_subtle_crypto/index.md +++ b/files/en-us/web/api/web_crypto_api/non-cryptographic_uses_of_subtle_crypto/index.md @@ -10,7 +10,7 @@ This article will focus on uses of the [`digest`](/en-US/docs/Web/API/SubtleCryp This article does not discuss the cryptographic uses of the [SubtleCrypto interface](/en-US/docs/Web/API/SubtleCrypto). An important thing to take away from this article is **don't use this API** for production cryptographic purposes because it is powerful and low level. To use it correctly you will need to take many context specific steps to accomplish cryptographic tasks correctly. If any of those steps are taken incorrectly at best your code won't run, at worse it _will_ run and you will unknowingly be putting your users at risk with an insecure product. -You may not even need to use the [Web Crypto API](/en-US/docs/Web/API/Web_Crypto_API) at all. Many of the things you would want to use cryptography for are already solved and part of the Web platform. For example, if you are worried about man-in-the-middle attacks, such as Wi-Fi hotspots reading the information between the client and the server, this is solved by ensuring correct use of [HTTPS](/en-US/docs/Glossary/HTTPS). Do you want to securely send information between users? Then you can set up a data connection between users using [WebRTC Data Channels](/en-US/docs/Web/API/WebRTC_API/Using_data_channels) which is encrypted as part of the standard. +You may not even need to use the [Web Crypto API](/en-US/docs/Web/API/Web_Crypto_API) at all. Many of the things you would want to use cryptography for are already solved and part of the Web platform. For example, if you are worried about [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks, such as Wi-Fi hotspots reading the information between the client and the server, this is solved by ensuring correct use of [HTTPS](/en-US/docs/Glossary/HTTPS). Do you want to securely send information between users? Then you can set up a data connection between users using [WebRTC Data Channels](/en-US/docs/Web/API/WebRTC_API/Using_data_channels) which is encrypted as part of the standard. The [SubtleCrypto interface](/en-US/docs/Web/API/SubtleCrypto) provides low level primitives for working with cryptography, but implementing a system using these tools is a complicated task. Mistakes are hard to notice and the results can mean your user's data is not as secure as you think it is. Which could have catastrophic results if your users are sharing sensitive or valuable data. diff --git a/files/en-us/web/html/reference/elements/input/hidden/index.md b/files/en-us/web/html/reference/elements/input/hidden/index.md index f0e01cd5dec9718..1daff163632cb1a 100644 --- a/files/en-us/web/html/reference/elements/input/hidden/index.md +++ b/files/en-us/web/html/reference/elements/input/hidden/index.md @@ -7,14 +7,14 @@ browser-compat: html.elements.input.type_hidden sidebar: htmlsidebar --- -{{HTMLElement("input")}} elements of type **`hidden`** let web developers include data that cannot be seen or modified by users when a form is submitted. For example, the ID of the content that is currently being ordered or edited, or a unique security token. Hidden inputs are completely invisible in the rendered page, and there is no way to make it visible in the page's content. +{{HTMLElement("input")}} elements of type **`hidden`** allow web developers to include data in a form that is not visually accessible to users when a form is submitted. For example, the ID of the content that is currently being ordered or edited, or a unique security token. Hidden inputs are completely invisible in the rendered page, but are still submitted as any other form input. While the data is not presented to users in the rendered content, it is still accessible in the HTML output and is editable to users using tools such as their [browser's developer tools](/en-US/docs/Learn_web_development/Howto/Tools_and_setup/What_are_browser_developer_tools). > [!NOTE] > The {{domxref("Element/input_event", "input")}} and {{domxref("HTMLElement/change_event", "change")}} events do not apply to this input type. Hidden inputs cannot be focused even using JavaScript (e.g., `hiddenInput.focus()`). ## Value -The {{HTMLElement("input")}} element's [`value`](/en-US/docs/Web/HTML/Reference/Elements/input#value) attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This specifically can't be edited or seen by the user via the user interface, although you could edit the value via browser developer tools. +The {{HTMLElement("input")}} element's [`value`](/en-US/docs/Web/HTML/Reference/Elements/input#value) attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This value is not presented to the user via the user interface. > [!WARNING] > While the value isn't displayed to the user in the page's content, it is visible—and can be edited—using any browser's developer tools or "View Source" functionality. Do not rely on `hidden` inputs as a form of security. @@ -29,7 +29,7 @@ This is actually one of the common attributes, but it has a special meaning avai ## Using hidden inputs -As mentioned above, hidden inputs can be used anywhere that you want to include data the user can't see or edit along with the form when it's submitted to the server. Let's look at some examples that illustrate its use. +As mentioned above, hidden inputs can be used anywhere that you want to include data the user can't see along with the form when it's submitted to the server. Let's look at some examples that illustrate its use. ### Tracking edited content @@ -45,12 +45,10 @@ You can see a full example of what this might look like in the [Examples](#examp ### Improving website security -Hidden inputs are also used to store and submit security tokens or _secrets_, for the purposes of improving website security. The basic idea is that if a user is filling in a sensitive form, such as a form on their banking website to transfer some money to another account, the secret they would be provided with would prove that they are who they say they are, and that they are using the correct form to submit the transfer request. - -This would stop a malicious user from creating a fake form, pretending to be a bank, and emailing the form to unsuspecting users to trick them into transferring money to the wrong place. This kind of attack is called a [Cross Site Request Forgery (CSRF)](/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Website_security#cross-site_request_forgery_csrf); pretty much any reputable server-side framework uses hidden secrets to prevent such attacks. +One common use of hidden input fields is to store Cross-Site Request Forgery (CSRF) tokens, which help protect websites against [CSRF attacks](/en-US/docs/Web/Security/Attacks/CSRF). > [!NOTE] -> Placing the secret in a hidden input doesn't inherently make it secure. The key's composition and encoding would do that. The value of the hidden input is that it keeps the secret associated with the data and automatically includes it when the form is sent to the server. You need to use well-designed secrets to actually secure your website. +> Data placed in a hidden input is not inherently secured. Its value is still observable by the end user. You need to use well-designed secrets to actually secure your website. ## Validation diff --git a/files/en-us/web/http/guides/cookies/index.md b/files/en-us/web/http/guides/cookies/index.md index eedfcab50817cb4..2b8072e20c934c3 100644 --- a/files/en-us/web/http/guides/cookies/index.md +++ b/files/en-us/web/http/guides/cookies/index.md @@ -156,7 +156,7 @@ You can ensure that cookies are sent securely and aren't accessed by unintended Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly ``` -- A cookie with the `Secure` attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means {{Glossary("MitM", "man-in-the-middle")}} attackers can't access it easily. Insecure sites (with `http:` in the URL) can't set cookies with the `Secure` attribute. However, don't assume that `Secure` prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if the `HttpOnly` attribute isn't set) can read and modify the information. +- A cookie with the `Secure` attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attackers can't access it easily. Insecure sites (with `http:` in the URL) can't set cookies with the `Secure` attribute. However, don't assume that `Secure` prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if the `HttpOnly` attribute isn't set) can read and modify the information. - A cookie with the `HttpOnly` attribute can't be accessed by JavaScript, for example using {{domxref("Document.cookie")}}; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have the `HttpOnly` attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting ([XSS](/en-US/docs/Web/Security/Attacks/XSS)) attacks. diff --git a/files/en-us/web/http/reference/headers/set-cookie/index.md b/files/en-us/web/http/reference/headers/set-cookie/index.md index 5f9701ef1aaa93a..cc141066cd6822d 100644 --- a/files/en-us/web/http/reference/headers/set-cookie/index.md +++ b/files/en-us/web/http/reference/headers/set-cookie/index.md @@ -149,7 +149,7 @@ Set-Cookie: =; Domain=; Secure; HttpOnl The `Secure` attribute must also be set when using this value. - `Secure` {{optional_inline}} - - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [man-in-the-middle](/en-US/docs/Glossary/MitM) attacks. + - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks. > [!NOTE] > Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.). diff --git a/files/en-us/web/http/reference/headers/strict-transport-security/index.md b/files/en-us/web/http/reference/headers/strict-transport-security/index.md index cd9144312ef905a..119a9efdfc5d04c 100644 --- a/files/en-us/web/http/reference/headers/strict-transport-security/index.md +++ b/files/en-us/web/http/reference/headers/strict-transport-security/index.md @@ -61,7 +61,7 @@ the intention of strict security. > [!NOTE] > The host must send the `Strict-Transport-Security` header over HTTPS only, not insecure HTTP. -> Browsers ignore the header if sent over HTTP to prevent a [manipulator-in-the-middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) +> Browsers ignore the header if sent over HTTP to prevent a [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) > from altering the header to expire prematurely or adding it for a host that doesn't support HTTPS. ### Expiration diff --git a/files/en-us/web/http/reference/resources_and_specifications/index.md b/files/en-us/web/http/reference/resources_and_specifications/index.md index 2074cf7262fd7f9..b019526d553ea28 100644 --- a/files/en-us/web/http/reference/resources_and_specifications/index.md +++ b/files/en-us/web/http/reference/resources_and_specifications/index.md @@ -53,6 +53,7 @@ HTTP was first specified in the early 1990s. Designed with extensibility in mind | [Draft spec](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-expect-ct-01) | Expect-CT Extension for HTTP | IETF Draft | | {{rfc(7486)}} | HTTP Origin-Bound Auth (HOBA) | Experimental | | {{rfc(7240)}} | Prefer Header for HTTP | Proposed Standard | +| {{rfc(3229)}} | Delta encoding in HTTP | Proposed Standard | ## See also diff --git a/files/en-us/web/javascript/reference/global_objects/promise/index.md b/files/en-us/web/javascript/reference/global_objects/promise/index.md index 0b335ae6fbec9ba..999a52f529afd27 100644 --- a/files/en-us/web/javascript/reference/global_objects/promise/index.md +++ b/files/en-us/web/javascript/reference/global_objects/promise/index.md @@ -21,7 +21,7 @@ A `Promise` is in one of these states: - _rejected_: meaning that the operation failed. The _eventual state_ of a pending promise can either be _fulfilled_ with a value or _rejected_ with a reason (error). -When either of these options occur, the associated handlers queued up by a promise's `then` method are called. If the promise has already been fulfilled or rejected when a corresponding handler is attached, the handler will be called, so there is no race condition between an asynchronous operation completing and its handlers being attached. +When either of these options occurs, the associated handlers queued up by a promise's `then` method are called. If the promise has already been fulfilled or rejected when a corresponding handler is attached, the handler will be called, so there is no race condition between an asynchronous operation completing and its handlers being attached. A promise is said to be _settled_ if it is either fulfilled or rejected, but not pending. diff --git a/files/en-us/web/security/defenses/mixed_content/index.md b/files/en-us/web/security/defenses/mixed_content/index.md index 7a6fc0242a3c3d3..e8f61472affc467 100644 --- a/files/en-us/web/security/defenses/mixed_content/index.md +++ b/files/en-us/web/security/defenses/mixed_content/index.md @@ -6,7 +6,7 @@ browser-compat: http.mixed-content sidebar: security --- -When a web page is loaded from a secure origin, over a secure channel such as {{Glossary("HTTPS")}}, the connection with the web server is encrypted, and is therefore protected from eavesdropping and modification by man-in-the-middle attacks. +When a web page is loaded from a secure origin, over a secure channel such as {{Glossary("HTTPS")}}, the connection with the web server is encrypted, and is therefore protected from eavesdropping and modification by [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks. If the securely loaded web page only includes images, scripts, and other resources that are also hosted on secure origins, users can be confident that the whole page is safe from these kinds of attacks. "Mixed content" refers to securely loaded web pages that use resources to be fetched via HTTP or another insecure protocol. diff --git a/files/en-us/web/security/defenses/secure_contexts/index.md b/files/en-us/web/security/defenses/secure_contexts/index.md index a027260e43fa558..8e2062c75b6dd2d 100644 --- a/files/en-us/web/security/defenses/secure_contexts/index.md +++ b/files/en-us/web/security/defenses/secure_contexts/index.md @@ -6,7 +6,7 @@ spec-urls: https://w3c.github.io/webappsec-secure-contexts/ sidebar: security --- -A **secure context** is a `Window` or `Worker` for which certain minimum standards of authentication and confidentiality are met. Many Web APIs and features are accessible only in a secure context. The primary goal of secure contexts is to prevent [MITM attackers](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) from accessing powerful APIs that could further compromise the victim of an attack. +A **secure context** is a `Window` or `Worker` for which certain minimum standards of authentication and confidentiality are met. Many Web APIs and features are accessible only in a secure context. The primary goal of secure contexts is to prevent [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attackers from accessing powerful APIs that could further compromise the victim of an attack. ## Why should some features be restricted? diff --git a/files/en-us/web/security/practical_implementation_guides/csp/index.md b/files/en-us/web/security/practical_implementation_guides/csp/index.md index e9143f97b2098bb..750389cd3dc2807 100644 --- a/files/en-us/web/security/practical_implementation_guides/csp/index.md +++ b/files/en-us/web/security/practical_implementation_guides/csp/index.md @@ -18,7 +18,7 @@ The main problem this article focuses on is cross-site scripting ({{Glossary("Cr CSP can also help to fix other problems, which are covered in other articles: - Preventing [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) by stopping your site being embedded into {{htmlelement("iframe")}} elements. This is done using the CSP [`frame-ancestors`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors) directive. -- Preventing [manipulator-in-the-middle](/en-US/docs/Web/Security/Attacks/MITM) (MiTM) attacks by upgrading any HTTP connections to HTTPS. This is helped by the CSP [`upgrade-insecure-requests`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/upgrade-insecure-requests) directive. See [Upgrading insecure requests](/en-US/docs/Web/HTTP/Guides/CSP#upgrading_insecure_requests). +- Preventing [manipulator in the middle](/en-US/docs/Web/Security/Attacks/MITM) (MiTM) attacks by upgrading any HTTP connections to HTTPS. This is helped by the CSP [`upgrade-insecure-requests`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/upgrade-insecure-requests) directive. See [Upgrading insecure requests](/en-US/docs/Web/HTTP/Guides/CSP#upgrading_insecure_requests). ## Solution diff --git a/files/en-us/web/security/practical_implementation_guides/tls/index.md b/files/en-us/web/security/practical_implementation_guides/tls/index.md index f943d2c20cadaa1..3d54d9a10a505df 100644 --- a/files/en-us/web/security/practical_implementation_guides/tls/index.md +++ b/files/en-us/web/security/practical_implementation_guides/tls/index.md @@ -12,7 +12,7 @@ sidebar: security ### Problem -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. +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, 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/Defenses/Secure_Contexts). @@ -96,7 +96,7 @@ 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. +To prevent [manipulator in the middle](/en-US/docs/Glossary/MitM) (MiTM) attacks, browsers should only connect to sites via HTTPS. ### Solution