What is the best way to deal with the CORS requests and their associated httpOnly session cookies in cordova?

[ghevge]

Can anyone please tell me what is the best way to deal with the CORS requests and their associated httpOnly session cookies in Cordova?

I'm not finding anything clear googling around, I can only find workarounds and some references to some plugins which seem to partially works in specific configurations.

In my opinion, the best way to deal with these problems would be an embedded Cordova http reverse proxy, but I'm not able to find anything related to such a component, within Cordova. In google, I've found 2 plugins that partially seem to do that, but the android one (cordova-plugin-http-proxy) seems to be dead for a while and from what I can tell looking at the code, only handles Post and Get, while the second one (cordova-plugin-webview-proxy) is only for IOS.

Please advice.

Thanks

[breautek]

Can you provide an example of how you're setting the cookie (in the raw HTTP form). This should be discoverable if you can hit your API using a non-browser based HTTP client (e.g. Postman, NodeJS, etc...) and inspecting the HTTP response header. At a basic level, it should contain something like:

Set-Cookie: yummy_cookie=choco

I'm not as sure with iOS but Chrome has changed the default behaviour around how cookies are sent/received in regards to cross origin request.

The cooke has a SameSite option which used to default to None, which would allow cookies to be sent for all requests regardless of origin. Now the default is Lax, which from MDN:

Means that the cookie is not sent on cross-site requests, such as on requests to load images or frames, but is sent when a user is navigating to the origin site from an external site (for example, when following a link). This is the default behavior if the SameSite attribute is not specified.

I believe if you want cookies to be sent to cross-origin domains (which will always be the case for Cordova/Hybrid WebView apps) the server must configure the cookie with 2 options:

1. SameSite=None;
2. Secure;

The Secure option used to be optional when SameSite defaulted to None, but with the change of changing the default to Lax, the browser also added Secure; requirement on SameSite=None;. This means that cookies will only be sent if a valid HTTPS connection can be established.

So a full example would look like:

Set-Cookie: yummy_cookie=choco; SameSite=None; Secure;

I don't use cookies in my day-to-day work, so all of this information is just gathered from helping others with similar problems or aggregating documentation. I've never actually used any of this in practice.

[breautek]

The best way to deal with these problems would be an embedded Cordova http reverse proxy,

Running a webserver (even a local webserver) to serve as a reverse proxy is not recommended at all. I've done this kind of hack before for a different reason.

The issues that come from running a local webserver on the device is that:

1. If you select a port to bind in which is already taken (by say another app implementing a similar practice on the device) the webserver will fail.
2. If you decide to be dynamic and allow to accept a random available port, then you're origin is constantly changing, which is also where cookies and other web storage data is stored (different origins have different storage containers).
3. Without precautions, any app running on the device can hit your local webserver which may expose private information to other apps unintentionally.

Just something to keep in mind.

[ghevge]

Thanks for the response!

My cookies are set with secure: httpOnly flag. I will try setting the flags you recommended, but that will have potential security impacts, especially on my web app , which will use the same APIs as the mobile apps will. That is way I still believe a reverse proxy is better for this scenario.

these are my cookies:

HTTP/1.1 200 OK

set-cookie: _pks=U9X2+zck2patpQL+2Ba9w3sq3JPoT2PYbc/qe73OE37L++jxqF/ImX7OixGEHmI1Bn+jBea5mOhQz4gZs9joj37gLoQgjV/iLa3fl2eLdr+2d; Max-Age=604800; Expires=Sun, 21 May 2023 15:06:24 GMT; Path=/; Secure; HttpOnly

content-type: application/json

date: Sun, 14 May 2023 15:06:24 GMT

x-envoy-upstream-service-time: 37

access-control-allow-origin: http://localhost

server: envoy

transfer-encoding: chunked

You are saying that a proxy can be potentially called by other apps, but then how the static resources are served and secured at the cordova level? as they should be served by some kind of web server too. What if a dedicated context path (lets say localhost/proxy/....) will be allocated at this resource web server level, to proxy the requests to the user configured http servers ? This configuration to be done by the users, potentially in the config.xml.
eg:

.......

An embedded reverse proxy will remove all the problems with CORS in Cordova, for which there are more questions than actual answers.

[breautek]

You are saying that a proxy can be potentially called by other apps, but then how the static resources are served and secured at the cordova level? as they should be served by some kind of web server too.

No, they appear as if they are but they don't operate with a webserver. Modern Cordova apps uses something called WebViewAssetLoader for Android, and iOS has a similar working feature called WKURLSchemeHandler. They both work differently but kinda achieve a similar end result.

Cordova apps do not host a web server and there is nothing binding to any network interface, not even the localhost/loopback address. So the only thing that has access to this "fake server" is the webview instance itself.

On Android, the https://localhost comes from the WebViewAssetLoader, which is a webview feature that allows us to bind a particular origin to be used. The webview itself intercepts all connections on the configured origin so that it doesn't even reach the network stack and redirects to the filesystem. This is Google's answer to give webview-powered apps access to browser features that are normally restricted to HTTPS only connections, as it tricks the webview that the origin is communicating with a secure server. I'm not 100% sure on the capabilities of the WebViewAssetLoader... implementing one generally involves implementing a PathHandler that handles a string path and returns a WebResourceResponse. The Cordova framework does this to interface with the local filesystem, however it looks like a cordova plugin might be able to extend this to add additional path handlers and I don't see why someone couldn't make a HTTP request, or add additional response headers. It might still be able to serve as a proxy. The cordova framework itself however just proxies into the local filesystem.

For iOS, the equivalent system is WKURLSchemeHandler. I'm not well knowledgeable on iOS, but I'm not seeing how one can set specific headers... so it's capabilities might not be as flexible as Android.

[ghevge]

I'm not familiar with iOS development, but this plugin seems to be able to handle the headers.
My only problem is that it only does it for iOS. https://github.com/GEDYSIntraWare/cordova-plugin-webview-proxy/blob/master/src/ios/WebviewProxy.m.

As for the android side, as long as we can intercept the WebViewer requests and as long as there are other restrictions from Android side to call remote http servers, even if we won't return the cookies to the UI, we still should be able to manage them and append them on requests, were required , at the java app level.

[ghevge]

@breautek I've set the cookie flags on the server side, the way you mentioned but the Cordova app still doesn't work. Plus the web app stopped working too, because of these changes :)

This is how the server returned cookie looks like after the changes.

set-cookie: _pks=er9AvJc6bwpr49FVI+BVTMORZSVPjrgogJXZRducI8DlPHuZixGkv2zpQBRo2X/cwpmxWib0PX/LMcwtETlO9vo3IFIyb4ZsiQSlsIJuvi1YR; Max-Age=604800; Expires=Sun, 21 May 2023 16:20:03 GMT; Secure; SameSite=None

On the subsequent requests, this cookie is not being passed, from what I can see in the chrome network tab.

[breautek]

That's unfortunate, I'm not sure what else can be tried.

But I explained a bit of how Cordova works using the schemes and the "fake server" powered by the WebViewAssetLoader above. Maybe a proxy-like system can still be implemented without actually introducing a real webserver on the device.