Have you heard of the Same-Origin Policy and Cross-Origin Resources Sharing?
❓ What is the Same-Origin Policy?
Same-origin policy (SOP) is a rule that is enforced by browsers to control access between web applications.
Example,
You are visiting a 🏦banking application and a 🛒 shopping application, the interaction between these two applications is limited by default by all browsers. (You may not realize)
Even though the bank application is able to make requests to the shopping application, for example submitting a form. However, the shopping application will not be able to read the response. This is because they are not from the same origin. ( shopping.com vs bank.com )
This is implemented default by all browsers and it’s done for security purposes.
🤯 Imagine if without this Same-origin policy (SOP),
You have visited the shopping application and are unsure if it’s malicious. Well, if there is a script in this shopping application asking for your info such as account number, account balances, and personal info from your bank application, your bank application will hand over this information to the shopping application happily without you even noticing it.
✅ To conclude, this Same-origin policy (SOP) is very important, to prevent such events from happening. Otherwise, all applications will pretty much attack each other and access each other data easily.
Now, do take note that this Same-Origin Policy (SOP) does not prevent writing between web applications, it only prevents reading between two applications.
Then, when the shopping application requests your bank account info from the bank application, and when your bank application sees the request, it will check where the access originated from.
In this case, if the domain is shopping.com, and this domain is different from the bank domain (bank.com), the browser will reject the request because these two applications have different origins.
👀 What is an Origin?
Origin is made up of 3 parts, the scheme(protocol), hostname(domain), and port of the URL used to access it.
Now, let’s do a simple check on the example below:
As we can see, same-origin access only works if the scheme, domain, and port are the same.
We can see there is a new term “CORS” from the network error from the image above.
🚀 Why and what is the Cross-Origin Resource Sharing (CORS) protocol for?
Cross-origin resource Sharing (CORS) is a mechanism that uses HTTP headers to define origins that the browser permits loading resources.
For example, if you are visiting a shopping application and you want to purchase a chair, you want to make a payment via the bank application.
In this case, the bank application may need to loosen up the grip of the same origin policy and allow cross-origin interaction. The bank may not want to stop the interaction so these applications will do is to make use of the cross-origin resource sharing protocol.
Now, you may wonder how would that happen because they are not from the same origin.
While they are still using the same https://, they are still different domains (different origins).
✅ Now, in order to cross-origin, the developer from the bank application may need to configure the CORS rule telling that if there’s a request coming specifically from shopapplication.com, and allow that request to go through.
Hence, bank and shop applications may be able to interact with each other now.
👍🏻 To understand more about CORS Headers
CORS basically makes use of 2 HTTP headers:
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
✅ How are Access-Control-Allow-Origin headers being used?
In this example:
The shopping application is sending a request to read the Bank homepage from the Origin of shopping.com.
If the bank application has configured to Access-Control-Allow-Origin from all shopping.com origins, the bank application will be able to read the request and allow the request to go through.
Access-Control-Allow-Origin Syntax:
Access-Control-Allow-Origin: * //whitelist all the internet
Access-Control-Allow-Origin:<origin> //whitelist only one origin
Access-Control-Allow-Origin: null // redirects and sand box redirects✅ What about Access-Control-Allow-Credentials headers?
Well, Access-Control-Allow-Origin only allows to access public pages, and if you want to access authenticated pages, you will need Access-Control-Allow-Credentials headers.
👉🏻 Access-Control-Allow-Credentials headers allow cookies, authorization headers, or client certificates to be included in the cross-origin request.
Let’s get back to the same example,
You have decided to purchase a chair 🪑 and proceed with payment. The shopping application will send a request to get your account details (authenticated resources )from your bank application.
🚀 The shopping application includes the cookies in the request headers, and the bank will be able to read the request if Access-Control-Allow-Credentials is set to true, and the shopping application will be able to read the authenticated resources from the bank.
Access-Control-Allow-Credentials Syntax:
Access-Control-Allow-Credentials: true //all the internet able to read the authenticated resources🐞 ❌ Now, you may realize something is off here and there are some vulnerabilities using CORS.
I will share about that in the next article! And how you can prevent it as a QA! 🧯
👇🏻 👇🏻👇🏻 👇🏻👇🏻 👇🏻
Make sure you follow me on Medium so that you will get notified of my new articles!
✅ Related Articles:
- “From REST to GraphQL” — Wait, GraphQL? SQL? Are they the same?
- Cloud Computing, let’s talk about it [Part 2]
- AWS! The terms you must know 🤫
- ISTQB 🧙🏻♀️The software testing Myth, do you need that?
- Why is software testing needed in the first place?
- What is Agile Methodology?
- Java 101 for software testing (Using fruits and Vehicle as examples)
- What do you need to know to test using Selenium in Java? (that I wished somebody had told me)
- “Understand what Docker is in 5 minutes: Challenged Accepted”
- Black Box or White Box Testing? (How many boxes do you need ?)
✅ ☎️👇🏻
Or connect with me on LinkedIn to discuss more!
