RTT - HTTP

RTT
===

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The **`RTT`** Client hint request header field provides the approximate round trip time on the application layer, in milliseconds. The RTT hint, unlike transport layer RTT, includes server processing time.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | no |

The RTT value is rounded to the nearest 25 milliseconds to prevent fingerprinting. There are many other mechanisms an attacker might use to obtain similar round-trip information.

The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources.

**Note:** The `Vary` header is used in responses to indicate that a different resource is sent for every different value of the header (see HTTP Caching Vary). Even if `RTT` is used to configure what resources are sent consider omitting it in the `Vary` header — it is likely to change often, which effectively makes the resource uncacheable.

Syntax
------

```http
RTT: <number>
```

Directives
----------

<number>

The approximate round trip time in milliseconds, rounded to the nearest 25 milliseconds.

Examples
--------

A server first needs to opt in to receive the `RTT` header by sending the `Accept-CH` response header containing `RTT`.

```http
Accept-CH: RTT
```

Then on subsequent requests the client might send an `RTT` header back:

```http
RTT: 125
```

Specifications
--------------

| Specification |
| --- |
| Network Information API # rtt-request-header-field |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Network client hints
    + `Downlink`
    + `ECT`
    + `Save-Data`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
* `NetworkInformation.effectiveType`


Accept-Post - HTTP

Accept-Post
===========

The **`Accept-Post`** response HTTP header advertises which media types are accepted by the server for HTTP post requests.

**`Accept-Post`** in response to any method means that `POST` is allowed on the requested resource (any document/media format in the header further indicates that the document format is allowed).

For example, a server receiving a `POST` request with an unsupported media type could reply with `415` `Unsupported Media Type` and an **`Accept-Post`** header referencing one or more supported media types.

**Note:** An IANA registry maintains a complete list of official content encodings.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | yes |

Syntax
------

```http
Accept-Post: <MIME\_type>/<MIME\_subtype>
Accept-Post: <MIME\_type>/\*
Accept-Post: \*/\*
```

**Note:** The `Accept-Post` header specifies a media range in the same way as `Accept`, except that it has no notion of preference (i.e., no `q` arguments). This is because `Accept-Post` is a response header while `Accept` is a request header.

Directives
----------

None.

Examples
--------

```http
Accept-Post: application/example, text/example
Accept-Post: image/webp
Accept-Post: \*/\*
```

Specifications
--------------

| Specification |
| --- |
| Linked Data Platform # header-accept-post |

Browser compatibility
---------------------

Browser compatibility is not relevant for this header (header is sent by server, and the specification does not define client behavior).

See also
--------

* Http method `POST`
* HTTP Semantic and context RFC 7231, section 4.3.3: POST


Downlink - HTTP

Downlink
========

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The **`Downlink`** Client hint request header field provides the approximate bandwidth of the client's connection to the server, in Mbps.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | no |

The `Downlink` value is given in Mbps and rounded to the nearest 25 kilobits per second to prevent fingerprinting. There are many other mechanisms an attacker might use to obtain similar information.

The hint allows a server to choose what information is sent based on the network bandwidth. For example, a server might choose to send smaller versions of images and other resources on low bandwidth networks.

**Note:** The `Vary` header is used in responses to indicate that a different resource is sent for every different value of the header (see HTTP Caching Vary). Even if `Downlink` is used to configure what resources are sent, consider omitting it in the `Vary` header — it is likely to change often, which effectively makes the resource uncacheable.

Syntax
------

```http
Downlink: <number>
```

Directives
----------

<number>

The downlink rate in Mbps, rounded to the nearest 25 kilobits.

Examples
--------

A server first needs to opt in to receive the `Downlink` header by sending the `Accept-CH` response header containing `Downlink`.

```http
Accept-CH: Downlink
```

Then on subsequent requests the client might send a `Downlink` header back:

```http
Downlink: 1.7
```

Specifications
--------------

| Specification |
| --- |
| Network Information API # downlink-request-header-field |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Network client hints
    + `RTT`
    + `ECT`
    + `Save-Data`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
* `NetworkInformation.effectiveType`


Content-Encoding - HTTP

Content-Encoding
================

 The **`Content-Encoding`** representation header lists any encodings that have been applied to the representation (message payload), and in what order.
 This lets the recipient know how to decode the representation in order to obtain the original payload format.
 Content encoding is mainly used to compress the message data without losing information about the origin media type.

Note that the original media/content type is specified in the `Content-Type` header, and that the `Content-Encoding` applies to the representation, or "coded form", of the data. If the original media is encoded in some way (e.g. a zip file) then this information would not be included in the `Content-Encoding` header.

Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate. Compressing a compressed media type such as a zip or jpeg may not be appropriate, as this can make the payload larger.

|  |  |
| --- | --- |
| Header type | Representation header |
| Forbidden header name | no |

Syntax
------

```http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip
```

Directives
----------

`gzip`

 A format using the Lempel-Ziv coding
 (LZ77), with a 32-bit CRC. This is the original format of the UNIX *gzip*
 program. The HTTP/1.1 standard also recommends that the servers supporting this
 content-encoding should recognize `x-gzip` as an alias, for compatibility
 purposes.

`compress`

 A format using the Lempel-Ziv-Welch (LZW) algorithm. The
 value name was taken from the UNIX *compress* program, which implemented this
 algorithm. Like the compress program, which has disappeared from most UNIX
 distributions, this content-encoding is not used by many browsers today, partly
 because of a patent issue (it expired in 2003).

`deflate`

 Using the zlib
 structure (defined in RFC 1950) with the deflate compression
 algorithm (defined in RFC 1951).

`br`
Non-standard

A format using the Brotli algorithm.

Examples
--------

### Compressing with gzip

 On the client side, you can advertise a list of compression schemes that will be sent
 along in an HTTP request. The `Accept-Encoding` header is used for
 negotiating content encoding.

```http
Accept-Encoding: gzip, deflate
```

 The server responds with the scheme used, indicated by the
 `Content-Encoding` response header.

```http
Content-Encoding: gzip
```

 Note that the server is not obligated to use any compression method. Compression highly
 depends on server settings and used server modules.

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.content-encoding |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Accept-Encoding`
* `Transfer-Encoding`


If-Modified-Since - HTTP

If-Modified-Since
=================

 The **`If-Modified-Since`** request HTTP header makes the
 request conditional: the server sends back the requested resource, with a
 `200` status, only if it has been last modified after the given date. If
 the resource has not been modified since, the response is a `304`
 without any body; the `Last-Modified` response header of a previous
 request contains the date of last modification. Unlike
 `If-Unmodified-Since`, `If-Modified-Since` can only be used
 with a `GET` or `HEAD`.

 When used in combination with `If-None-Match`, it is ignored, unless
 the server doesn't support `If-None-Match`.

 The most common use case is to update a cached entity that has no associated
 `ETag`.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

```http
If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

 One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov",
 "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

Examples
--------

```http
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.if-modified-since |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304 Not Modified`


