For my PHP-based "API Server," I encountered a problem and found a solution that worked well:

To resolve the issue, I added the following lines to the index.php file:

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS');
header('Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token');

The issue in ASP.NET Core Web API was resolved by incorporating the "Microsoft.AspNetCore.Cors" (ver 1.1.1) package and making modifications to the Startup.cs file as shown below:

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("AllowAllHeaders",
            builder =>
            {
                builder.AllowAnyOrigin()
                       .AllowAnyHeader()
                       .AllowAnyMethod();
            });
    });
    .
    .
    .
}

Furthermore, in the same file:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    // Includes UseCors with a specified policy.
    app.UseCors("AllowAllHeaders");
    .
    .
    .
}

Additionally, it requires adding

[EnableCors("AllowAllHeaders")]

attribute in the controller.

When dealing with CORS, there are a few things to keep in mind. For instance, wildcards like * are not allowed, although I'm not entirely certain about this rule as I read it somewhere but can't locate the source now.

If you are sending requests from a different domain, make sure to include the allow origin headers.

Access-Control-Allow-Origin: www.other.com

For requests that impact server resources such as POST/PUT/PATCH and involve MIME types other than

application/x-www-form-urlencoded

, multipart/form-data, or text/plain, the browser will initiate a pre-flight OPTIONS request to confirm with the server if it's permissible.

Keep in mind that your API/server needs to handle these OPTIONS requests properly by responding with the necessary access control headers and ensuring the HTTP response status code is 200.

The specified headers should resemble something like this, tweak them to suit your requirements:

   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

The max-age header plays a crucial role; in my case, the setup didn't function without it, potentially indicating that the browser relies on this information for determining the duration of "access rights."

In scenarios where you're initiating a POST request with application/json mime from another domain, remember to append the aforementioned allow origin header, resulting in a configuration like this:

   Access-Control-Allow-Origin: www.other.com
   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

After successfully completing the pre-flight process and obtaining all relevant data, your actual request can proceed as intended.

Remember, the Access-Control headers requested during the initial or pre-flight request must be included in the response for the system to operate smoothly.

You can refer to an informative example in the MDN documentation provided here, and also explore this post on Stack Overflow for further insights.

If you are developing a Chrome extension

When configuring the manifest.json file, ensure that you include permissions for your specific domain(s).

"permissions": [
   "http://example.com/*",
   "https://example.com/*",
   "http://www.example.com/*",
   "https://www.example.com/*"
]

When it comes to making HTTP requests in JavaScript, both the XMLHttpRequest and Fetch methods abide by the same-origin policy. This means that a web application utilizing either XMLHttpRequest or Fetch can only send HTTP requests to its own domain.

For more information, check out the source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

To allow cross-origin resource sharing, you need to include the Access-Control-Allow-Origin: * HTTP header from your server side.

If you are using Apache as your HTTP server, you can add this header to your Apache configuration file like so:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

Although Mod_headers is typically enabled by default in Apache, you may want to double-check by running:

a2enmod headers

If you're working with PHP, adding headers is as simple as:

<?php
    header("Access-Control-Allow-Origin: *");
    header("Access-Control-Expose-Headers: Content-Length, X-JSON");
    header("Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS");
    header("Access-Control-Allow-Headers: *");
    ...

If you're experiencing cross-origin request problems in your Node.js application, you can resolve them by following these steps:

npm install cors

Then, insert the following lines into your app.js file:

const cors = require('cors')
app.use(cors())

In the event that you happen to be utilizing the IIS server, you have the option to configure the following headers in the HTTP request headers section.

Access-Control-Allow-Origin:*
Access-Control-Allow-Methods: 'HEAD, GET, POST, PUT, PATCH, DELETE'
Access-Control-Allow-Headers: 'Origin, Content-Type, X-Auth-Token';

By implementing these headers, all POST, GET, etc., requests will function properly.

In my Apache VirtualHost configuration file, I have included the following directives:

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

To set up a Python server with Flask, consider integrating the flask-cors extension for handling cross-domain requests.

Take a look at: Flask-CORS

Our team has encountered this issue when using the powerful combination of Vue.js, Axios, and a C# Web API. We found that adding a route attribute to the endpoint being accessed resolved the problem for us.

[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }

If you are utilizing API Gateway's HTTP API with the proxy route ANY /{proxy+}, it is essential to explicitly specify your route methods for CORS functionality to function properly.

https://i.sstatic.net/hwmy3.png

It would have been beneficial if the AWS documentation on configuring CORS for an HTTP API had made this requirement clearer.

During a lengthy discussion with AWS support, their senior HTTP API developer suggested this approach after investigating the issue.

When utilizing Lambda Integrated Proxy with API Gateway, it is important to properly configure your lambda function so that the response headers are set up correctly, just as if you were sending requests directly to the function. (If custom lambda functions are being used, this task will be managed by the API Gateway.)

// Make sure to include the following code in your lambda's index.handler():
exports.handler = (event, context, callback) => {
    // For successful execution:
    callback(null, {
        statusCode: 200,
        headers: {
            "Access-Control-Allow-Origin" : "*"
        }
    }
}

Cross-Origin Resource Sharing (CORS) is a mechanism based on HTTP headers that enables a server to specify origins (such as domain, scheme, or port) other than its own, from which a web browser should allow the loading of resources.

Source: Cross-Origin Resource Sharing (CORS)

In essence, the server informs you (the browser) about which sites are trustworthy for accessing content on that particular site.

1. Scammysite.bad attempts to instruct your browser to send a request to good-api-site.good
2. good-api-site.good directs your browser to only trust other-good-site.good
3. Your browser correctly flags the request from scammysite.bad to good-api-site.good as untrustworthy and acknowledges that CORS has protected you.

If you are developing a website and don't mind who integrates with it, go ahead and proceed by setting * in your ACL.

However, if you are developing a site and want to restrict access to only site X, or even sites X, Y, and Z, then you utilize CORS to advise the client's browser to authorize these specific sites for integration with your site.

Browsers may opt to disregard this directive. Once again, CORS safeguards your client - not you.

CORS permits either * or one designated site. While this can be restrictive, you can employ dynamic configuration in your web server to bypass this limitation - and facilitate more precise control.

For instance, here is an example of configuring CORS per site in Apache:

# Store the entire "Origin" header in the Apache environment variable "AccessControlAllowOrigin"
# Adjust the regex pattern to match your desired "trusted" sites
SetEnvIfNoCase Origin "^https://(other-good-site\.good|one-more-good.site)$" AccessControlAllowOrigin=$0
# If you manage multiple sites, ensure this rule applies exclusively to the specified site
<If "%{HTTP_HOST} == 'good-api-site.com'">
    # Remove existing headers to replace them explicitly
    Header        unset Access-Control-Allow-Origin   env=AccessControlAllowOrigin
    Header        unset Access-Control-Allow-Methods  env=AccessControlAllowOrigin
    Header        unset Access-Control-Allow-Headers  env=AccessControlAllowOrigin
    Header        unset Access-Control-Expose-Headers env=AccessControlAllowOrigin
    # Add the headers "always" to guarantee they are explicitly set
    # The value of the "Access-Control-Allow-Origin" header will correspond to the stored data in the "AccessControlAllowOrigin" environment variable
    Header always set Access-Control-Allow-Origin   %{AccessControlAllowOrigin}e     env=AccessControlAllowOrigin
    # Customize the following settings according to your requirements
    Header always set Access-Control-Allow-Methods  "POST, GET, OPTIONS, PUT"        env=AccessControlAllowOrigin
    Header always set Access-Control-Allow-Headers  "X-Requested-With,Authorization" env=AccessControlAllowOrigin
    Header always set Access-Control-Expose-Headers "X-Requested-With,Authorization" env=AccessControlAllowOrigin
</If>

In my opinion, disabling CORS in Chrome may not be the best solution. This is particularly true when working with Ionic for mobile builds as the issue could resurface.

It's advisable to address this at the backend level instead.

To begin with, ensure that you set the following headers-

• header('Access-Control-Allow-Origin: *');
• header('Header set Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept"');

If your API supports both GET and POST requests, make sure to include the following in your header as well-

if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') { if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD'])) header("Access-Control-Allow-Methods: GET, POST, OPTIONS"); if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) header("Access-Control-Allow-Headers: {$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); exit(0); }

An issue that frequently leads to this error is when the host API has associated the request with a specific HTTP method (such as PUT), but the API client is invoking the API using a different HTTP method (like POST or GET).

https://i.sstatic.net/AO86o.png

After configuring the CORS settings in the API gateway, I made sure to follow the steps outlined above.

It's important to remember that your function needs to return an HTTP status 200 when receiving an OPTIONS request, otherwise CORS will not work correctly.

After extensive research on AWS SDK for uploads, I stumbled upon a solution to my issue thanks to @lsimoneau and this insightful question 45581857.

By simply specifying the region option in my request URL pointing to the region of my bucket, I was able to resolve the problem and successfully upload.

 const s3 = new AWS.S3({
 accessKeyId: config.awsAccessKeyID,
 secretAccessKey: config.awsSecretAccessKey,
 region: 'eu-west-2'  // specify region here });

One time, I encountered a similar issue related to the DNS server being set to 8.8.8.8 (Google's). As it turns out, the problem lied within the router settings. In my case, the application was attempting to connect to the server through Google instead of locally.

By removing 8.8.8.8, I was able to resolve the problem at hand. While I am aware that CORS settings can also address this issue, I wanted to share my experience in case others face the same challenge.

Verify that the request is directed to the appropriate endpoint. In a recent project using Node.js, there was an oversight in specifying the correct endpoint. The request was targeting /api/txn/12345 when it should have been directed to /api/txn/:txnId. This mistake ultimately resulted in an error.

For those individuals who, like myself, find themselves navigating the world of Django and Nginx alongside Swagger UI, grappling with configuring an endpoint for Docker and local https— it is vital to ensure that your Swagger configuration includes: 'https://<local-domain.local>'

Solving this issue is a simple task that can be accomplished with just a few easy steps, eliminating any worries.

Follow these steps carefully to resolve the problem:

1. Begin by accessing (https://www.npmjs.com/package/cors#enabling-cors-pre-flight)
2. Proceed to the installation section and copy the command npm install cors for installation using Node.js in your terminal
3. Scroll down to the Simple Usage (Enable All CORS Requests) section. Copy and paste the complete declaration into your project, then run it. This method is guaranteed to work. Copy the comment code and insert it into your app.js file or any other suitable location within your project. Give it a try, as it will enable cross-origin resource sharing and allow you to switch between servers seamlessly for your needs.

When using the stand-alone distributions of GeoServer, you will find that it comes equipped with the Jetty application server. To allow JavaScript applications from external domains to access GeoServer, make sure to enable cross-origin resource sharing (CORS).

To activate CORS, simply uncomment the following lines in webapps/geoserver/WEB-INF/web.xml:

<web-app>
  <filter>
      <filter-name>cross-origin</filter-name>
      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
</web-app>

The issue of the preflight request not passing the access control check is a crucial one:

Prior to sending the actual GET request, the browser verifies if the service is configured properly for CORS. This involves checking if the service allows the methods and headers that will be used in the request. Simply permitting access from a different origin is not sufficient; other requirements must also be met.

Just setting headers like

Header always set Access-Control-Allow-Origin: www.example.com 
Header always set Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS 
Header always set Access-Control-Allow-Headers: Content-Type #etc...

is not enough. You need to include a rewrite rule:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

A helpful resource to explore further is Response for preflight does not have HTTP ok status.

I successfully implemented a solution by including the OPTIONS method in the Access-Control-Allow-Methods header:

Access-Control-Allow-Methods: GET, OPTIONS

However, to my disappointment, this approach only works in Chrome and Firefox, not in Chromium.