Lukas Weichselbaum on web.dev

Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)

2021-03-15T00:00:00Z

Why should you deploy a strict Content Security Policy (CSP)? #

Cross-site scripting (XSS)—the ability to inject malicious scripts into a web application—has been one of the biggest web security vulnerabilities for over a decade.

Content Security Policy (CSP) is an added layer of security that helps to mitigate XSS. Configuring a CSP involves adding the Content-Security-Policy HTTP header to a web page and setting values to control what resources the user agent is allowed to load for that page. This article explains how to use a CSP based on nonces or hashes to mitigate XSS instead of the commonly used host-allowlist-based CSPs which often leave the page exposed to XSS as they can be bypassed in most configurations.

A Content Security Policy based on nonces or hashes is often called a strict CSP. When an application uses a strict CSP, attackers who find HTML injection flaws will generally not be able to use them to force the browser to execute malicious scripts in the context of the vulnerable document. This is because strict CSP only permits hashed scripts or scripts with the correct nonce value generated on the server, so attackers cannot execute the script without knowing the correct nonce for a given response.

Browser compatibility #

Strict CSP is supported in all modern browser engines.

Browser support

Chrome 52, Supported 52
Firefox 52, Supported 52
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Why a strict CSP is recommended over allowlist CSPs #

If your site already has a CSP that looks like this: script-src www.googleapis.com, it may not be effective against cross-site scripting! This type of CSP is called an allowlist CSP and it has a couple of downsides:

It requires a lot of customization.
It can be bypassed in most configurations.

This makes allowlist CSPs generally ineffective at preventing attackers from exploiting XSS. That's why it's recommended to use a strict CSP based on cryptographic nonces or hashes, which avoids the pitfalls outlined above.

Allowlist CSP

Doesn't effectively protect your site. ❌
Must be highly customized. 😓

Strict CSP

Effectively protects your site. ✅
Always has the same structure. 😌

What is a strict Content Security Policy? #

A strict Content Security Policy has the following structure and is enabled by setting one of the following HTTP response headers:

Nonce-based strict CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Hash-based strict CSP

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

The following properties make a CSP like the one above "strict" and hence secure:

Uses nonces 'nonce-{RANDOM}' or hashes 'sha256-{HASHED_INLINE_SCRIPT}' to indicate which <script> tags are trusted by the site's developer and should be allowed to execute in the user's browser.
Sets 'strict-dynamic' to reduce the effort of deploying a nonce- or hash-based CSP by automatically allowing the execution of scripts that are created by an already trusted script. This also unblocks the use of most third party JavaScript libraries and widgets.
Not based on URL allowlists and therefore doesn't suffer from common CSP bypasses.
Blocks untrusted inline scripts like inline event handlers or javascript: URIs.
Restricts object-src to disable dangerous plugins such as Flash.
Restricts base-uri to block the injection of <base> tags. This prevents attackers from changing the locations of scripts loaded from relative URLs.

Adopting a strict CSP #

To adopt a strict CSP, you need to:

Decide if your application should set a nonce- or hash-based CSP.
Copy the CSP from the What is a strict Content Security Policy section and set it as a response header across your application.
Refactor HTML templates and client-side code to remove patterns that are incompatible with CSP.
Deploy your CSP.

You can use Lighthouse (v7.3.0 and above with flag --preset=experimental) Best Practices audit throughout this process to check whether your site has a CSP, and whether it's strict enough to be effective against XSS.

Step 1: Decide if you need a nonce- or hash-based CSP #

There are two types of strict CSPs, nonce- and hash-based. Here's how they work:

Nonce-based CSP: You generate a random number at runtime, include it in your CSP, and associate it with every script tag in your page. An attacker can't include and run a malicious script in your page, because they would need to guess the correct random number for that script. This only works if the number is not guessable and newly generated at runtime for every response.
Hash-based CSP: The hash of every inline script tag is added to the CSP. Note that each script has a different hash. An attacker can't include and run a malicious script in your page, because the hash of that script would need to be present in your CSP.

Criteria for choosing a strict CSP approach:

Criteria for choosing a strict CSP approach
Nonce-based CSP	For HTML pages rendered on the server where you can create a new random token (nonce) for every response.
Hash-based CSP	For HTML pages served statically or those that need to be cached. For example, single-page web applications built with frameworks such as Angular, React or others, that are statically served without server-side rendering.

Step 2: Set a strict CSP and prepare your scripts #

When setting a CSP, you have a few options:

Report-only mode (Content-Security-Policy-Report-Only) or enforcement mode (Content-Security-Policy). In report-only, the CSP won't block resources yet—nothing will break—but you'll be able to see errors and receive reports for what would have been blocked. Locally, when you're in the process of setting a CSP, this doesn't really matter, because both modes will show you the errors in the browser console. If anything, enforcement mode will make it even easier for you to see blocked resources and tweak your CSP, since your page will look broken. Report-only mode becomes most useful later in the process (see Step 5).
Header or HTML <meta> tag. For local development, a <meta> tag may be more convenient for tweaking your CSP and quickly seeing how it affects your site. However:
- Later on, when deploying your CSP in production, it is recommended to set it as an HTTP header.
- If you want to set your CSP in report-only mode, you'll need to set it as a header—CSP meta tags don't support report-only mode.

Option A: Nonce-based CSP

Set the following Content-Security-Policy HTTP response header in your application:

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Generate a nonce for CSP #

A nonce is a random number used only once per page load. A nonce-based CSP can only mitigate XSS if the nonce value is not guessable by an attacker. A nonce for CSP needs to be:

A cryptographically strong random value (ideally 128+ bits in length)
Newly generated for every response
Base64 encoded

Here are some examples on how to add a CSP nonce in server-side frameworks:

Django (python)
Express (JavaScript):

const app = express();
app.get('/', function(request, response) {
    // Generate a new random nonce value for every response.
    const nonce = crypto.randomBytes(16).toString("base64");
    // Set the strict nonce-based CSP response header
    const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
    response.set("Content-Security-Policy", csp);
    // Every <script> tag in your application should set the `nonce` attribute to this value.
    response.render(template, { nonce: nonce });
  });
}

Add a `nonce` attribute to `<script>` elements #

With a nonce-based CSP, every <script> element must have a nonce attribute which matches the random nonce value specified in the CSP header (all scripts can have the same nonce). The first step is to add these attributes to all scripts:

Blocked by CSP

<script src="/path/to/script.js"></script>
<script>foo()</script>

CSP will block these scripts, because they don't have nonce attributes.

Allowed by CSP

<script nonce="${NONCE}" src="/path/to/script.js"></script>
<script nonce="${NONCE}">foo()</script>

CSP will allow the execution of these scripts if ${NONCE} is replaced with a value matching the nonce in the CSP response header. Note that some browsers will hide the nonce attribute when inspecting the page source.

Option B: Hash-based CSP Response Header

Set the following Content-Security-Policy HTTP response header in your application:

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

For several inline scripts, the syntax is as follows: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'.

Load sourced scripts dynamically #

All scripts that are externally sourced need to be loaded dynamically via an inline script, because CSP hashes are supported across browsers only for inline scripts (hashes for sourced scripts are not well-supported across browsers).

Blocked by CSP

<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>

CSP will block these scripts since only inline-scripts can be hashed.

Allowed by CSP

<script>
var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];
scripts.forEach(function(scriptUrl) {
  var s = document.createElement('script');
  s.src = scriptUrl;
  s.async = false; // to preserve execution order
  document.head.appendChild(s);
});
</script>

To allow execution of this script, the hash of the inline script must be calculated and added to the CSP response header, replacing the {HASHED_INLINE_SCRIPT} placeholder. To reduce the amount of hashes, you can optionally merge all inline scripts into a single script. To see this in action checkout the example and examine the code.

Script loading considerations #

In the code snippet above, s.async = false is added to ensure that foo executes before bar (even if bar loads first). In this snippet, s.async = false does not block the parser while the scripts load; that's because the scripts are added dynamically. The parser will only stop as the scripts are being executed, just like it would behave for async scripts. However, with this snippet, keep in mind:

One/both scripts may execute before the document has finished downloading. If you want the document to be ready by the time the scripts execute, you need to wait for the DOMContentLoaded event before you append the scripts. If this causes a performance issue (because the scripts don't start downloading early enough), you can use preload tags earlier in the page.
defer = true won't do anything. If you need that behaviour, you'll have to manually run the script at the time you want to run it.

Step 3: Refactor HTML templates and client-side code to remove patterns incompatible with CSP #

Inline event handlers (such as onclick="…", onerror="…") and JavaScript URIs (<a href="javascript:…">) can be used to run scripts. This means that an attacker who finds an XSS bug could inject this kind of HTML and execute malicious JavaScript. A nonce- or hash-based CSP disallows the use of such markup. If your site makes use of any of the patterns described above, you'll need to refactor them into safer alternatives.

If you enabled CSP in the previous step, you'll be able to see CSP violations in the console every time CSP blocks an incompatible pattern.

In most cases, the fix is straightforward:

To refactor inline event handlers, rewrite them to be added from a JavaScript block #

Blocked by CSP

<span onclick="doThings();">A thing.</span>

CSP will block inline event handlers.

Allowed by CSP

<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things')
          .addEventListener('click', doThings);
</script>

CSP will allow event handlers that are registered via JavaScript.

For `javascript:` URIs, you can use a similar pattern #

Blocked by CSP

<a href="javascript:linkClicked()">foo</a>

CSP will block javascript: URIs.

Allowed by CSP

<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo')
          .addEventListener('click', linkClicked);
</script>

CSP will allow event handlers that are registered via JavaScript.

Use of `eval()` in JavaScript #

If your application uses eval() to convert JSON string serializations into JS objects, you should refactor such instances to JSON.parse(), which is also faster.

If you cannot remove all uses of eval(), you can still set a strict nonce-based CSP, but you will have to use the 'unsafe-eval' CSP keyword which will make your policy slightly less secure.

You can find these and more examples of such refactoring in this strict CSP Codelab:

Step 4 (Optional): Add fallbacks to support old browser versions #

Browser support

Chrome 52, Supported 52
Firefox 52, Supported 52
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

If you need to support browser versions older than the one listed above:

Using 'strict-dynamic' requires adding https: as a fallback for old versions of Safari. By doing so:
- All browsers that support 'strict-dynamic' will ignore the https: fallback, so this won't reduce the strength of the policy.
- In old browser, externally sourced scripts will be allowed to load only if they come from an HTTPS origin. This is less secure than a strict CSP–it's a fallback–but would still prevent certain common XSS causes like injections of javascript: URIs because 'unsafe-inline' is not present or ignored in presence of a hash or nonce.
To ensure compatibility with very old browser versions (4+ years), you can add 'unsafe-inline' as a fallback. All recent browsers will ignore 'unsafe-inline' if a CSP nonce or hash is present.

Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Step 5: Deploy your CSP #

After confirming that no legitimate scripts are being blocked by CSP in your local development environment, you can proceed with deploying your CSP to your (staging, then) production environment:

(Optional) Deploy your CSP in report-only mode using the Content-Security-Policy-Report-Only header. Learn more about the Reporting API. Report-only mode is handy to test a potentially breaking change like a new CSP in production, before actually enforcing CSP restrictions. In report-only mode, your CSP does not affect the behavior of your application (nothing will actually break). But the browser will still generate console errors and violation reports when patterns incompatible with CSP are encountered (so you can see what would have broken for your end-users).
Once you're confident that your CSP won't induce breakage for your end-users, deploy your CSP using the Content-Security-Policy response header. Only once you've completed this step, will CSP begin to protect your application from XSS. Setting your CSP via a HTTP header server-side is more secure than setting it as a <meta> tag; use a header if you can.

Limitations #

Generally speaking, a strict CSP provides a strong added layer of security that helps to mitigate XSS. In most cases, CSP reduces the attack surface significantly (dangerous patterns like javascript: URIs are completely turned off). However, based on the type of CSP you're using (nonces, hashes, with or without 'strict-dynamic'), there are cases where CSP doesn't protect:

If you nonce a script, but there's an injection directly into the body or into the src parameter of that <script> element.
If there are injections into the locations of dynamically created scripts (document.createElement('script')), including into any library functions which create script DOM nodes based on the value of their arguments. This includes some common APIs such as jQuery's .html(), as well as .get() and .post() in jQuery < 3.0.
If there are template injections in old AngularJS applications. An attacker who can inject an AngularJS template can use it to execute arbitrary JavaScript.
If the policy contains 'unsafe-eval', injections into eval(), setTimeout() and a few other rarely used APIs.

Developers and security engineers should pay particular attention to such patterns during code reviews and security audits. You can find more details on the cases described above in this CSP presentation.

Protect your resources from web attacks with Fetch Metadata

2020-06-04T00:00:00Z

Why should you care about isolating your web resources? #

Many web applications are vulnerable to cross-origin attacks like cross-site request forgery (CSRF), cross-site script inclusion (XSSI), timing attacks, cross-origin information leaks or speculative execution side-channel (Spectre) attacks.

Fetch Metadata request headers allow you to deploy a strong defense-in-depth mechanism—a Resource Isolation Policy—to protect your application against these common cross-origin attacks.

It is common for resources exposed by a given web application to only be loaded by the application itself, and not by other websites. In such cases, deploying a Resource Isolation Policy based on Fetch Metadata request headers takes little effort, and at the same time protects the application from cross-site attacks.

Browser compatibility #

Fetch Metadata request headers are supported in all modern browser engines.

Browser support

Chrome 76, Supported 76
Firefox 90, Supported 90
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

Background #

Many cross-site attacks are possible because the web is open by default and your application server cannot easily protect itself from communication originating from external applications. A typical cross-origin attack is cross-site request forgery (CSRF) where an attacker lures a user onto a site they control and then submits a form to the server the user is logged in to. Since the server cannot tell if the request originated from another domain (cross-site) and the browser automatically attaches cookies to cross-site requests, the server will execute the action requested by the attacker on behalf of the user.

Other cross-site attacks like cross-site script inclusion (XSSI) or cross-origin information leaks are similar in nature to CSRF and rely on loading resources from a victim application in an attacker-controlled document and leaking information about the victim applications. Since applications cannot easily distinguish trusted requests from untrusted ones, they cannot discard malicious cross-site traffic.

Introducing Fetch Metadata #

Fetch Metadata request headers are a new web platform security feature designed to help servers defend themselves against cross-origin attacks. By providing information about the context of an HTTP request in a set of Sec-Fetch-* headers, they allow the responding server to apply security policies before processing the request. This lets developers decide whether to accept or reject a request based on the way it was made and the context in which it will be used, making it possible to respond to only legitimate requests made by their own application.

Same-Origin

Requests originating from sites served by your own server (same-origin) will continue to work.

Cross-site

Malicious cross-site requests can be rejected by the server because of the additional context in the HTTP request provided by Sec-Fetch-* headers.

`Sec-Fetch-Site` #

Browser support

Chrome 76, Supported 76
Firefox 90, Supported 90
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

Sec-Fetch-Site tells the server which site sent the request. The browser sets this value to one of the following:

same-origin, if the request was made by your own application (e.g. site.example)
same-site, if the request was made by a subdomain of your site (e.g. bar.site.example)
none, if the request was explicitly caused by a user's interaction with the user agent (e.g. clicking on a bookmark)
cross-site, if the request was sent by another website (e.g. evil.example)

`Sec-Fetch-Mode` #

Browser support

Chrome 76, Supported 76
Firefox 90, Supported 90
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

Sec-Fetch-Mode indicates the mode of the request. This roughly corresponds to the type of the request and allows you to distinguish resource loads from navigation requests. For example, a destination of navigate indicates a top-level navigation request while no-cors indicates resource requests like loading an image.

`Sec-Fetch-Dest` #

Browser support

Chrome 80, Supported 80
Firefox 90, Supported 90
Edge 80, Supported 80
Safari 16.4, Supported 16.4

Source

Sec-Fetch-Dest exposes a request's destination (e.g. if a script or an img tag caused a resource to be requested by the browser).

How to use Fetch Metadata to protect against cross-origin attacks #

The extra information these request headers provide is quite simple, but the additional context allows you to build powerful security logic on the server-side, also referred to as a Resource Isolation Policy, with just a few lines of code.

Implementing a Resource Isolation Policy #

A Resource Isolation Policy prevents your resources from being requested by external websites. Blocking such traffic mitigates common cross-site web vulnerabilities such as CSRF, XSSI, timing attacks, and cross-origin information leaks. This policy can be enabled for all endpoints of your application and will allow all resource requests coming from your own application as well as direct navigations (via an HTTP GET request). Endpoints that are supposed to be loaded in a cross-site context (e.g. endpoints loaded using CORS) can be opted out of this logic.

Step 1: Allow requests from browsers which don't send Fetch Metadata #

Since not all browsers support Fetch Metadata, you need to allow requests that don't set Sec-Fetch-* headers by checking for the presence of sec-fetch-site.

if not req['sec-fetch-site']:
  return True  # Allow this request

Step 2: Allow same-site and browser-initiated requests #

Any requests that do not originate from a cross-origin context (like evil.example) will be allowed. In particular, these are requests that:

Originate from your own application (e.g. a same-origin request where site.example requests site.example/foo.json will always be allowed).
Originate from your subdomains.
Are explicitly caused by a user's interaction with the user agent (e.g. direct navigation or by clicking a bookmark, etc.).

if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
  return True  # Allow this request

To ensure that your site can still be linked from other sites, you have to allow simple (HTTP GET) top-level navigation.

if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
  # <object> and <embed> send navigation requests, which we disallow.
  and req['sec-fetch-dest'] not in ('object', 'embed'):
    return True  # Allow this request

Step 4: Opt out endpoints that are meant to serve cross-site traffic (Optional) #

In some cases, your application might provide resources which are meant to be loaded cross-site. These resources need to be exempted on a per-path or per-endpoint basis. Examples of such endpoints are:

Endpoints meant to be accessed cross-origin: If your application is serving endpoints that are CORS enabled, you need to explicitly opt them out from resource isolation to ensure that cross-site requests to these endpoints are still possible.
Public resources (e.g. images, styles, etc.): Any public and unauthenticated resources that should be loadable cross-origin from other sites can be exempted as well.

if req.path in ('/my_CORS_endpoint', '/favicon.png'):
  return True

Step 5: Reject all other requests that are cross-site and not navigational #

Any other cross-site request will be rejected by this Resource Isolation Policy and thus protect your application from common cross-site attacks.

Example: The following code demonstrates a complete implementation of a robust Resource Isolation Policy on the server or as a middleware to deny potentially malicious cross-site resource requests, while allowing simple navigational requests:

# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):
  # Allow requests from browsers which don't send Fetch Metadata
  if not req['sec-fetch-site']:
    return True

  # Allow same-site and browser-initiated requests
  if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
    return True

  # Allow simple top-level navigations except <object> and <embed>
  if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
    and req['sec-fetch-dest'] not in ('object', 'embed'):
      return True

  # [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
  if req.path in ('/my_CORS_endpoint', '/favicon.png'):
    return True

  # Reject all other requests that are cross-site and not navigational
  return False

Deploying a Resource Isolation Policy #

Install a module like the code snippet from above to log and monitor how your site behaves and make sure the restrictions don't affect any legitimate traffic.
Fix potential violations by exempting legitimate cross-origin endpoints.
Enforce the policy by dropping non-compliant requests.

Identifying and fixing policy violations #

It's recommended that you test your policy in a side-effect free way by first enabling it in reporting mode in your server-side code. Alternatively, you can implement this logic in middleware, or in a reverse proxy which logs any violations that your policy might produce when applied to production traffic.

From our experience of rolling out a Fetch Metadata Resource Isolation Policy at Google, most applications are by default compatible with such a policy and rarely require exempting endpoints to allow cross-site traffic.

Enforcing a Resource Isolation Policy #

After you've checked that your policy doesn't impact legitimate production traffic, you're ready to enforce restrictions, guaranteeing that other sites will not be able to request your resources and protecting your users from cross-site attacks.

Lukas Weichselbaum on web.dev

Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)