Sec-CH-UA-Model - HTTP

Sec-CH-UA-Model
===============

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-UA-Model`** user agent client hint request header indicates the device model on which the browser is running.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-UA-Model: <device-version>
```

### Directives

`<device-version>`

A string containing the device version. For example "Pixel 3".

Examples
--------

A server requests the `Sec-CH-UA-Model` header by including the `Accept-CH` in a *response* to any request from the client, using the name of the desired header as a token:

```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Model
```

 The client may choose to provide the hint, and add the `Sec-CH-UA-Model` header to subsequent requests.
 For example, on mobile phone the client might add the header as shown:

```http
GET /GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Bitness: "64"
Sec-CH-UA-Model: "Pixel 3 XL"
```

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-model |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Save-Data - HTTP

Save-Data
=========

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

 The **`Save-Data`** network client hint request header field is a boolean which indicates the client's preference for reduced data usage.
 This could be for reasons such as high transfer costs, slow connection speeds, etc.

**`Save-Data`** is a low entropy hint, and hence may be sent by the client even if not requested by the server using an `Accept-CH` response header.
 Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like `Downlink` and `RTT`.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | no |
| CORS-safelisted response header | no |

 A value of `On` indicates explicit user opt-in into a reduced data usage
 mode on the client, and when communicated to origins allows them to deliver alternative
 content to reduce the data downloaded such as smaller image and video resources,
 different markup and styling, disabled polling and automatic updates, and so on.

**Note:** Disabling HTTP/2 Server Push (RFC 7540, section 8.2: Server Push) might be desirable too for reducing data downloads.

Syntax
------

```http
Save-Data: <sd-token>
```

Directives
----------

`<sd-token>`

 A value indicating whether the client wants to opt in to reduced data usage mode.
 `on` indicates yes, while `off` (the default) indicates no.

Examples
--------

 The `Vary` header ensures that the content is cached properly (for
 instance ensuring that the user is not served a lower-quality image from the cache when
 `Save-Data` header is no longer present [*e.g.* after having switched from cellular to Wi-Fi]).

### With `Save-Data: on`

Request:

```http
GET /image.jpg HTTP/1.1
Host: example.com
Save-Data: on
```

Response:

```http
HTTP/1.1 200 OK
Content-Length: 102832
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[…]
```

### Without `Save-Data`

Request:

```http
GET /image.jpg HTTP/1.1
Host: example.com
```

Response:

```http
HTTP/1.1 200 OK
Content-Length: 481770
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[…]
```

Specifications
--------------

| Specification |
| --- |
| Save Data API # save-data-request-header-field |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Help Your Users `Save-Data` - CSS Tricks
* Delivering Fast and Light Applications with Save-Data - web.dev
* `Vary` header which indicates that the content served varies depending on the value of `Save-Data` (see HTTP Caching > Vary)
* CSS @media feature `prefers-reduced-data`
Experimental
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `NetworkInformation.saveData`


Warning - HTTP

Warning
=======

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

 The **`Warning`** HTTP header contains information about possible problems with the status of the message.
 More than one `Warning` header may appear in a response.

`Warning` header fields can, in general, be applied to any message.
 However, some warn-codes are specific to caches and can only be applied to response messages.

|  |  |
| --- | --- |
| Header type | Request header,
 Response header |
| Forbidden header name | no |

Syntax
------

```http
Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
```

Directives
----------

<warn-code>

A three-digit warning number. The first digit indicates whether the `Warning` is required to be deleted from a stored response after validation.

* `1xx` warn-codes describe the freshness or validation status of the response and will be deleted by a cache after successful validation.
* `2xx` warn-codes describe some aspect of the representation that is not rectified by a validation and will not be deleted by a cache after validation unless a full response is sent.

<warn-agent>

The name or pseudonym of the server or software adding the `Warning` header (might be "-" when the agent is unknown).

<warn-text>

An advisory text describing the error.

<warn-date>

A date. This is optional. If more than one `Warning` header is sent, include a date that matches the `Date` header.

Warning codes
-------------

The HTTP Warn Codes registry at iana.org defines the namespace for warning codes.

| Code | Text | Description |
| --- | --- | --- |
| 110 | Response is Stale | The response provided by a cache is stale (the expiration time set for the response has passed). |
| 111 | Revalidation Failed | An attempt to validate the stale response failed due to an inability to reach the server. |
| 112 | Disconnected Operation | The cache is intentionally disconnected from the rest of the network. |
| 113 | Heuristic Expiration | A cache heuristically chose a freshness lifetime greater than 24 hours and the age of the response is greater than 24 hours. |
| 199 | Miscellaneous Warning | Arbitrary information that should be presented to a user or logged. |
| 214 | Transformation Applied | Added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type or the like. |
| 299 | Miscellaneous Persistent Warning | Arbitrary information that should be presented to a user or logged. This warn-code is similar to the warn-code 199 and additionally indicates a persistent warning. |

Examples
--------

```http
Warning: 110 anderson/1.3.37 "Response is stale"

Date: Wed, 21 Oct 2015 07:28:00 GMT
Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"
```

Specifications
--------------

| Specification |
| --- |
| HTTP Caching # field.warning |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Date`
* HTTP response status codes


Accept-Patch - HTTP

Accept-Patch
============

The **`Accept-Patch`** response HTTP header advertises which media-type the server is able to understand in a PATCH request.

**`Accept-Patch`** in response to any method means that PATCH is allowed on the resource identified by the Request-URI. Two common cases lead to this:

A server receiving a PATCH request with an unsupported media type could reply with `415` `Unsupported Media Type` and an Accept-Patch header referencing one or more supported media types.

**Note:**

* An IANA registry maintains a complete list of official content encodings.
* Two others content encoding, `bzip` and `bzip2`, are sometimes used, though not standard. They implement the algorithm used by these two UNIX programs. Note that the first one was discontinued due to patent licensing problems.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | yes |

Syntax
------

```http
Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

Directives
----------

None

Examples
--------

```http
Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

Specifications
--------------

| Specification |
| --- |
| RFC 5789 # section-3.1 |

Browser compatibility
---------------------

Browser compatibility is not relevant for this header (header is sent by server, and the specification does not define client behavior).

See also
--------

* Http method `PATCH`
* HTTP Semantic and context RFC 7231, section 4.3.4: PUT


Alt-Used - HTTP

Alt-Used
========

The `Alt-Used` HTTP header is used in requests to identify the alternative service in use, just as the `Host` HTTP header field identifies the host and port of the origin.

The is intended to allow alternative services to detect loops, differentiate traffic for purposes of load balancing, and generally to ensure that it is possible to identify the intended destination of traffic, since introducing this information after a protocol is in use has proven to be problematic.

When a client uses an alternative service for a request, it can indicate this to the server using the `Alt-Used` HTTP header.

Syntax
------

```http
Alt-Used: <host>:<port>
```

Directives
----------

<host>

the domain name of the server.

<port> Optional

TCP port number on which the server is listening.

Examples
--------

