diff --git a/files/en-us/web/http/headers/forwarded/index.md b/files/en-us/web/http/headers/forwarded/index.md index c3b77f6a946f8d9..fdbc1d85d612d84 100644 --- a/files/en-us/web/http/headers/forwarded/index.md +++ b/files/en-us/web/http/headers/forwarded/index.md @@ -18,6 +18,10 @@ Therefore, the user's privacy must be kept in mind when deploying this header. The alternative and de-facto standard versions of this header are the {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Host")}} and {{HTTPHeader("X-Forwarded-Proto")}} headers. +> [!NOTE] +> If upstream services rely on `X-Forwarded-*` headers, replacing them outright with `Forwarded` could lead to compatibility issues. +> Verify that frameworks, middleware, and any third-party tools support the standardized version before deploying this header as a replacement. + diff --git a/files/en-us/web/http/headers/want-content-digest/index.md b/files/en-us/web/http/headers/want-content-digest/index.md index 04bb314198fe5dc..8f18c28b3e970af 100644 --- a/files/en-us/web/http/headers/want-content-digest/index.md +++ b/files/en-us/web/http/headers/want-content-digest/index.md @@ -2,13 +2,17 @@ title: Want-Content-Digest slug: Web/HTTP/Headers/Want-Content-Digest page-type: http-header -spec-urls: https://datatracker.ietf.org/doc/html/rfc9530 +spec-urls: https://datatracker.ietf.org/doc/html/rfc9530#section-4 --- {{HTTPSidebar}} -The HTTP **`Want-Content-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates that the recipient should send a {{HTTPHeader("Content-Digest")}} header. -It is the `Content-` analogue of {{HTTPHeader("Want-Repr-Digest")}}. +The HTTP **`Want-Content-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates a preference for the recipient to send a {{HTTPHeader("Content-Digest")}} integrity header in messages associated with the request URI and representation metadata. + +The header includes hashing algorithm preferences that the recipient can use in subsequent messages. +The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely. + +Some implementations may send unsolicited `Content-Digest` headers without requiring a `Want-Content-Digest` header in a previous message.
@@ -26,15 +30,15 @@ It is the `Content-` analogue of {{HTTPHeader("Want-Repr-Digest")}}. ## Syntax ```http -Want-Content-Digest: = +Want-Content-Digest: = ``` ## Directives -`Want-Content-Digest` describes an [RFC8941 dictionary](https://www.rfc-editor.org/rfc/rfc8941#section-3.2) with its keys being hashing algorithms and its values being the integers `0` (meaning "not acceptable") or `1` to `9` (conveying ascending, relative, weighted preference). - -- `` - - : For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}. +- `` + - : The algorithm used to create a digest of the message content. + Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`. + The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`. - `` - : An integer from 0 to 9 where `0` means "not acceptable", and the values `1` to `9` convey ascending, relative, weighted preference. In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values). @@ -69,3 +73,4 @@ Developers can set and get HTTP headers using `fetch()` in order to provide appl ## See also - {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Repr-Digest")}} digest headers +- [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com) diff --git a/files/en-us/web/http/headers/want-repr-digest/index.md b/files/en-us/web/http/headers/want-repr-digest/index.md index e0dfdc66d49c6b6..92e2dec4061d1a9 100644 --- a/files/en-us/web/http/headers/want-repr-digest/index.md +++ b/files/en-us/web/http/headers/want-repr-digest/index.md @@ -2,12 +2,17 @@ title: Want-Repr-Digest slug: Web/HTTP/Headers/Want-Repr-Digest page-type: http-header -spec-urls: https://datatracker.ietf.org/doc/html/rfc9530 +spec-urls: https://datatracker.ietf.org/doc/html/rfc9530#section-4 --- {{HTTPSidebar}} -The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates that the recipient should send a {{HTTPHeader("Repr-Digest")}} header. +The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{glossary("response header")}} indicates a preference for the recipient to send a {{HTTPHeader("Repr-Digest")}} integrity header in messages associated with the request URI and representation metadata. + +The header includes hashing algorithm preferences that the recipient can use in subsequent messages. +The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely. + +Some implementations may send unsolicited `Repr-Digest` headers without requiring a `Want-Repr-Digest` header in a previous message.
@@ -25,13 +30,15 @@ The HTTP **`Want-Repr-Digest`** {{glossary("request header", "request")}} and {{ ## Syntax ```http -Want-Repr-Digest: = +Want-Repr-Digest: = ``` ## Directives -- `` - - : For permissible digest algorithms see {{HTTPHeader("Repr-Digest")}}. +- `` + - : The algorithm used to create a digest of the representation. + Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`. + The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`. - `` - : An integer from 0 to 9 where `0` means "not acceptable", and the values `1` to `9` convey ascending, relative, weighted preference. In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values). @@ -55,3 +62,4 @@ Developers can set and get HTTP headers using `fetch()` in order to provide appl ## See also - {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Content-Digest")}} digest headers +- [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com) 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 164be6966918047..b2731166fa1a9b8 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 @@ -7,15 +7,8 @@ browser-compat: http.headers.X-Content-Type-Options {{HTTPSidebar}} -The HTTP **`X-Content-Type-Options`** {{Glossary("response header")}} is a marker used by the server to indicate that the [MIME types](/en-US/docs/Web/HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should be followed and not be changed. -The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) by saying that the MIME types are deliberately configured. - -This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types. -Since then, other browsers have introduced it, even if their MIME sniffing algorithms were less aggressive. - -Starting with Firefox 72, top-level documents also avoid MIME sniffing (if {{HTTPHeader("Content-type")}} is provided). -This can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than `text/html`. -Make sure to set both headers correctly. +The HTTP **`X-Content-Type-Options`** {{Glossary("response header")}} indicates that the [MIME types](/en-US/docs/Web/HTTP/MIME_types) advertised in the {{HTTPHeader("Content-Type")}} headers should be respected and not changed. +The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) by specifying that the MIME types are deliberately configured. Site security testers usually expect this header to be set. @@ -49,6 +42,15 @@ X-Content-Type-Options: nosniff `style` and the MIME type is not `text/css`, or of type `script` and the MIME type is not a [JavaScript MIME type](https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type). +## Description + +This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types. +Since then, other browsers have introduced it, even if their MIME sniffing algorithms were less aggressive. + +Starting with Firefox 72, top-level documents also avoid MIME sniffing (if {{HTTPHeader("Content-type")}} is provided). +This can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than `text/html`. +Both headers should be set correctly to avoid this. + ## Specifications {{Specifications}} diff --git a/files/en-us/web/http/headers/x-dns-prefetch-control/index.md b/files/en-us/web/http/headers/x-dns-prefetch-control/index.md index bb435ce96569ffd..03fffd21eef1f16 100644 --- a/files/en-us/web/http/headers/x-dns-prefetch-control/index.md +++ b/files/en-us/web/http/headers/x-dns-prefetch-control/index.md @@ -9,10 +9,10 @@ browser-compat: http.headers.X-DNS-Prefetch-Control {{HTTPSidebar}}{{Non-standard_header}} -The HTTP **`X-DNS-Prefetch-Control`** {{Glossary("response header")}} controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. +The HTTP **`X-DNS-Prefetch-Control`** {{Glossary("response header")}} controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. -This prefetching is performed in the background, so that the {{glossary("DNS")}} is likely to have been resolved by the time the referenced items are needed. -This reduces latency when the user clicks a link. +The intention is that prefetching is performed in the background so that the {{glossary("DNS")}} resolution is complete by the time the referenced items are needed by the browser. +This reduces latency when the user clicks a link, for example.
@@ -37,11 +37,9 @@ X-DNS-Prefetch-Control: off ### Directives - `on` - - : Enables DNS prefetching. This is what browsers do, if they support the feature, when - this header is not present + - : Enables DNS prefetching. This is what browsers do if they support the feature when this header is not present. - `off` - - : Disables DNS prefetching. This is useful if you don't control the link on the pages, - or know that you don't want to leak information to these domains. + - : Disables DNS prefetching. This is useful if you don't control the link on the pages or know that you don't want to leak information to these domains. ## Description diff --git a/files/en-us/web/http/headers/x-forwarded-for/index.md b/files/en-us/web/http/headers/x-forwarded-for/index.md index ee1218dff19b66f..35c4a85177de109 100644 --- a/files/en-us/web/http/headers/x-forwarded-for/index.md +++ b/files/en-us/web/http/headers/x-forwarded-for/index.md @@ -8,21 +8,12 @@ status: {{HTTPSidebar}} -The HTTP **`X-Forwarded-For`** (XFF) {{Glossary("request header")}} is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server. +The HTTP **`X-Forwarded-For`** (XFF) {{Glossary("request header")}} is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a {{Glossary("proxy server")}}. +A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header. > [!WARNING] -> Improper use of this header can be a security risk. For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section. - -When a client connects directly to a server, the -client's IP address is sent to the server (and is often written to server -access logs). But if a client connection passes through any [forward or reverse](https://en.wikipedia.org/wiki/Proxy_server) proxies, the server only -sees the final proxy's IP address, which is often of little use. That's especially true if -the final proxy is a load balancer which is part of the same installation -as the server. So, to provide a more-useful client IP address to the server, the `X-Forwarded-For` request header is -used. - -For detailed guidance on using `X-Forwarded-For`, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections. -A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header. +> Improper use of this header can be a security risk. +> For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section.
@@ -37,109 +28,119 @@ A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} he
-## Security and privacy concerns - -This header, by design, exposes privacy-sensitive information, such as the IP address -of the client. Therefore the user's privacy must be kept in mind when deploying this -header. +## Syntax -The `X-Forwarded-For` header is untrustworthy when no trusted reverse proxy (e.g., a load balancer) is between the client and -server. If the client and all proxies are benign and well-behaved, then the list of IP addresses in the header -has the meaning described in the [Directives](#directives) section. But if there's a risk the client or any proxy -is malicious or misconfigured, then it's possible any part (or the entirety) of the header may have been -spoofed (and may not be a list or contain IP addresses at all). +For example: -If any trusted reverse proxies are between the client and -server, the final `X-Forwarded-For` IP addresses (one for each trusted proxy) are trustworthy, as they -were added by trusted proxies. (That's true as long as the server is _only_ -accessible through those proxies and not also directly). +```http +// An IPV6 client IP +X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348 -Any security-related use of `X-Forwarded-For` (such as for rate limiting or IP-based -access control) _must only_ use IP addresses added by a trusted proxy. Using untrustworthy -values can result in rate-limiter avoidance, access-control bypass, memory exhaustion, or -other negative security or availability consequences. +// An IPV4 client IP +X-Forwarded-For: 203.0.113.195 -Conversely, leftmost (untrusted) values must only be used where there will be no negative -impact from the possibility of using spoofed values. +// An IPV4 client IP and an IPV6 proxy IP +X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348 +``` -## Syntax +Using the following syntax: ```http -X-Forwarded-For: , , +X-Forwarded-For: , [, ] ``` -Elements are comma-separated, with optional whitespace surrounding the commas. - ## Directives - `` - - : The client IP address -- ``, `` - - : If a request goes through multiple proxies, the IP addresses of each successive - proxy is listed. This means that, given well-behaved client and proxies, the rightmost - IP address is the IP address of the most recent proxy and the leftmost IP address is - the IP address of the originating client. + - : The client IP address. +- `` + - : A proxy IP address. + If a request goes through multiple proxies, the IP addresses of each successive proxy is listed. + This means that the rightmost IP address is the IP address of the most recent proxy and the leftmost IP address is the address of the originating client (assuming well-behaved client and proxies). -## Examples +## Description -```http -X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348 +When a client connects directly to a server, the client's IP address is sent to the server and is often written to server access logs. +If a client connection passes through any forward or reverse proxies, the server only sees the final proxy's IP address, which is often of little use. +That's especially true if the final proxy is a load balancer which is part of the same deployment as the server. +To provide a more useful client IP address to the server, the `X-Forwarded-For` request header is used. -X-Forwarded-For: 203.0.113.195 +For detailed guidance on using `X-Forwarded-For`, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections. -X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348 +> [!NOTE] +> The standardized `Forwarded` header may replace the `X-Forwarded-For` header, although you should verify that frameworks, middleware, and any third-party tools support it. +> If upstream services rely on `X-Forwarded-*` headers, replacing them outright with `Forwarded` could lead to compatibility issues. -X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178 -``` +### Security and privacy concerns + +This header exposes privacy-sensitive information by design, such as the IP address of the client. +Therefore, the user's privacy must be kept in mind when deploying this header. + +The `X-Forwarded-For` header is untrustworthy when no **trusted reverse proxy** (e.g., a load balancer) is between the client and server. +If the client and all proxies are trusted and well-behaved, the list of IP addresses in the header has the meaning described in the [Directives](#directives) section. +If there's any risk that the client or any proxy is malicious or misconfigured, it's possible a part or all of the header may be spoofed, may have an unexpected format or contents. + +If trusted reverse proxies are between the client and server, the final `X-Forwarded-For` IP addresses (one for each trusted proxy) are trustworthy, as they were added by trusted proxies. +This is true as long as the server is _only_ accessible through those proxies and not also directly from the internet. + +Any security-related use of `X-Forwarded-For` (such as for rate limiting or IP-based access control) _must only_ use IP addresses added by a trusted proxy. +Using untrustworthy values can result in rate-limiter avoidance, access-control bypass, memory exhaustion, or other negative security or availability consequences. + +Conversely, leftmost (untrusted) values must only be used for cases where there is no negative impact from the possibility of using spoofed values. -## Parsing +### Parsing -Improper parsing of the `X-Forwarded-For` header can result in spoofed values being used -for security-related purposes, resulting in the negative consequences mentioned above. +Improper parsing of the `X-Forwarded-For` header can result in spoofed values being used for security-related purposes, resulting in the negative consequences mentioned above. -There may be multiple `X-Forwarded-For` headers present in a request. The IP addresses in -these headers must be treated as a single list, starting with the first IP address of the -first header and continuing to the last IP address of the last header. There are two ways -of making this single list: +There may be multiple `X-Forwarded-For` headers present in a request. +The IP addresses in these headers must be treated as a single list, starting with the first IP address of the first header and continuing to the last IP address of the last header. +There are two ways of making this single list: -- join the `X-Forwarded-For` full header values with commas and then split by comma into a list, or -- split each `X-Forwarded-For` header by comma into lists and then join the lists +- Join the `X-Forwarded-For` full header values with commas and then split by comma into a list, or +- split each `X-Forwarded-For` header by comma into lists and then join the lists. It is insufficient to use only one of multiple `X-Forwarded-For` headers. -(Some reverse proxies will automatically join multiple `X-Forwarded-For` headers into one, -but it is safest to not assume that this is the case.) +Some reverse proxies will automatically join multiple `X-Forwarded-For` headers into one, but it is safest to not assume that this is the case. -## Selecting an IP address +### Selecting an IP address -When selecting an address, the full list of IPs — from all `X-Forwarded-For` headers — must be used. +When selecting an address, the full list of IPs (from all `X-Forwarded-For` headers) must be used. -When choosing the `X-Forwarded-For` client IP address closest to the client (untrustworthy -and _not_ for security-related purposes), the first IP from the leftmost that is _a valid -address_ and _not private/internal_ should be selected. ("Valid" because spoofed values -may not be IP addresses at all; "not internal/private" because clients may have used -proxies on their internal network, which may have added addresses from the [private IP space](https://en.wikipedia.org/wiki/Private_network).) +When choosing the `X-Forwarded-For` IP address closest to the client (untrustworthy and _not_ for security-related purposes), the first IP from the leftmost that is _a valid address_ and _not private/internal_ should be selected. -When choosing the first _trustworthy_ `X-Forwarded-For` client IP address, additional -configuration is required. There are two common methods: +> [!NOTE] +> We say "a valid address" above because spoofed values may not be actual IP addresses. +> Additionally, we say "not internal/private" because clients may have used proxies on their internal network, which may have added addresses from the [private IP space](https://en.wikipedia.org/wiki/Private_network). -- **Trusted proxy count**: The count of reverse proxies between the internet and the - server is configured. The `X-Forwarded-For` IP list is searched from the rightmost by - that count minus one. (For example, if there is only one reverse proxy, that proxy will - add the client's IP address, so the rightmost address should be used. If there are - three reverse proxies, the last two IP addresses will be internal.) -- **Trusted proxy list**: The IPs or IP ranges of the trusted reverse proxies are - configured. The `X-Forwarded-For` IP list is searched from the rightmost, skipping all - addresses that are on the trusted proxy list. The first non-matching address is the - target address. +When choosing the first _trustworthy_ `X-Forwarded-For` client IP address, additional configuration is required. +There are two common methods: -The first trustworthy `X-Forwarded-For` IP address may belong to an untrusted intermediate -proxy rather than the actual client computer, but it is the only IP suitable for security -uses. +- Trusted proxy count + - : The count of reverse proxies between the internet and the server is configured. + The `X-Forwarded-For` IP list is searched from the rightmost by that count minus one. + For example, if there is only one reverse proxy, that proxy will add the client's IP address, so the rightmost address should be used. + If there are three reverse proxies, the last two IP addresses will be internal. +- Trusted proxy list + - : The IPs or IP ranges of the trusted reverse proxies are configured. + The `X-Forwarded-For` IP list is searched from the rightmost, skipping all addresses that are on the trusted proxy list. + The first non-matching address is the target address. -Note that if the server is directly connectable from the internet — even if it is also -behind a trusted reverse proxy — _no part_ of the `X-Forwarded-For` IP list can be -considered trustworthy or safe for security-related uses. +The first trustworthy `X-Forwarded-For` IP address may belong to an untrusted intermediate proxy rather than the actual client computer, but it is the only IP suitable for security uses. + +> [!NOTE] +> If the server can be directly connected to from the internet — even if it is also behind a trusted reverse proxy — **no part** of the `X-Forwarded-For` IP list can be considered trustworthy or safe for security-related uses. + +## Examples + +### Client and proxy IPs + +From the following `X-Forwarded-For` request header, we can infer that the client IP address is `203.0.113.195`, and the request has passed through two proxies. +The first proxy has an IPv6 address of `2001:db8:85a3:8d3:1319:8a2e:370:7348` and the last proxy in the request chain has an IPv4 address of `198.51.100.178`: + +```http +X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178 +``` ## Specifications diff --git a/files/en-us/web/http/headers/x-forwarded-host/index.md b/files/en-us/web/http/headers/x-forwarded-host/index.md index 900f0af2a060a50..9eb5193a33ffcbe 100644 --- a/files/en-us/web/http/headers/x-forwarded-host/index.md +++ b/files/en-us/web/http/headers/x-forwarded-host/index.md @@ -9,8 +9,13 @@ status: {{HTTPSidebar}} The HTTP **`X-Forwarded-Host`** (XFH) {{Glossary("request header")}} is a de-facto standard header for identifying the original host requested by the client in the {{HTTPHeader("Host")}} HTTP request header. +A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header. -Host names and ports of reverse proxies (load balancers, CDNs) may differ from the origin server handling the request, in that case the `X-Forwarded-Host` header is useful to determine which Host was originally used. +Host names and ports of reverse {{Glossary("Proxy_server", "proxies")}} (load balancers, CDNs) may differ from the origin server handling the request, in that case the `X-Forwarded-Host` header is useful to determine which `Host` was originally used. + +> [!NOTE] +> The standardized `Forwarded` header may replace the `X-Forwarded-Host` header, although you should verify that frameworks, middleware, and any third-party tools support it. +> If upstream services rely on `X-Forwarded-*` headers, replacing them outright with `Forwarded` could lead to compatibility issues. diff --git a/files/en-us/web/http/headers/x-forwarded-proto/index.md b/files/en-us/web/http/headers/x-forwarded-proto/index.md index 67ee60e8614cf52..710c681c619832d 100644 --- a/files/en-us/web/http/headers/x-forwarded-proto/index.md +++ b/files/en-us/web/http/headers/x-forwarded-proto/index.md @@ -8,11 +8,15 @@ status: {{HTTPSidebar}} -The HTTP **`X-Forwarded-Proto`** (XFP) {{Glossary("request header")}} is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer. -Your server access logs contain the protocol used between the server and the load balancer, but not the protocol used between the client and the load balancer. +The HTTP **`X-Forwarded-Proto`** (XFP) {{Glossary("request header")}} is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to a {{Glossary("Proxy_server", "proxy")}} or load balancer. +A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header. + +Server access logs contain the protocol used between the server and the load balancer, but not the protocol used between the client and the load balancer. To determine the protocol used between the client and the load balancer, the `X-Forwarded-Proto` request header can be used. -A standardized version of this header is the HTTP {{HTTPHeader("Forwarded")}} header. +> [!NOTE] +> The standardized `Forwarded` header may replace the `X-Forwarded-Proto` header, although you should verify that frameworks, middleware, and any third-party tools support it. +> If upstream services rely on `X-Forwarded-*` headers, replacing them outright with `Forwarded` could lead to compatibility issues.
@@ -40,11 +44,17 @@ X-Forwarded-Proto: ## Examples +### X-Forwarded-Proto client protocol + +The following header indicates that the original request was made over HTTPS before being forwarded by a proxy or load balancer: + ```http X-Forwarded-Proto: https ``` -Other non-standard forms: +### Non-standard forms + +The following forms may be seen in request headers: ```http # Microsoft diff --git a/files/en-us/web/http/headers/x-powered-by/index.md b/files/en-us/web/http/headers/x-powered-by/index.md index 020fbe736894673..842e04fa381f3aa 100644 --- a/files/en-us/web/http/headers/x-powered-by/index.md +++ b/files/en-us/web/http/headers/x-powered-by/index.md @@ -8,7 +8,7 @@ status: {{HTTPSidebar}} -The HTTP **`X-Powered-By`** {{Glossary("Response header")}} is a non-standard header for identifying the application or framework that generated the response. +The HTTP **`X-Powered-By`** {{Glossary("response header")}} is a non-standard header for identifying the application or framework that generated the response.
@@ -36,7 +36,9 @@ X-Powered-By: ## Examples -### Express response headers +### Express X-Powered-By header + +Express applications will usually include the `X-Powered-By` header in responses with the string `express` as the field value: ```http X-Powered-By: express @@ -49,7 +51,5 @@ Not part of any current specification. ## See also - {{HTTPHeader("Forwarded")}} -- {{HTTPHeader("X-Forwarded-Host")}} -- {{HTTPHeader("X-Forwarded-For")}} -- {{HTTPHeader("X-Forwarded-Proto")}} +- {{HTTPHeader("X-Forwarded-Host")}}, {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Proto")}} headers - {{HTTPHeader("Via")}} diff --git a/files/en-us/web/http/headers/x-xss-protection/index.md b/files/en-us/web/http/headers/x-xss-protection/index.md index 3173f1496a465f4..e9a480f3234cf96 100644 --- a/files/en-us/web/http/headers/x-xss-protection/index.md +++ b/files/en-us/web/http/headers/x-xss-protection/index.md @@ -3,25 +3,26 @@ title: X-XSS-Protection slug: Web/HTTP/Headers/X-XSS-Protection page-type: http-header status: + - deprecated - non-standard browser-compat: http.headers.X-XSS-Protection --- -{{HTTPSidebar}}{{Non-standard_header}} +{{HTTPSidebar}}{{Non-standard_header}}{{deprecated_header}} + +> [!WARNING] +> Even though this feature can protect users of older web browsers that don't yet support {{Glossary("CSP")}}, in some cases, **XSS protection can create XSS vulnerabilities** in otherwise safe websites. See the [Security considerations](#security_considerations) section below for more information. The HTTP **`X-XSS-Protection`** {{Glossary("response header")}} was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting ({{Glossary("Cross-site_scripting", "XSS")}}) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong {{HTTPHeader("Content-Security-Policy")}} that disables the use of inline JavaScript (`'unsafe-inline'`). -> [!WARNING] -> Even though this feature can protect users of older web browsers that don't yet support {{Glossary("CSP")}}, in some cases, **XSS protection can create XSS vulnerabilities** in otherwise safe websites. See the section below for more information. +In terms of web platform support: -> [!NOTE] -> -> - Chrome has [removed their XSS Auditor](https://chromestatus.com/feature/5021976655560704) -> - Firefox has not, and [will not implement `X-XSS-Protection`](https://bugzil.la/528661) -> - Edge has [retired their XSS filter](https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/) -> -> This means that if you do not need to support legacy browsers, it is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) without allowing `unsafe-inline` scripts instead. +- Chrome has [removed their XSS Auditor](https://chromestatus.com/feature/5021976655560704) +- Firefox has not, and [will not implement `X-XSS-Protection`](https://bugzil.la/528661) +- Edge has [retired their XSS filter](https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/) + +This means that if you do not need to support legacy browsers, it is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) without allowing `unsafe-inline` scripts instead.
@@ -45,6 +46,8 @@ X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report= ``` +## Directives + - `0` - : Disables XSS filtering. - `1` @@ -54,7 +57,9 @@ X-XSS-Protection: 1; report= - `1; report=` (Chromium only) - : Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP {{CSP("report-uri")}} directive to send a report. -## Vulnerabilities caused by XSS filtering +## Security considerations + +### Vulnerabilities caused by XSS filtering Consider the following excerpt of HTML code for a webpage: