Interview Bank
  • Interview Bank
  • Web
    • Persistent Connection and Non Persistent
    • CDN
    • Code Review
    • JWT
      • JWT vs Session Based Authentication
      • JWT Challenge
      • JWE
      • JWS
    • Content Security Policy (CSP)
    • Same-origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
      • Exploiting CORS
    • HTTP Strict Transport Security (HSTS)
    • SQL Injection (SQLi)
    • Password Encryption in Login APIs
    • API Security
      • API Principles
    • Simple bypass PHP
    • Server-side Template Injection (SSTI)
    • Javascript Object and Inheritance
    • HTTP/2
    • Cookie vs Local vs session Storage
    • XML External Entity (XXE)
    • What happened when enter domain name in browser
    • Prototype Pollution - Part 1
    • Prototype Pollution - Part 2
    • Nginx vs Apache
  • OT Security
    • Securing Operational Technology: Understanding OT Security
  • Quantum Computing
    • Quantum Computing: Unveiling the Cryptographic Paradigm Shift
    • Quantum Obfuscation: Shielding Code in the Quantum Era
  • DevSecOps
    • Continuous Integration/Continuous Deployment Pipeline Security
    • Chaos Engineering Overview
      • Security Chaos Engineering
    • Mysql VS redis
    • Kubernetes (k8s)
    • How MySQL executes query
    • REDIS
    • Difference between cache and buffer
  • Windows
    • Pentesting Active Directory - Active Directory 101
    • Pentesting Active Directory - Kerberos (Part 1)
    • Pentesting Active Directory - Kerberos (Part 2)
    • AD vs Kerberos vs LDAP
    • Active Directory Certificate Services Part 1
    • Unconstrained Delegation
    • AS-REP Roasting
    • NTLM Relay via SMB
    • LLMRN
    • Windows lateral movement
    • Constrained Delegation
    • Resource-Based Constrained Delegation
    • IFEO (lmage File Execution Options) Hijacking
  • UNIX
    • Setuid
  • Large Language Models (LLMs)
    • Tokens
    • LangChain
    • Integration and Security
  • Android
    • Keystore
  • Red team development
    • Secure C2 Infrastructure
    • P Invoke in c#
    • D Invoke
    • ExitProcess vs ExitThread
  • Blue Team
    • Indicators of Compromise
    • Methods to prevent Email domain spoofing
    • Windows Prefetching
  • CVE
    • XZ Outbreak CVE-2024-3094
    • Log4J Vulnerability (CVE-2021-44228)
    • SolarWinds Hack (CVE-2020-10148)
    • PHP CGI RCE (CVE-2024-4577)
    • Windows Recall
  • Software Architecture
    • Microservices
    • KVM
  • Docker
    • Overview
    • Daemon Socket
    • Tips to reduce docker size
  • Blockchain
    • Overview
    • Smart Contract
  • Business Acumen
    • Market Research Reports and Perception
    • Understanding Acquisitions
    • Cybersecurity as a Business Strategy
  • Cyber Teams
    • Introduction to Purple Teaming
  • Malware
    • Dynamic Sandbox Limitations
Powered by GitBook
On this page
  • What is CORS
  • Access-Control-Allow-Origin Header
  • Implementing simple cross-origin resource sharing
  • Handling cross-origin resource requests with credentials
  • Pre-flight Request
  • Pre-flight request
  • Response from server
  • Actual Request
  • Actual Response
  • Thinking question
  • Interview Question
  • Author
  • Reference
  1. Web

Cross-Origin Resource Sharing (CORS)

PreviousSame-origin Policy (SOP)NextExploiting CORS

Last updated 1 year ago

What is CORS

Cross-origin resource sharing (CORS) is browser mechanism which enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin Policy (SOP).

However, it also provides potential for cross-domain attacks, if a websites CORS is poorly configured, it does not protect against CSRF

Access-Control-Allow-Origin Header

Access-Control-Allow-Origin Header is the included in the response form one website to a request originating from another website, and ifentifies the permitted origin of the request.

A web browser compares the Access-Control-Allow-Origin with the requesting website's origin and permites access to the response if they match

Implementing simple cross-origin resource sharing

The protocol headers Access-Control-Allow-Origin is returned by a server when a website requests a cross-domain resources, with an origin header added by the browser.

E.g.

For example, suppose a website with origin normal-website.com causes the following cross-domain request:

GET /data HTTP/1.1
Host: robust-website.com
Origin : https://normal-website.com

The server on robust-website.com returns the following response:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://normal-website.com

The browser will allow code running on normal-website.com to access the response because the origins match.

Handling cross-origin resource requests with credentials

The default behavior of cross-origin resource requests is for requests to be passed without credentials like cookies and the Authorization header. However, the cross-domain server can permit reading of the response when credentials are passed to it by setting the CORS Access-Control-Allow-Credentials header to true. Now if the requesting website uses JavaScript to declare that it is sending cookies with the request:

GET /data HTTP/1.1
Host: robust-website.com
...
Origin: https://normal-website.com
Cookie: JSESSIONID=<value>

And the response to the request is:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://normal-website.com
Access-Control-Allow-Credentials: true

Then the browser will permit the requesting website to read the response, because the Access-Control-Allow-Credentials response header is set to true. Otherwise, the browser will not allow access to the response.

Pre-flight Request

E.g.

Pre-flight request

OPTIONS /api/data HTTP/1.1
Host: example.com
Origin: http://example.org
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

One small question, what is the Access-Control-Request-Method: POST means?

Response from server

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example.org
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

In this example, the browser first sends an OPTIONS request to the server BEFORE sending the actual request, to obtain authorization information for the actual request. Upon receiving the preflight request, the server checks the information in the request and confirms that it allows cross-origin requests. Therefore, the preflight response includes CORS headers such as Access-Control-Allow-Origin and Access-Control-Allow-Methods

Actual Request

POST /api/data HTTP/1.1
Host: example.com
Origin: http://example.org
Content-Type: application/json
Authorization: Bearer token

From the previous question, the Access-Control-Request-Method: POST means in actual CORS request, we are checking if POST methods is allowed.

Actual Response

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example.org
Content-Type: application/json

{"message": "Data saved successfully"}

Thinking question

What if Pre-flight request failed, the server respond other than 200 status code. What will happen to browser? Will the actual Request still being sent?

The answer is no, The purpose of pre-flight request (Option) is to check the server whether the actual request is allowed to sent with the specified methods, headers and origin. If the server respond other than 200. The browser WILL NOT proceed with sending the actual request. It will generate an error indicating that the CORS policy of the server does not allow the request

Interview Question

  1. What is CORS and why is it important for web security?

  2. What is the purpose of a preflight request in CORS? When is it triggered?

  3. What is the Access-Control-Request-Method in preflight request for?

  4. Will CORS protect CSRF? Why or Why not? (Research yourself)

  5. What is the difference between SOP, CORS and CSP? (Recap from previous interview question)

Author

Reference

Unlike , for "preflighted" requests the browser first sends an HTTP request using the method to the resource on the other origin, in order to determine if the actual request is safe to send. Such cross-origin requests are preflighted since they may have implications for user data.

simple requests
OPTIONS
Ikonw
https://portswigger.net/web-security/cors
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS