Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Providing Access-Control-Allow-Origin with a Wildcard

I am making a page that responds to an AJAX request with a certain string when another certain string is provided as a GET variable. In order to avoid problems with the "same origin" policy, I have found that I can include this line of PHP at the top of the page:

header('Access-Control-Allow-Origin: *');

There's no sensitive data being passed whatsoever, it's actually keywords passed back and forth from several different domains, (its an SEO related application). Due to this, hundreds of different domains will be using it, so if possible I would like to avoid specifying each one. Are there any risks to using this line? If so, what are they?

Also, if this page was located under an HTTPS URL is it still accessible?

Any advice, suggestions or concerns are most welcome. Thank you!

like image 249
Doug Molineux Avatar asked May 26 '11 17:05

Doug Molineux


People also ask

Can Access-Control allow origin have wildcard?

For requests without credentials, the literal value " * " can be specified as a wildcard; the value tells browsers to allow requesting code from any origin to access the resource. Attempting to use the wildcard with credentials results in an error. Specifies an origin. Only a single origin can be specified.

What is * in Access-Control allow origin means?

Access-Control-Allow-Origin specifies either a single origin which tells browsers to allow that origin to access the resource; or else — for requests without credentials — the " * " wildcard tells browsers to allow any origin to access the resource.

What is CORS wildcard?

Access-Control-Allow-Origin header with wildcard (*) value Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the resource originated.

Is Access-Control allow Origin * Safe?

Access-Control-Allow-Origin: * is totally safe to add to any resource, unless that resource contains private data protected by something other than standard credentials. Standard credentials are cookies, HTTP basic auth, and TLS client certificates.


1 Answers

If the access truly is public, I'd say this is a good solution. However, if you want to limit the access to your site, you'll probably want to list explicitly each domain origin allowed.

Since you say your response doesn't include any sensitive information, you probably don't need to worry about hosting your service over HTTPS. The one reason you might is if a client HTTPS page tries to access your non-HTTPS service. In that case, I would guess they'd get a warning about unsecure information being sent/received when your AJAX service is called, and maybe even just a silent fail. If this is a common enough case, then I'd say looking into the HTTPS service. Make sure your HTTPS certificate is certified properly, because if the client's browser cannot verify the certificate the AJAX request will silently fail (as opposed to prompting when you navigate directly to an HTTPS page)! Also, I don't know how it will go in your case, but whenever I've worked with HTTPS, I've usually had to tweak things to get them to function properly.

Long story short, I'd start with HTTP and then evaluate the need of HTTPS. Good luck!

like image 114
Briguy37 Avatar answered Oct 03 '22 06:10

Briguy37