Why should you deploy a strict Content Security Policy (CSP)? #

Browser compatibility #

Why a strict CSP is recommended over allowlist CSPs #

What is a strict Content Security Policy? #

Adopting a strict CSP #

Step 1: Decide if you need a nonce- or hash-based CSP #

Step 2: Set a strict CSP and prepare your scripts #

Generate a nonce for CSP #

Add a `nonce` attribute to `<script>` elements #

Load sourced scripts dynamically #

Script loading considerations #

Step 3: Refactor HTML templates and client-side code to remove patterns incompatible with CSP #

To refactor inline event handlers, rewrite them to be added from a JavaScript block #

For `javascript:` URIs, you can use a similar pattern #

Use of `eval()` in JavaScript #

Step 4 (Optional): Add fallbacks to support old browser versions #

Step 5: Deploy your CSP #

Limitations #

Further reading #

Protect your resources from web attacks with Fetch Metadata

Why should you care about isolating your web resources? #

Browser compatibility #

Background #

Introducing Fetch Metadata #

`Sec-Fetch-Site` #

`Sec-Fetch-Mode` #

`Sec-Fetch-Dest` #

How to use Fetch Metadata to protect against cross-origin attacks #

Implementing a Resource Isolation Policy #

Step 1: Allow requests from browsers which don't send Fetch Metadata #

