recursal/MDN huggingface dataset:
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`
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: 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
==============

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

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

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

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

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: 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
============================

**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: 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
==============

 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`