Thanks for filing the issue!

@deepika.ragunathan: Could you please brief us on how to perform step 2 in comment#0 i.e., "performing an AJAX request to another domain which doesn't support CORS". It would be highly helpful if provided with a test file to check it from chrome test team.

@vamshi.kommuri@chromium.org:

Actually we are trying to hit the service without changing any server-side code involving a cross domain AJAX call.

For that we used the flag  --disable-web-security   --user-data-dir upto the version 58.

But in the latest version upgrade of chrome, we are not able to hit other service involving cross domain AJAX call.

I think these statements will be helpful.

Am attaching the sample images of the request and the response which we received.

Deleted: SampleServiceCall.png 22.9 KB

	SampleServiceCall.png 22.9 KB View Download

Deleted: ResultOfServiceCall.png 9.0 KB

	ResultOfServiceCall.png 9.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

toyoshim@: Could this have changed based on the CORS refactorings we're doing? Perhaps we had a flag on the SecurityOrigin that we're no longer checking? I doubt we have tests for this, as it's not a supported flag..

Hum... I might break it, maybe I forgot to take the GrantUniversalAccess flag into account in some new places.

Question just in case, should we really keep supporting --disable-web-security? This is so powerful. It's scary that just flipping one bit in the renderer can kill the security feature (though the one bit can be moved to the browser process).

Anyway, I will check which change makes this difference.

Remove Windows bit since this is not platform specific.

Removing the Needs-Bisect label as this is already being worked by toyoshim@, 
Please feel free to add the label back if bisect is required here.

Thank you!

Bisect will still help.
May I ask you to pick up my CLs in the suspected revision range?

As per comment #4 we need server side code and AJAX environment to reproduce this issue, which isn't presently available with ET Chrome team,  hence adding TE-NeedsTriageHelp for further triaging. Requesting someone from Blink>SecurityFeature team to help in providing Bisect.

Thanks!

Do we get any temporary solution?

No. Actually, I thought if we could remove this flag from Chrome.
But looks some tests use this flag to emulate exploited renderers.

Sorry for slow investigation. I just do not have enough bandwidth now, and didn't put high priority since this is one of only for testing features.

Simple test: https://jsfiddle.net/toyoshim/3n2psq1L/

Hum... I can not run a bisect because old Chrome crashes on the recent gLinux :(

vamshi.kommuri@
If you can run, it would still help me to doublecheck if I missed something others in the change.

Ah, #13 wasn't a right test for this.
It looks only preflight request fails. Simple CORS successfully bypass the check with the flags.

Let me revise the test, and see what causes the issue.

https://jsfiddle.net/toyoshim/9n81mdpu/

This XHR OPTIONS case that requires CORS preflight also seems to work with trunk.

deepika:
It seems this happens only on a special case. Could you provide a simple repro site, or explain more details to reproduce the case?

Also I'm afraid that the reporting user reuse an existing profile (user-data-dir). I can confirm that reusing a normal profile makes the Chrome ignore the --disable-web-security flag, but running the same version Chrome with a brand-new profile makes it work.

Will close this in a week since I can not reproduce the issue.