This is reposted from crbug 1031699 as directed by the guys from Chromium project.
Let me present our use case before the actual request.
At MuleSoft we are working with APIs and data integration. We build software to design, iterate, develop, test, and monitor APs. Because we strongly believe that the place of such tooling is in the web and not in the desktop client, our tooling is build on top of the web platform. This however causes some inconvenience for our users when it comes to API testing (both during the development, structured tests, and monitoring). Because our clients are banks, govs, medical companies, and huge enterprises the majority of APIs we are working with have limitations put on the web client.
I don't really have data that tells why CORS headers are not send with the response. I can only guess that it would require this companies to run a process of altering the backend which in many causes is a legacy system which triggers the whole development process just to add headers to the response. I don't think it is a security issue since you can make a request from other clients (CLI, desktop app) with success. Also, APIs usually require the presence of the authorization header with some kind of token (OAuth, JWT) and are not session based. At least this is what we are telling to our clients :)
The use case is that our tools, like API designer, or API testing tools need to come with additional server components that proxy the request from the web client to the server. It is quite OK if we are dealing with publicly accessible APIs. However, there are APIs that are not public and are only accessible from the internal network. In this case, for our customer to work with our tooling, they need to install additional software in local network (a proxy) to achieve similar result.
Another problem I see with the current state is that we have inconsistency and discrimination of web clients. I understand the security concerns about resource sharing and I am aware of what an evil script can do if it has access to a remote resource that is protected by session only. However, if you install an extension in a browser, or an application on your smartphone, it asks you for a permission to access internet or a specific address. A web application has no such option to ask a user to grant access to connect to a remote resource, even when CORS is not supported.
So the ask here is to consider altering the specification for CORS to enable web application to ask for a permission from the user to access remote resource even when API does not support CORS headers.
Things to consider:
Allowing web application to define a permission to access specific domain with possible wildcards on the path, and on a subdomain
Once the permission is granted the web application can request a remote resource without CORS checkup before the actual request
A new CORS related header is added to the spec that allow to disable requests from web clients whether the user grant the permission or not
When a permission is granted to a domain, no session related headers can be transmitted to matched domain to ensure that session based APIs won't be affected by this change. This would only work with APIs that require some kind of token to authenticate the user.
This would not change the behavior of how current APIs work from the developer perspective. The developer would have to use the Permissions API to check whether the user already granted the access to the application or not and ask for the permission if necessary.
I've prepared a deck explaining the issue. It is in the attachment. Our IT disallow sharing Google Slides so I can't provide a link.
I'll be happy to discuss the issue hoping that we can came up with a solution.
This is reposted from crbug 1031699 as directed by the guys from Chromium project.
Let me present our use case before the actual request.
At MuleSoft we are working with APIs and data integration. We build software to design, iterate, develop, test, and monitor APs. Because we strongly believe that the place of such tooling is in the web and not in the desktop client, our tooling is build on top of the web platform. This however causes some inconvenience for our users when it comes to API testing (both during the development, structured tests, and monitoring). Because our clients are banks, govs, medical companies, and huge enterprises the majority of APIs we are working with have limitations put on the web client. I don't really have data that tells why CORS headers are not send with the response. I can only guess that it would require this companies to run a process of altering the backend which in many causes is a legacy system which triggers the whole development process just to add headers to the response. I don't think it is a security issue since you can make a request from other clients (CLI, desktop app) with success. Also, APIs usually require the presence of the authorization header with some kind of token (OAuth, JWT) and are not session based. At least this is what we are telling to our clients :)
The use case is that our tools, like API designer, or API testing tools need to come with additional server components that proxy the request from the web client to the server. It is quite OK if we are dealing with publicly accessible APIs. However, there are APIs that are not public and are only accessible from the internal network. In this case, for our customer to work with our tooling, they need to install additional software in local network (a proxy) to achieve similar result.
Another problem I see with the current state is that we have inconsistency and discrimination of web clients. I understand the security concerns about resource sharing and I am aware of what an evil script can do if it has access to a remote resource that is protected by session only. However, if you install an extension in a browser, or an application on your smartphone, it asks you for a permission to access internet or a specific address. A web application has no such option to ask a user to grant access to connect to a remote resource, even when CORS is not supported.
So the ask here is to consider altering the specification for CORS to enable web application to ask for a permission from the user to access remote resource even when API does not support CORS headers.
Things to consider:
This would not change the behavior of how current APIs work from the developer perspective. The developer would have to use the Permissions API to check whether the user already granted the access to the application or not and ask for the permission if necessary.
I've prepared a deck explaining the issue. It is in the attachment. Our IT disallow sharing Google Slides so I can't provide a link.
I'll be happy to discuss the issue hoping that we can came up with a solution.
Anypoint platform and CORS (1) (1).pdf