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.

Eg: Data protected by cookies is safe

Imagine https://example.com/users-private-data, which may expose private data depending on the user's logged in state. This state uses a session cookie. It's safe to add Access-Control-Allow-Origin: * to this resource, as this header only allows access to the response if the request is made without cookies, and cookies are required to get the private data. As a result, no private data is leaked.

Eg: Data protected by location / ip / internal network is not safe (unfortunately common with intranets and home appliances):

Imagine https://intranet.example.com/company-private-data, which exposes private company data, but this can only be accessed if you're on the company's wifi network. It's not safe to add Access-Control-Allow-Origin: * to this resource, as it's protected using something other than standard credentials. Otherwise, a bad script could use you as a tunnel to the intranet.

Rule of thumb

Imagine what a user would see if they accessed the resource in an incognito window. If you're happy with everyone seeing this content (including the source code the browser received), it's safe to add Access-Control-Allow-Origin: *.

This answer was originally written as a reply to What are the security implications of setting Access-Control-Allow-Headers: *, if any? and was merged despite being irrelevant to this question.

To set it to a wildcard *, means to allow all headers apart from safelisted ones, and remove restrictions that keeps them safe.

These are the restrictions for the 4 safelisted headers to be considered safe:

• For Accept-Language and Content-Language: can only have values consisting of 0-9, A-Z, a-z, space or *,-.;=.
• For Accept and Content-Type: can't contain a CORS-unsafe request header byte: 0x00-0x1F (except for 0x09 (HT), which is allowed), "():<>?@[\]{}, and 0x7F (DEL).
• For Content-Type: needs to have a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
• For any header: the value’s length can't be greater than 128.

For simplicity's sake, I'll base my answer on these headers.

Depending on server implementation, simply removing these limitations can be very dangerous (to the user).
For example, this outdated wordpress plugin has a reflected XSS vulnerability where the value of Accept-Language was parsed and rendered on the page as-is, causing script execution on the user's browser should a malicious payload be included in the value.

With the wildcard header Access-Control-Allow-Headers: *, a third party site redirecting to your site could set the value of the header to Accept Language: <script src="https://example.com/malicious-script.js"></script>, given that the wildcard removes the restriction in Point 1 above.

The preflight response would then give the greenlight to this request, and the user will be redirected to your site, triggering an XSS on their browser, which impact can range from an annoying popup to losing control of their account through cookie hijacking.

Thus, I would strongly recommend against setting a wildcard unless it is for an API endpoint where nothing is being rendered on the page.

You can set Access-Control-Allow-Headers: Pragma as an alternative solution to your problem.

Note that the value * only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information), otherwise it will be read as a literal header. Documentation

In scenario where server attempts to disable the CORS completely by setting below headers.

• Access-Control-Allow-Origin: * (tells the browser that server accepts cross site requests from any ORIGIN)

• Access-Control-Allow-Credentials: true (tells the browser that cross site requests can send cookies)

There is a fail safe implemented in browsers that will result in below error

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

So in most scenarios setting ‘Access-Control-Allow-Origin’ to * will not be a problem. However to secure against attacks, the server can maintain a list of allowed origins and whenever server gets a cross origin request, it can validate the ORIGIN header against the list of allowed origins and then echo back the same in Access-Control-Allow-Origin header.

Since ORIGIN header can't be changed by javascript running on the browser, the malicious site will not be able to spoof it.