```http
Alt-Used: alternate.example.net
```

See also
--------

* `Alt-Svc`
* `Host`


Date - HTTP

Date
====

 The **`Date`** general HTTP header contains the date and time
 at which the message originated.

**Warning:** `Date` is listed
 in the forbidden header names
 in the fetch spec, so this code will not send the `Date` header:

```js
fetch("https://httpbin.org/get", {
  headers: {
    Date: new Date().toUTCString(),
  },
});
```

|  |  |
| --- | --- |
| Header type | Request header,
 Response header |
| Forbidden header name | yes |

Syntax
------

```http
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

 One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct",
 "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

GMT

 Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local
 time.

Examples
--------

```http
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.date |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Age`


X-Forwarded-For - HTTP

X-Forwarded-For
===============

The **`X-Forwarded-For`** (XFF) 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.

**Warning:** Improper use of this header can be a security risk. For details, see the 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 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 this header, see the Parsing and Selecting an IP address sections.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

A standardized version of this header is the HTTP `Forwarded` header.

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.

 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 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).

 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).

 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 where there will be no negative
 impact from the possibility of using spoofed values.

Syntax
------

```http
X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

Elements are comma-separated, with optional whitespace surrounding the commas.

Directives
----------

<client>

The client IP address

<proxy1>, <proxy2>

 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.

Examples
--------

```http
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178
```

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.

 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

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.)

Selecting an IP address
-----------------------

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.)

 When choosing the first *trustworthy* `X-Forwarded-For` client IP address, additional
 configuration is required. There are two common methods:

* **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.

 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 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.

Specifications
--------------

 Not part of any current specification. The standardized version of this header is
 `Forwarded`.

See also
--------

* `Forwarded`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via`


Authorization - HTTP

Authorization
=============

The HTTP **`Authorization`** request header can be used to provide credentials that authenticate a user agent with a server, allowing access to a protected resource.

 The **`Authorization`** header is usually, but not always, sent after the user agent first attempts to request a protected resource without credentials.
 The server responds with a `401` `Unauthorized` message that includes at least one `WWW-Authenticate` header.
 This header indicates what authentication schemes can be used to access the resource (and any additional information needed by the client to use them).
 The user-agent should select the most secure authentication scheme that it supports from those offered, prompt the user for their credentials, and then re-request the resource (including the encoded credentials in the **`Authorization`** header).

This header is stripped from cross-origin redirects.

**Note:** This header is part of the General HTTP authentication framework.
 It can be used with a number of authentication schemes.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

```http
Authorization: <auth-scheme> <authorization-parameters>
```

Basic authentication

```http
Authorization: Basic <credentials>
```

Digest authentication

```http
Authorization: Digest username=<username>,
 realm="<realm>",
 uri="<url>",
 algorithm=<algorithm>,
 nonce="<nonce>",
 nc=<nc>,
 cnonce="<cnonce>",
 qop=<qop>,
 response="<response>",
 opaque="<opaque>"
```

Directives
----------

`<auth-scheme>`

 The Authentication scheme that defines how the credentials are encoded.
 Some of the more common types are (case-insensitive): `Basic`, `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.

**Note:** For more information/options see HTTP Authentication > Authentication schemes

 Other than `<auth-scheme>` the remaining directives are specific to each authentication scheme.
 Generally you will need to check the relevant specifications for these (keys for a small subset of schemes are listed below).

### Basic

<credentials>

The credentials, encoded according to the specified scheme.

**Note:** For information about the encoding algorithm, see the examples: below, in `WWW-Authenticate`, in HTTP Authentication, and in the relevant specifications.

### Digest

<response>

 A string of the hex digits that proves that the user knows a password.
 The algorithm encodes the username and password, realm, cnonce, qop, nc, and so on.
 It is described in detail in the specification.

`username`

 A quoted string containing user's name for the specified `realm` in either plain text or the hash code in hexadecimal notation.
 If the name contains characters that aren't allowed in the field, then `username*` can be used instead (not "as well").

`username*`

 The user's name formatted using an extended notation defined in RFC5987.
 This should be used only if the name can't be encoded in `username` and if `userhash` is set `"false"`.

`uri`

The *Effective Request URI*. See the specification for more information.

`realm`

Realm of the requested username/password (again, should match the value in the corresponding `WWW-Authenticate` response for the resource being requested).

`opaque`

The value in the corresponding `WWW-Authenticate` response for the resource being requested.

`algorithm`

The algorithm used to calculate the digest. Must be a supported algorithm from the `WWW-Authenticate` response for the resource being requested.

`qop`

 A token indicating the *quality of protection* applied to the message.
 Must match the one value in the set specified in the `WWW-Authenticate` response for the resource being requested.

* `"auth"`: Authentication
* `"auth-int"`: Authentication with integrity protection

`cnonce`

 An quoted ASCII-only string value provided by the client.
 This is used by both the client and server to provide mutual authentication, provide some message integrity protection, and avoid "chosen plaintext
 attacks".
 See the specification for additional information.

`nc`

 Nonce count. The hexadecimal count of requests in which the client has sent the current `cnonce` value (including the current request).
 The server can use duplicate `nc` values to recognize replay requests.

`userhash` Optional

`"true"` if the username has been hashed. `"false"` by default.

Examples
--------

### Basic authentication

For `"Basic"` authentication the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in `base64` (`YWxhZGRpbjpvcGVuc2VzYW1l`).

```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

**Warning:** Base64-encoding can easily be reversed to obtain the original name and password, so Basic authentication is completely insecure.
 HTTPS is always recommended when using authentication, but is even more so when using `Basic` authentication.

See also HTTP authentication for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.authorization |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTTP authentication
* `WWW-Authenticate`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


Access-Control-Allow-Methods - HTTP

Access-Control-Allow-Methods
============================

 The **`Access-Control-Allow-Methods`** response header
 specifies one or more methods allowed when accessing a resource in response to a
 preflight request.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Access-Control-Allow-Methods: <method>, <method>, …
Access-Control-Allow-Methods: \*
```

Directives
----------

<method>

A comma-delimited list of the allowed HTTP request methods.

`*` (wildcard)

 The value "`*`" only counts as a special wildcard value for requests
 without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is
 treated as the literal method name "`*`" without special semantics.

Examples
--------

```http
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Methods: \*
```

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-methods |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`


X-Forwarded-Proto - HTTP

X-Forwarded-Proto
=================

 The **`X-Forwarded-Proto`** (XFP) 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. 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 `Forwarded` header.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

```http
X-Forwarded-Proto: <protocol>
```

Directives
----------

<protocol>

The forwarded protocol (http or https).

Examples
--------

```http
X-Forwarded-Proto: https
```

Other non-standard forms:

```http
# Microsoft
Front-End-Https: on

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https
```

Specifications
--------------

 Not part of any current specification. The standardized version of this header is
 `Forwarded`.

See also
--------

* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Host`


Device-Memory - HTTP

