# Chrome 79+ no longer shows preflight CORS requests

DevFeed: [Chrome 79+ no longer shows preflight CORS requests](<https://devfeed.tech/articles/chrome-79-no-longer-shows-preflight-cors-requests-19046.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/chrome-79-doesnt-show-cors-preflight/>)

Author: HTTP Toolkit; Tim Perry

Published: 2020-02-13T16:25:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [Cross-origin resource sharing (CORS)](<https://devfeed.tech/topics/cors.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>), [Developer Tools](<https://devfeed.tech/topics/developer-tools.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [cors](<https://devfeed.tech/tags/cors.md>), [developer-tools](<https://devfeed.tech/tags/developer-tools.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

Chrome 79 changes how CORS is implemented and removes CORS preflight OPTIONS requests from the Chrome developer tools Network tab. The article explains CORS preflight behavior and notes that the change moves CORS handling out of the core Blink browser engine, with security and debugging implications.

## Source excerpt

Chrome 79 brings some important changes in its CORS implementation, rolling out now, which mean that CORS preflight OPTIONS requests will no longer appear in the network tab of the Chrome developer tools. CORS? Cross-Origin Resource Sharing (CORS) allows web servers to tell browsers which web applications are allowed to talk to them. This applies when a web application tries to send a request to a server with a different origin, for example a page hosted at https://example.com tries to make a request to https://api.mybank.com. For simple requests that are defined to not cause side effects, the browser will make the request, but examine the Access-Control-* headers on the response from the server before allowing the web application to read that data. For more dangerous requests, which could trigger an action on the server, the browser sends a so-called "preflight" request. Before sending the real request, it sends an OPTIONS request to the server that includes Access-Control-Request-* headers describing the method and any restricted headers that the application would like to send. The server then responds with a response including its own Access-Control-* headers, which tell the browser whether or not this is allowed. If it's allowed, the browser goes on to send the real request, if not then the application isn't allowed to make that request, so it fails. Phew, make sense? This is just an outline of CORS, there's quite a bit more detail available in MDN's docs. It trips up quite a few people, and checking that you've done it securely on the server side (i.e. you're not allowing other malicious web applications to do or read things they shouldn't) is harder still. Changes in Chrome 79 In Chrome 79, a new flag was added: If you're running 79+, you can see this on the chrome://flags page. It appears that this was disabled by default at the release in December 2019, but it's intended to be enabled incrementally over the weeks from January 6th 2020, which brings us to app