Step 2: Allow same-site and browser-initiated requests #

Step 3: Allow simple top-level navigation and iframing #

Step 4: Opt out endpoints that are meant to serve cross-site traffic (Optional) #

Step 5: Reject all other requests that are cross-site and not navigational #

Deploying a Resource Isolation Policy #

Identifying and fixing policy violations #

Enforcing a Resource Isolation Policy #

Further reading #

Lukas Weichselbaum on web.dev

Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)

Why should you deploy a strict Content Security Policy (CSP)? #

Browser compatibility #

Why a strict CSP is recommended over allowlist CSPs #

What is a strict Content Security Policy? #

Adopting a strict CSP #

Step 1: Decide if you need a nonce- or hash-based CSP #

Step 2: Set a strict CSP and prepare your scripts #

Generate a nonce for CSP #

Add a nonce attribute to <script> elements #

Load sourced scripts dynamically #

Script loading considerations #

Step 3: Refactor HTML templates and client-side code to remove patterns incompatible with CSP #

To refactor inline event handlers, rewrite them to be added from a JavaScript block #

For javascript: URIs, you can use a similar pattern #

Use of eval() in JavaScript #

Step 4 (Optional): Add fallbacks to support old browser versions #

Step 5: Deploy your CSP #

Limitations #

Further reading #

Protect your resources from web attacks with Fetch Metadata

Why should you care about isolating your web resources? #

Browser compatibility #

Background #

Introducing Fetch Metadata #

Sec-Fetch-Site #

Sec-Fetch-Mode #

Sec-Fetch-Dest #

How to use Fetch Metadata to protect against cross-origin attacks #

Implementing a Resource Isolation Policy #

Step 1: Allow requests from browsers which don't send Fetch Metadata #

Step 2: Allow same-site and browser-initiated requests #

Step 3: Allow simple top-level navigation and iframing #

Step 4: Opt out endpoints that are meant to serve cross-site traffic (Optional) #

Step 5: Reject all other requests that are cross-site and not navigational #

Deploying a Resource Isolation Policy #

Identifying and fixing policy violations #

Enforcing a Resource Isolation Policy #

Further reading #

Add a `nonce` attribute to `<script>` elements #

For `javascript:` URIs, you can use a similar pattern #

Use of `eval()` in JavaScript #

`Sec-Fetch-Site` #

`Sec-Fetch-Mode` #

`Sec-Fetch-Dest` #