Device-Memory
=============

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Device-Memory`** device client hint request header field indicates the approximate amount of available RAM on the client device. The header is part of the Device Memory API.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | no |

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Device-Memory` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Device-Memory` client hint will typically also specify it in the `Vary` header. This informs caches that the server may send different responses based on the header value in a request.

Syntax
------

```http
Device-Memory: <number>
```

Directives
----------

`<number>`

The approximate amount of device RAM. Possible values are: `0.25`, `0.5`, `1`, `2`, `4`, `8`.

The amount of device RAM can be used as a fingerprinting variable, so values for the header are intentionally coarse to reduce the potential for its misuse.

Examples
--------

The server first needs to opt in to receive `Device-Memory` header by sending the response headers `Accept-CH` containing `Device-Memory`.

```http
Accept-CH: Device-Memory
```

Then on subsequent requests the client might send `Device-Memory` header back:

```http
Device-Memory: 1
```

Specifications
--------------

| Specification |
| --- |
| Device Memory # iana-device-memory |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device Memory API
* `Navigator.deviceMemory`
* `WorkerNavigator.deviceMemory`
* Device client hints
    + `Content-DPR`
    + `DPR`
    + `Viewport-Width`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Sec-CH-UA-Platform-Version - HTTP

Sec-CH-UA-Platform-Version
==========================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-UA-Platform-Version`** user agent client hint request header provides the version of the operating system on which the user agent is running.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-UA-Platform-Version: <version>
```

### Directives

`<version>`

 The version string typically contains the operating system version in a string, consisting of dot-separated major, minor and patch version numbers.
 For example, `"11.0.0"`

The version string on Linux is always empty.

Examples
--------

A server requests the `Sec-CH-UA-Platform-Version` header by including the `Accept-CH` in a *response* to any request from the client, using the name of the desired header as a token:

```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Platform-Version
```

 The client may choose to provide the hint, and add the `Sec-CH-UA-Platform-Version` header to subsequent requests.
 For example, the following request headers might be sent from a browser running on Windows 10.

```http
GET /GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Platform-Version: "10.0.0"
```

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-platform-version |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Expires - HTTP

Expires
=======

 The **`Expires`** HTTP header contains the date/time after which the
 response is considered expired.

 Invalid expiration dates with value 0 represent a date in the past and mean that the
 resource is already expired.

**Note:** If there is a `Cache-Control` header
 with the `max-age` or `s-maxage` directive in the response,
 the `Expires` header is ignored.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |
| CORS-safelisted response header | yes |

Syntax
------

```http
Expires: <http-date>
```

Directives
----------

<http-date>

An HTTP-date timestamp.

Examples
--------

```http
Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

Specifications
--------------

| Specification |
| --- |
| HTTP Caching # field.expires |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Cache-Control`
* `Age`


Strict-Transport-Security - HTTP

Strict-Transport-Security
=========================

The HTTP **`Strict-Transport-Security`** response header (often abbreviated as HSTS) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

**Note:** This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload
```

Directives
----------

`max-age=<expire-time>`

The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.

`includeSubDomains` Optional

If this optional parameter is specified, this rule applies to all of the site's subdomains as well.

`preload` Optional
Non-standard

 See Preloading Strict Transport Security for details. When using `preload`, the `max-age` directive must be at least `31536000` (1 year), and the `includeSubDomains` directive must be present.
 Not part of the specification.

Description
-----------

 If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types `http://www.foo.com/` or even just foo.com.
 This creates an opportunity for a man-in-the-middle attack.
 The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

**Note:** The `Strict-Transport-Security` header is *ignored* by the browser when your site has only been accessed using HTTP.
 Once your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the `Strict-Transport-Security` header.
 Browsers do this as attackers may intercept HTTP connections to the site and inject or remove the header.

### An example scenario

 You log into a free Wi-Fi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a couple of bills.
 Unfortunately, the access point you're using is actually a hacker's laptop, and they're intercepting your original HTTP request and redirecting you to a clone of your bank's site instead of the real thing. Now your private data is exposed to the hacker.

 Strict Transport Security resolves this problem; as long as you've accessed your bank's website once using HTTPS, and the bank's website uses Strict Transport Security, your
 browser will know to automatically use only HTTPS, which prevents hackers from performing this sort of man-in-the-middle attack.

### How the browser handles it

The first time your site is accessed using HTTPS and it returns the `Strict-Transport-Security` header, the browser records this information, so that future attempts to load the site using HTTP will automatically use HTTPS instead.

When the expiration time specified by the `Strict-Transport-Security` header elapses, the next attempt to load the site via HTTP will proceed as normal instead of automatically using HTTPS.

 Whenever the Strict-Transport-Security header is delivered to the browser, it will update the expiration time for that site, so sites can refresh this information and prevent the timeout from expiring.
 Should it be necessary to disable Strict Transport Security, setting the `max-age` to 0 (over an https connection) will immediately expire the `Strict-Transport-Security` header, allowing access via http.

Preloading Strict Transport Security
------------------------------------

 Google maintains an HSTS preload service.
 By following the guidelines and successfully submitting your domain, you can ensure that browsers will connect to your domain only via secure connections.
 While the service is hosted by Google, all browsers are using this preload list.
 However, it is not part of the HSTS specification and should not be treated as official.

* Information regarding the HSTS preload list in Chrome: https://www.chromium.org/hsts
* Consultation of the Firefox HSTS preload list: nsSTSPreloadList.inc
Examples
--------

 All present and future subdomains will be HTTPS for a `max-age` of 1 year.
 This blocks access to pages or subdomains that can only be served over HTTP.

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

Although a `max-age` of 1 year is acceptable for a domain, two years is the recommended value as explained on https://hstspreload.org.

In the following example, `max-age` is set to 2 years, and is suffixed with `preload`, which is necessary for inclusion in all major web browsers' HSTS preload lists, like Chromium, Edge, and Firefox.

```http
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
```

Specifications
--------------

| Specification |
| --- |
| HTTP Strict Transport Security (HSTS) # section-6.1 |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Blog post: HTTP Strict Transport Security has landed!
* Blog post: HTTP Strict Transport Security (force HTTPS)
* OWASP Article: HTTP Strict Transport Security
* Wikipedia: HTTP Strict Transport Security
* HSTS preload service
* Features restricted to secure contexts


Access-Control-Allow-Origin - HTTP

Access-Control-Allow-Origin
===========================

The **`Access-Control-Allow-Origin`** response header indicates whether the response can be shared with requesting code from the given origin.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Access-Control-Allow-Origin: \*
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

Directives
----------

`*`

For requests *without credentials*, the literal value "`*`" can be specified as a wildcard; the value tells browsers to allow requesting code from any origin to access the resource. Attempting to use the wildcard with credentials results in an error.

`<origin>`

Specifies an origin. Only a single origin can be specified. If the server supports clients from multiple origins, it must return the origin for the specific client making the request.

`null`

Specifies the origin "null".

