My web client application is setting HTTP POST requests via fetch API.
I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab.
I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back?
You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.
This is an expected behavior change according to:
https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1
I originally came across this via:
https://support.google.com/chrome/thread/11089651?hl=en
As of 2021 in CHROME the OPTIONS request is visible in the NETWORK tab filter OTHER requests
To see it together with XHR just CTRL+click and pick the request filters you want to see.
UPDATE (April 17) Chrome Version 90.0.4430.72 has made the options requests hidden again :(
Chrome 81 does not seem to display anything even after changing the option and restarting on my computer.
As an alternative solution, I started to use Firefox and its Network tab for development.
https://getfirefox.com
I'm Takashi from Chromium Project, and drove the Out-Of-Blink/Render CORS project.
The project intended to introduce a process isolated CORS implementation for better security and privacy, and many of new network related features rely on this new implementation. Unfortunately we temporarily disabled preflight support in DevTools as it turned out continuing to support it weakens security and privacy. Sorry for inconvenience during this period.
Good news is now Chrome 83 implements the CORS preflight DevTools support again in a security preserved way. So you can monitor the CORS preflight requests as you could do before the Out-Of-Blink/Renderer CORS.
Best,
Related
For desktop applications there is a firewall and determines which app can connect to the internet.
Of course internet browsers and other internet apps are always unblocked, other way they are useless.
Now we change point of view from OS->APPS and lets look same way at BROWSER->PLUGINS.
Browser is always online and how I obtain something similar to OS firewall but for the browser plugins? How I know which add-on is actually connecting to its developers server and send some data about my browsing acitvity, add-on usage and so on... ?
Read the code
Unfortunately, AFAIK you have to read the code. For example, the extension
https://github.com/m0rtem/CloudFail/ does call home. You can search for "http" in the code.
Inspect the extension
On Firefox you can inspect an extension.
For example, inspect (aka debug) uBlock. You get the full dev tools on the extension's background page. Go to the "network" tab. Now for testing, go to the extension's options. Update your filter lists. Then go back to extension inspector network tab : you see all the remote calls that the extension made, at your request. But you could also see any hidden call.
content security policy
Sending the user's data to a remote server is not the same thing as writing code with poor security practices, exposing the user to malicious code execution from hackers. But still, it's related.
For Firefox, the default CSP is "script-src 'self'; object-src 'self';" https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy.
So you can read the extension's manifest.json, to see if they changed the default policy.
You can also search for "google analytics" in the code.
Now, be aware that on the official stores, every extension's code base is reviewed by Chrome or Mozilla, so the worst practices (like hacking) are forbidden.
https://wiki.mozilla.org/WebExtensions/policy#II.Security.2F_Privacy
Chrome and other browsers support Windows Authentication via NTLM. From what I can tell though, the Chrome Dev Tools Network tab only ever shows the initial request and final response in the negotiation process. (See diagram below)
Image credit: https://www.zevenet.com/knowledge-base/howtos/load-balancing-of-webapps-with-iis-authentication-ntlm-and-asp-net-impersonation/
Is there a way to make in the tool it show all the detail about what's actually going on? It's very confusing to look at the initial request and not see any Authorization header yet have the server respond with a response indicating the client is now authorized.
Your best bet is WireShark capture.
I ran into such a problem.
When I run the application on my laptop (Linux/Ubuntu 18) in the developer console in the Chrome browser, I have this message
A cookie associated with a cross-site resource at
http://pubsub.rtschannel.com/ was set without the SameSite
attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with SameSite=None and Secure.
You can review cookies in developer tools under
Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
On another laptop (Linux/Ubuntu 16) in the Chrome browser, when the application is launched locally, there is no such message.
I tried to find at least some information on this subject, but alas I couldn’t. The only thing I could find was the link inside the message that it was a browser bug and in Chrome version number 80 it should be fixed and this setting would be added by default.
Please tell me, does it depend on the browser settings, or can I somehow influence this message programmatically? Can I clean it somehow?
On the project, I use angularjs if this can help.
Thanks.
These warnings are purely informational at the moment and do not affect site functionality. This behaviour will not be enforced until Chrome 80 which is due to hit stable in Feb 2020.
You can simply turn off the messages by setting chrome://flags/#cookie-deprecation-messages to Disabled. However, that is purely affecting the display of the messages.
If the pubsub.rtschannel.com is not your domain, e.g. it's a third-party service you use, then it's that domain that will be responsible for updating the cookies.
If it is your domain, then you need to review the cookie usage and set an appropriate value for the SameSite attribute on the cookie. You can find more context and guidance on https://web.dev/samesite-cookies-explained.
I am having a small issue whereby Chrome (Version 60.0.3112.113, Mac OS) is returning a failed status response from a CORS preflight OPTIONS request.
The endpoint it is querying is a nodejs server which previously did not respond correctly to the preflight request. I have since fixed this.
The preflight request works in all other browsers, and works in Chrome on all other computers. I have tested using Browserling, and everything works as expected.
As such I am assuming (with 99% confidence) that this is some sort of caching issue with Chrome on my development computer. I have however been unable to resolve this, and have at this point tried deleting any/all cache options that I can find in the various Chrome options menus.
Can anyone share any insight?
I could not find a way of clearing whatever internal cache Chrome is using in this regard.
My resolution was simply to append a query string (based on the build time) to the request such that Chrome does not use this internal cache.
This is a good way of versioning resources (JS, CSS, API endpoints etc) anyway.
I want my Chrome extension to collect information about how the current browser tab negotiated its secure connection.
In particular, I want to know the protocol and the cypher/auth & key exchange mechanisms used in the HTTPS connection: SSL3? TLS 1.2? And those ugly strings like AES_128_GCM or CHACHA20_POLY1305, ECDHE_RSA or ECDHE_ECDSA.
Is this even possibile?
Within the API index, the best fitting module seems to be chrome.webRequest. But I can't see any means to gather connection data. Am I missing something?
You cannot get any information about the TLS connection via the Chrome extension APIs. A few days ago, a popular feature request on Chromium's issue tracker was marked as WontFix because of the complexity of implementing such a feature in Chrome (Issue 107793: Provide information about the TLS connections to extensions via the webRequest API).
The only way to get the certificate information in Chrome is by clicking on the lock icon, then the Connection tab.