Question about CORS and browser security


This is more of a generic hybrid app approach question, i don’t think it’s specific to Ionic but does apply to Ionic. How is the native webview browser security set up? Can i just use angular HTTP or resource services as tells me i can?
What if i try to test my app using IOS safari, will i then run into CORS issues? (yeah i know, better test on real device, but lacking apple developer account at the moment, and, for quick tests i think it will be usefull).
Is there a difference between IOS and Android?

Thanks for replying and i hope i haven’t overlooked documentation or another thread about this,


1 Like

I’ve build android app using backend service, and i’m enable CORS in my server for that :smile:
And i use normal $http.get or post … its depend on your data :slight_smile:

Thank you for your reply ghprod, but i mean the situation where you use third party services and API’s where you are not in control of enabling CORS. Even more specific, where CORS is disabled for instance.
Is it then possible to use a default Angular HTTP / Resource service?

So in other words, is your Ionic app seen as a native app, from which a third party REST request is not actually CORS, or as a browser, where it IS?

If you dont have control to that resource/server about cors, then the best deal you need to create some proxy bridge, example with curl php before send to your device …
I’m sorry if my answer does not satisfy you, because i never test from my android to make request to another server which has cors disable :slight_smile:

Hi @michahell,

See the following for CORS and web browsers:

Apache Cordova / Ionic apps don’t suffer from CORS issues so testing from a device or simulator should work fine.


1 Like

To test in a browser you can define on the gulpfile.js on the serve section, something like:

  root: 'www',
  hostname: '',
  port: 8000,
  livereload: true,
  middleware: function(connect, o) {
    return [(function() {
        var url = require('url'),
            proxy = require('proxy-middleware');
        var options = url.parse('http://your-server/api');
        options.route = '/api';
        return proxy(options);
1 Like

Thank you @nicraboy and @jbolila, I think I will probably have no problems with CORS given your replies :smile:

Cors can be a pain.

For me I want to test all apps in browser as fixing css goes way faster with good inspections tools.

I have read up on CORS here
But as stated previously it has also only been a case where I have control of the backend.

And i never had problem with the real app just when developing.

For example with Drupal CMS we use this module:

Or directly in the .htaccess file of any apache site.

It is also possible to start Chrome in disabled security mode for testing.
terminal: chromium-browser --disable-web-security

Remember to not have chrome open when running that command :smile:

1 Like

From my understanding with CORS, all the server does with this enabled is send back a header acknowledging and accepting the fact that you will be making a cross-origin request via POST, PUT, or whatever kind of call they are accepting.

If the host has an API without CORS enabled, they will probably accept a GET with some data and return to you whatever you need. Check their API docs to figure out how to setup a proper request for that particular host.

I’ve had a few days of CORS headaches behind me.

Basically what I ended up with is disabling security on Chrome (just for testing the app) which allowed me make credentialed API requests without matching origin headers, if that makes sense. It allows me to test in the browser now.

Beyond that, you can do emulation for testing, as on the actual device you don’t get this problem. Can also use the phonegap developer app for this, it works, too. But phonegap build still gave me problems (it’s really flaky). The phonegap developer app is pretty neat as it pushes all console logging back to the terminal, and it’s really easy and quick to set up and run as opposed to say emulation. However you do of course need a device to test on, but the upside is you don’t need to be a registered dev to use it.

Oh btw can I get confirmation about CORS not being useful or making much sense in a mobile app? Perhaps I’m missing something.

Yeah, CORS is all server-side. The only thing I’d suggest is checking out your config.xml and make sure you have:

<access origin="*" />

This is what one of my ajax calls looks like:

	type: "POST",
	url: "http://hostip:port/login",
	crossDomain: true,
	async: true,
	cache: false,
	data: {
    		email: $,
        	password: $scope.accountData.password
		dataType: "json",
		timeout: 5000
.done(function(data, textStatus, jqXHR) {
	var json = data;
	if(json[0].sessionId) {
		localStorage.setItem('email', $;
		localStorage.setItem('sessionId', json[0].sessionId);
		localStorage.setItem('isLoggedIn', true);
	else {
		alert('Fail: ' + json[0].message);
.fail(function(jqXHR, textStatus, errorThrown) {
	alert('Error logging in: ' + errorThrown);
.always(function(data, textStatus, errorThrown) {

Note that it still works for me without specifying crossDomain: true. I believe that that property just forces it to always think it’s a cross domain call.

Thinknovely, i appreciate your contribution, but the problem was not that i did not understand CORS or that i was looking for how to configure it. I wanted to know how an Ionic app behaves, either as a browser or as an application. If it would behave as a browser, then CORS problems would occur IF one is not in control of certain REST / web services one is using. IF one is in control of their own webservices, CORS is never a problem, since you can configure your own service to allow CORS requests, as you just posted.

I wanted to know this since i am porting a web app that uses third-party webservices that a) i do NOT control, and b) do not have CORS enabled.

That would have caused headaches (you’d need to build a proxy system just to circumvent CORS denial) if Ionic apps were seen as browsers and not secure applications.

But i expect this will not be a problem given the replies of several others, gratitude!