**Note:** `null` should not be used: "It may seem safe to return `Access-Control-Allow-Origin: "null"`, but the serialization of the Origin of any resource that uses a non-hierarchical scheme (such as `data:` or `file:`) and sandboxed documents is defined to be "null". Many User Agents will grant such documents access to a response with an `Access-Control-Allow-Origin: "null"` header, and any origin can create a hostile document with a "null" Origin. The "null" value for the ACAO header should therefore be avoided."

Examples
--------

A response that tells the browser to allow code from any origin to access a resource will include the following:

```http
Access-Control-Allow-Origin: \*
```

A response that tells the browser to allow requesting code from the origin `https://developer.mozilla.org` to access a resource will include the following:

```http
Access-Control-Allow-Origin: https://developer.mozilla.org
```

Limiting the possible `Access-Control-Allow-Origin` values to a set of allowed origins requires code on the server side to check the value of the `Origin` request header, compare that to a list of allowed origins, and then if the `Origin` value is in the list, set the `Access-Control-Allow-Origin` value to the same value as the `Origin` value.

### CORS and caching

Suppose the server sends a response with an `Access-Control-Allow-Origin` value with an explicit origin (rather than the "`*`" wildcard). In that case, the response should also include a `Vary` response header with the value `Origin` — to indicate to browsers that server responses can differ based on the value of the `Origin` request header.

```http
Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-origin |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Origin`
* `Vary`
* Cross-Origin Resource Sharing (CORS)
* `Cross-Origin-Resource-Policy`


CSP: frame-ancestors - HTTP

CSP: frame-ancestors
====================

The HTTP `Content-Security-Policy` (CSP) **`frame-ancestors`** directive specifies valid parents that may embed a page using `<frame>`, `<iframe>`, `<object>`, or `<embed>`.

Setting this directive to `'none'` is similar to `X-Frame-Options``: deny` (which is also supported in older browsers).

**Note:** **`frame-ancestors`** allows you to specify what parent source may embed a page.
 This differs from **`frame-src`**, which allows you to specify where iframes in a page may be loaded from.

|  |  |
| --- | --- |
| CSP version | 2 |
| Directive type | Navigation directive |
| `default-src` fallback | No. Not setting this allows anything. |
|
 This directive is not supported in the `<meta>`
 element.
  |

Syntax
------

One or more sources can be set for the `frame-ancestors` policy:

```http
Content-Security-Policy: frame-ancestors <source>;
Content-Security-Policy: frame-ancestors <space separated list of sources>;
```

### Sources

<source> can be one of the following:

**Note:** The `frame-ancestors` directive's syntax is similar to a source list of other directives (e.g. `default-src`), but doesn't allow `'unsafe-eval'` or `'unsafe-inline'` for example. It will also not fall back to a `default-src` setting. Only the sources listed below are allowed:

<host-source>

 Internet hosts by name or IP address, as well as an optional URL scheme and/or port number, separated by spaces. The site's address may include an optional leading wildcard (the asterisk character, `'*'`), and you may use a wildcard (again, `'*'`) as the port number, indicating that all legal ports are valid for the source. Single quotes surrounding the host are not allowed.
 Examples:

* `http://*.example.com`: Matches all attempts to load from any subdomain of example.com using the `http:` URL scheme.
* `mail.example.com:443`: Matches all attempts to access port 443 on mail.example.com.
* `https://store.example.com`: Matches all attempts to access store.example.com using `https:`.

**Warning:** If no URL scheme is specified for a `host-source` and the iframe is loaded from an `https` URL, the URL for the page loading the iframe must also be `https`, per the Does URL match expression in origin with redirect count? section of the CSP spec.

<scheme-source>

A scheme such as `http:` or `https:`. The colon is required and scheme should not be quoted. You can also specify data schemes (not recommended).

* `data:` Allows `data:` URLs to be used as a content source. *This is insecure; an attacker can also inject arbitrary `data:` URLs. Use this sparingly and definitely not for scripts.*
* `mediastream:` Allows `mediastream:` URIs to be used as a content source.
* `blob:` Allows `blob:` URIs to be used as a content source.
* `filesystem:` Allows `filesystem:` URIs to be used as a content source.

`'self'`

Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude `blob` and `filesystem` from source directives. Sites needing to allow these content types can specify them using the Data attribute.

`'none'`

Refers to the empty set; that is, no URLs match. The single quotes are required.

Examples
--------

```http
Content-Security-Policy: frame-ancestors 'none';

Content-Security-Policy: frame-ancestors 'self' https://www.example.org;

Content-Security-Policy: frame-ancestors 'self' https://example.org https://example.com https://store.example.com;
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-frame-ancestors |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `X-Frame-Options`
* `frame-src` CSP


CSP: default-src - HTTP

CSP: default-src
================

The HTTP `Content-Security-Policy` (CSP) **`default-src`** directive serves as a fallback for the other CSP fetch directives. For each of the following directives that are absent, the user agent looks for the `default-src` directive and uses this value for it:

* `child-src`
* `connect-src`
* `font-src`
* `frame-src`
* `img-src`
* `manifest-src`
* `media-src`
* `object-src`
* `prefetch-src`
* `script-src`
* `script-src-elem`
* `script-src-attr`
* `style-src`
* `style-src-elem`
* `style-src-attr`
* `worker-src`

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |

Syntax
------

One or more sources can be allowed for the `default-src` policy:

```http
Content-Security-Policy: default-src <source>;
Content-Security-Policy: default-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### No inheritance with default-src

If there are other directives specified, `default-src` does not influence them. The following header:

```http
Content-Security-Policy: default-src 'self'; script-src https://example.com
```

is the same as:

```http
Content-Security-Policy: connect-src 'self';
 font-src 'self';
 frame-src 'self';
 img-src 'self';
 manifest-src 'self';
 media-src 'self';
 object-src 'self';
 script-src https://example.com;
 style-src 'self';
 worker-src 'self'
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-default-src |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* CSP directives (https://www.w3.org/TR/CSP/#csp-directives):
    + Fetch directive
    + Document directive
    + Navigation directive
    + Reporting directive
    + `upgrade-insecure-requests`
    + `block-all-mixed-content`


CSP: report-to - HTTP

CSP: report-to
==============

 The `Content-Security-Policy`
**`Report-To`** HTTP response header field
 instructs the user agent to store reporting endpoints for an origin.

```http
Content-Security-Policy: …; report-to groupname
```

 The directive has no effect in and of itself, but only gains meaning in combination
 with other directives.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Reporting directive |
|
 This directive is not supported in the `<meta>`
 element.
  |

Syntax
------

```http
Content-Security-Policy: report-to <json-field-value>;
```

Examples
--------

 See `Content-Security-Policy-Report-Only` for more information and
 examples.

```http
Report-To: { "group": "csp-endpoint",
 "max\_age": 10886400,
 "endpoints": [
 { "url": "https://example.com/csp-reports" }
 ] },
 { "group": "hpkp-endpoint",
 "max\_age": 10886400,
 "endpoints": [
 { "url": "https://example.com/hpkp-reports" }
 ] }
Content-Security-Policy: …; report-to csp-endpoint
```

```http
Report-To: { "group": "endpoint-1",
 "max\_age": 10886400,
 "endpoints": [
 { "url": "https://example.com/reports" },
 { "url": "https://backup.com/reports" }
 ] }

Content-Security-Policy: …; report-to endpoint-1
```

```http
Reporting-Endpoints: endpoint-1="https://example.com/reports"

Content-Security-Policy: …; report-to endpoint-1
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-report-to |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only`


CSP: frame-src - HTTP

CSP: frame-src
==============

 The HTTP `Content-Security-Policy` (CSP)
 **`frame-src`** directive specifies valid sources for nested
 browsing contexts loading using elements such as `<frame>` and
 `<iframe>`.

**Note:** **`frame-src`** allows you to specify where iframes in a page may be loaded from.
 This differs from **`frame-ancestors`**, which allows you to specify what parent source may embed a page.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| Fallback |
 If this directive is absent, the user agent will look for the
 `child-src` directive (which falls back to the
 `default-src` directive).
  |

Syntax
------

One or more sources can be allowed for the `frame-src` policy:

```http
Content-Security-Policy: frame-src <source>;
Content-Security-Policy: frame-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: frame-src https://example.com/
```

The following `<iframe>` is blocked and won't load:

```html
<iframe src="https://not-example.com/"></iframe>
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-frame-src |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `<frame>` and `<iframe>`
* `frame-ancestors`


CSP: trusted-types - HTTP

CSP: trusted-types
==================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP `Content-Security-Policy` (CSP) **`trusted-types`**
Experimental
 directive instructs user agents to restrict the creation of Trusted Types policies - functions that build non-spoofable, typed values intended to be passed to DOM XSS sinks in place of strings.

Together with **`require-trusted-types-for`** directive, this allows authors to define rules guarding writing values to the DOM and thus reducing the DOM XSS attack surface to small, isolated parts of the web application codebase, facilitating their monitoring and code review. This directive declares an allowlist of trusted type policy names created with `trustedTypes.createPolicy` from Trusted Types API.

Syntax
------

```http
Content-Security-Policy: trusted-types;
Content-Security-Policy: trusted-types 'none';
Content-Security-Policy: trusted-types <policyName>;
Content-Security-Policy: trusted-types <policyName> <policyName> 'allow-duplicates';
```

<policyName>

A valid policy name consists only of alphanumeric characters, or one of "`-#=_/@.%`". A star (`*`) as a policy name instructs the user agent to allow any unique policy name ('`allow-duplicates`' may relax that further).

`'none'`

Disallows creating any Trusted Type policy (same as not specifying any *<policyName>*).

`'allow-duplicates'`

Allows for creating policies with a name that was already used.

Examples
--------

```js
// Content-Security-Policy: trusted-types foo bar 'allow-duplicates';

if (typeof trustedTypes !== "undefined") {
  const policyFoo = trustedTypes.createPolicy("foo", {});
  const policyFoo2 = trustedTypes.createPolicy("foo", {});
  const policyBaz = trustedTypes.createPolicy("baz", {}); // Throws and dispatches a SecurityPolicyViolationEvent.
}
```

Specifications
--------------

| Specification |
| --- |
| Trusted Types # trusted-types-csp-directive |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* Cross-Site Scripting (XSS)
* Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types
* Trusted Types with DOMPurify XSS sanitizer
* Trusted Types polyfill


CSP: require-trusted-types-for - HTTP

CSP: require-trusted-types-for
==============================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP `Content-Security-Policy` (CSP) **`require-trusted-types-for`**
Experimental
 directive instructs user agents to control the data passed to DOM XSS sink functions, like `Element.innerHTML` setter.

When used, those functions only accept non-spoofable, typed values created by Trusted Type policies, and reject strings. Together with **`trusted-types`** directive, which guards creation of Trusted Type policies, this allows authors to define rules guarding writing values to the DOM and thus reducing the DOM XSS attack surface to small, isolated parts of the web application codebase, facilitating their monitoring and code review.

Syntax
------

```http
Content-Security-Policy: require-trusted-types-for 'script';
```

`'script'`

Disallows using strings with DOM XSS injection sink functions, and requires matching types created by Trusted Type policies.

Examples
--------

```js
// Content-Security-Policy: require-trusted-types-for 'script'; trusted-types foo;

const attackerInput = '<svg onload="alert(/cross-site-scripting/)" />';
const el = document.createElement("div");

if (typeof trustedTypes !== "undefined") {
  // Create a policy that can create TrustedHTML values
  // after sanitizing the input strings with DOMPurify library.
  const sanitizer = trustedTypes.createPolicy("foo", {
    createHTML: (input) => DOMPurify.sanitize(input),
  });

  el.innerHTML = sanitizer.createHTML(attackerInput); // Puts the sanitized value into the DOM.
  el.innerHTML = attackerInput; // Rejects a string value; throws a TypeError.
}
```

Specifications
--------------

| Specification |
| --- |
| Trusted Types # require-trusted-types-for-csp-directive |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* Cross-Site Scripting (XSS)
* DOM XSS injection sinks covered by Trusted Types
* Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types
* Trusted Types with DOMPurify XSS sanitizer
* Trusted Types polyfill


CSP: form-action - HTTP

CSP: form-action
================

The HTTP `Content-Security-Policy` (CSP) **`form-action`** directive restricts the URLs which can be used as the target of form submissions from a given context.

**Warning:** Whether `form-action` should block redirects after a form submission is debated and browser implementations of this aspect are inconsistent (e.g. Firefox 57 doesn't block the redirects whereas Chrome 63 does).

|  |  |
| --- | --- |
| CSP version | 2 |
| Directive type | Navigation directive |
| `default-src` fallback | No. Not setting this allows anything. |

Syntax
------

One or more sources can be set for the `form-action` policy:

```http
Content-Security-Policy: form-action <source>;
Content-Security-Policy: form-action <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Meta tag configuration

```html
<meta http-equiv="Content-Security-Policy" content="form-action 'none'" />
```

### Apache configuration

```apacheconf
<IfModule mod\_headers.c>
  Header set Content-Security-Policy "form-action 'none';"
</IfModule>
```

### Nginx configuration

```nginx
add_header Content-Security-Policy "form-action 'none';"
```

### Violation case

Using a `<form>` element with an action set to inline JavaScript will result in a CSP violation.

```html
<meta http-equiv="Content-Security-Policy" content="form-action 'none'" />

<form action="javascript:alert('Foo')" id="form1" method="post">
  <input type="text" name="fieldName" value="fieldValue" />
  <input type="submit" id="submit" value="submit" />
</form>

<!--
// Error: Refused to send form data because it violates the following
// Content Security Policy directive: "form-action 'none'".
-->
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-form-action |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `<form>`


CSP: report-uri - HTTP

CSP: report-uri
===============

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

 The deprecated HTTP `Content-Security-Policy` (CSP)
 **`report-uri`** directive instructs the user agent to report
 attempts to violate the Content Security Policy. These violation reports consist of JSON
 documents sent via an HTTP POST request to the specified URI.

**Warning:** Though the `report-to` directive is intended to replace the deprecated **`report-uri`** directive,
 `report-to` isn't supported in most browsers yet.
 So for compatibility with current browsers
 while also adding forward compatibility when browsers get `report-to` support,
 you can specify both **`report-uri`** and `report-to`:

```http
Content-Security-Policy: …; report-uri https://endpoint.com; report-to groupname
```

 In browsers that support `report-to`,
 the **`report-uri`** directive will be ignored.

 The directive has no effect in and of itself, but only gains meaning in combination
 with other directives.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Reporting directive |
|
 This directive is not supported in the `<meta>`
 element.
  |

Syntax
------

```http
Content-Security-Policy: report-uri <uri>;
Content-Security-Policy: report-uri <uri> <uri>;
```

<uri>

A URI where to POST the report to.

Examples
--------

 See `Content-Security-Policy-Report-Only` for more information and
 examples.

```http
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
```

`/csp-violation-report-endpoint/` could for example run a PHP something like
 the following that logs the JSON detailing the violation and, if the violation is the
 first one added to the log file, sends an email to an administrator:

```php
    <?php

 // Start configure
 $log\_file = dirname(\_\_FILE\_\_) . '/csp-violations.log';
 $log\_file\_size\_limit = 1000000; // bytes - once exceeded no further entries are added
 $email\_address = 'admin@example.com';
 $email\_subject = 'Content-Security-Policy violation';
 // End configuration

 $current\_domain = preg\_replace('/www\./i', '', $\_SERVER['SERVER\_NAME']);
 $email\_subject = $email\_subject . ' on ' . $current\_domain;

 http\_response\_code(204); // HTTP 204 No Content

 $json\_data = file\_get\_contents('php://input');

 // We pretty print the JSON before adding it to the log file
 if ($json\_data = json\_decode($json\_data)) {
 $json\_data = json\_encode($json\_data, JSON\_PRETTY\_PRINT | JSON\_UNESCAPED\_SLASHES);

 if (!file\_exists($log\_file)) {
 // Send an email
 $message = "The following Content-Security-Policy violation occurred on " .
 $current\_domain . ":\n\n" .
 $json\_data .
 "\n\nFurther CPS violations will be logged to the following log file, but no further email notifications will be sent until this log file is deleted:\n\n" .
 $log\_file;
 mail($email\_address, $email\_subject, $message,
 'Content-Type: text/plain;charset=utf-8');
 } else if (filesize($log\_file) > $log\_file\_size\_limit) {
 exit(0);
 }

 file\_put\_contents($log\_file, $json\_data, FILE\_APPEND | LOCK\_EX);
 }
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-report-uri |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only`
* `report-to`


CSP: prefetch-src - HTTP

CSP: prefetch-src
=================

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

 The HTTP `Content-Security-Policy` (CSP)
 **`prefetch-src`** directive specifies valid resources that may
 be prefetched or prerendered.

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `prefetch-src` policy:

```http
Content-Security-Policy: prefetch-src <source>;
Content-Security-Policy: prefetch-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Example
-------

### Prefetch resources do not match header

Given a page with the following Content Security Policy:

```http
Content-Security-Policy: prefetch-src https://example.com/
```

 Fetches for the following code will return network errors, as the URLs provided do not
 match `prefetch-src`'s source list:

```html
<link rel="prefetch" href="https://example.org/" />
<link rel="prerender" href="https://example.org/" />
```

Specifications
--------------

#### No specification found

No specification data found for `http.headers.Content-Security-Policy.prefetch-src`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`


CSP: block-all-mixed-content - HTTP

CSP: block-all-mixed-content
============================

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

**Warning:** This directive is marked as obsolete in the specification: all mixed content is now blocked if it can't be autoupgraded.

The HTTP `Content-Security-Policy` (CSP) **`block-all-mixed-content`** directive prevents loading any assets over HTTP when the page uses HTTPS.

 All mixed content resource requests are blocked, including both active and passive mixed content.
 This also applies to `<iframe>` documents, ensuring the entire page is mixed content-free.

**Note:** The `upgrade-insecure-requests` directive is evaluated before `block-all-mixed-content`.
 If the former is set, the latter does nothing, so set one directive or the other – not both, unless you want to force HTTPS on older browsers that do not force it after a redirect to HTTP.

Syntax
------

```http
Content-Security-Policy: block-all-mixed-content;
```

Examples
--------

```http
Content-Security-Policy: block-all-mixed-content;

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
```

 To disallow http assets on a more granular level, you can also set individual directives to `https:`.
 For example, to disallow insecure HTTP images:

```http
Content-Security-Policy: img-src https:
```

Specifications
--------------

 Not part of any current specification.
 Used to be defined in the outdated Mixed Content Level 1 specification.

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `upgrade-insecure-requests`
* Mixed content


CSP source values - HTTP

CSP source values
=================

 HTTP `Content-Security-Policy` (CSP) header directives that specify a `<source>` from which resources may be loaded can use any one of the values listed below.
 Relevant directives include the fetch directives, along with others listed below.

Sources
-------

`<host-source>`

 Internet host by name or IP address. The URL scheme, port number, and path are optional.
 Wildcards (`'*'`) can be used for subdomains, host address, and port number, indicating that all legal values of each are valid.
 When matching schemes, secure upgrades are allowed (e.g. specifying `http://example.com` will match `https://example.com`).
 Examples:

* `http://*.example.com`: Matches all attempts to load from any subdomain of example.com. Also matches `https` resources.
* `mail.example.com:443`: Matches all attempts to load from port 443 on mail.example.com.
* `https://store.example.com`: Matches all attempts to access store.example.com using `https:`.
* `*.example.com`: Matches all attempts to load from any subdomain of example.com.
* `https://*.example.com:12/path/to/file.js`: Matches all attempts to load from any subdomain of example.com using `https:` on port 12, and only if the path is `/path/to/file.js`.
* `ws://example.com`: Matches all attempts to load from example.com using `ws:`. Also matches `wss` resources.

`<scheme-source>`

 A scheme such as `http:` or `https:`.
 The colon is required.
 Unlike other values below, single quotes shouldn't be used.
 You can also specify data schemes (not recommended).

* `data:` Allows `data:` URLs to be used as a content source.
 *This is insecure; an attacker can also inject arbitrary `data:` URLs. Use this sparingly and definitely not for scripts.*
* `mediastream:` Allows `mediastream:` URIs to be used as a content source.
* `blob:` Allows `blob:` URIs to be used as a content source.
* `filesystem:` Allows `filesystem:` URIs to be used as a content source.

**Note:** if a scheme source is missing, the document origin's scheme is used.
 Secure upgrades are allowed, so if the document is loaded using `https:`, then `example.com` will match `https://example.com` but not `http://example.com`.
 For more information, see CSP Level 3.

`'self'`

 Refers to the origin from which the protected document is being served, including the same URL scheme and port number.
 You must include the single quotes. Some browsers specifically exclude `blob` and `filesystem` from source directives.
 Sites needing to allow these content types can specify them using the Data attribute.

`'unsafe-eval'`

 Allows the use of `eval()` and other unsafe methods for creating code from strings.
 You must include the single quotes.

`'wasm-unsafe-eval'`

 Allows the loading and execution of WebAssembly modules without the need to also allow unsafe JavaScript execution via `'unsafe-eval'`.
 The single quotes are required.

`'unsafe-hashes'`

 Allows enabling specific inline event handlers.
 If you only need to allow inline event handlers and not inline `<script>` elements or `javascript:` URLs, this is a safer method than using the `unsafe-inline` expression.

`'unsafe-inline'`

 Allows the use of inline resources, such as inline `<script>` elements, `javascript:` URLs, inline event handlers, and inline `<style>` elements.
 The single quotes are required.

`'none'`

 Refers to the empty set; that is, no URLs match.
 The single quotes are required.

`'nonce-<base64-value>'`

 An allowlist for specific inline scripts using a cryptographic nonce (number used once).
 The server must generate a unique nonce value each time it transmits a policy.
 It is critical to provide an unguessable nonce, as bypassing a resource's policy is otherwise trivial.
 See unsafe inline script for an example.
 Specifying nonce makes a modern browser ignore `'unsafe-inline'` which could still be set for older browsers without nonce support.

**Note:** The CSP `nonce` source can only be applied to *nonceable* elements (e.g., as the `<img>` element has no `nonce` attribute, there is no way to associate it with this CSP source).

`'<hash-algorithm>-<base64-value>'`

 A sha256, sha384 or sha512 hash of scripts or styles.
 This value consists of the algorithm used to create the hash followed by a hyphen and the base64-encoded hash of the script or style.
 When generating the hash, exclude <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace.
 In CSP 2.0, hash sources can be applied to inline scripts and styles. Hash source expressions are allowed in CSP 3.0 for external scripts in `script-src` directives.
 See the script-src and style-src pages for more information and examples.

`'strict-dynamic'`

 The `strict-dynamic` source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script.
 At the same time, any allowlist or source expressions such as `'self'` or `'unsafe-inline'` are ignored.
 See script-src for an example.

`'report-sample'`

Requires a sample of the violating code to be included in the violation report.

`'inline-speculation-rules'`

Allows the inclusion of speculation rules in scripts (see also `<script type="speculationrules">`).

Relevant directives
-------------------

Directives for which the above sources apply include:

* Fetch directives:
    + `default-src`
    + `child-src`
    + `connect-src`
    + `font-src`
    + `frame-src`
    + `img-src`
    + `manifest-src`
    + `media-src`
    + `object-src`
    + `prefetch-src`
    + `script-src`
    + `script-src-elem`
    + `script-src-attr`
    + `style-src`
    + `style-src-elem`
    + `style-src-attr`
    + `worker-src`
* Document directives:
    + `base-uri`
    + `sandbox`
* Navigation directives:
    + `form-action`
    + `frame-ancestors`


CSP: object-src - HTTP

CSP: object-src
===============

 The HTTP `Content-Security-Policy`
**`object-src`** directive specifies valid sources for the
 `<object>` and `<embed>` elements.

To set allowed types for `<object>` and `<embed>`, use the `plugin-types` directive.

**Note:** Elements controlled by `object-src` are perhaps coincidentally
 considered legacy HTML elements and aren't receiving new standardized features (such as
 the security attributes `sandbox` or `allow` for
 `<iframe>`). Therefore it is recommended to restrict
 this fetch-directive (e.g. explicitly set `object-src 'none'` if possible).

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `object-src` policy:

```http
Content-Security-Policy: object-src <source>;
Content-Security-Policy: object-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: object-src https://example.com/
```

The following `<object>` and `<embed>` elements are blocked and won't load:

```html
<embed src="https://not-example.com/flash"></embed>
<object data="https://not-example.com/plugin"></object>
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-object-src |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `<object>` and `<embed>`
* `plugin-types`


CSP: child-src - HTTP

CSP: child-src
==============

 The HTTP `Content-Security-Policy` (CSP)
 **`child-src`** directive defines the valid sources for web workers and nested browsing
 contexts loaded using elements such as `<frame>` and
 `<iframe>`. For workers, non-compliant requests are treated as fatal
 network errors by the user agent.

|  |  |
| --- | --- |
| CSP version | 2 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `child-src` policy:

```http
Content-Security-Policy: child-src <source>;
Content-Security-Policy: child-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: child-src https://example.com/
```

This `<iframe>` and worker are blocked and won't load:

```html
<iframe src="https://not-example.com"></iframe>

<script>
 const blockedWorker = new Worker("data:application/javascript,…");
</script>
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-child-src |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `<frame>` and `<iframe>`
* `Worker`, `SharedWorker`, `ServiceWorker`


CSP: plugin-types - HTTP

CSP: plugin-types
=================

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

 The HTTP `Content-Security-Policy` (CSP)
 **`plugin-types`** directive restricts the set of plugins that
 can be embedded into a document by limiting the types of resources which can be loaded.

Instantiation of an `<embed>` or `<object>` element will fail if:

* the element to load does not declare a valid MIME type,
* the declared type does not match one of specified types in the
 `plugin-types` directive,
* the fetched resource does not match the declared type.

|  |  |
| --- | --- |
| CSP version | 2 |
| Directive type | Document directive |
| `default-src` fallback | No. Not setting this allows anything. |

Syntax
------

 One or more MIME types can
 be set for the `plugin-types` policy:

```http
Content-Security-Policy: plugin-types <type>/<subtype>;
Content-Security-Policy: plugin-types <type>/<subtype> <type>/<subtype>;
```

<type>/<subtype>

A valid MIME type.

Examples
--------

### Disallowing plugins

 To disallow all plugins, the `object-src` directive should be set to
 `'none'` which will disallow plugins. The `plugin-types` directive
 is only used if you are allowing plugins with `object-src` at all.

```html
<meta http-equiv="Content-Security-Policy" content="object-src 'none'" />
```

Specifications
--------------

Not part of any current specification. Used to be defined in CSP 2.

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`: `object-src`
* `<object>`
* `<embed>`
* `X-Content-Type-Options`


CSP: media-src - HTTP

CSP: media-src
==============

 The HTTP `Content-Security-Policy` (CSP)
 **`media-src`** directive specifies valid sources for loading
 media using the `<audio>` and `<video>` elements.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `media-src` policy:

```http
Content-Security-Policy: media-src <source>;
Content-Security-Policy: media-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: media-src https://example.com/
```

 The following `<audio>`, `<video>` and
 `<track>` elements are blocked and won't load:

```html
<audio src="https://not-example.com/audio"></audio>

<video src="https://not-example.com/video">
  <track kind="subtitles" src="https://not-example.com/subtitles" />
</video>
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-media-src |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy`
* `<audio>`, `<video>` and `<track>`