Endlessly learning
Photo by Yann Allegre on Unsplash
In our last article, Cross-Origin Resource Sharing (CORS) Vulnerabilities - Part 1, we discussed the vulnerabilities that can happen when you dynamically generate the Access-Control-Allow-Origin value using the request’s Origin value.
In this article we’ll discuss the other situations you should be aware of where using CORS can increase your application’s security risks.
Photo by Egor Myznik on Unsplash
Cross-Origin Resource Sharing (CORS) is a controlled relaxation of the security Same Origin Policy (SOP) provides. When done properly, it can enable cross-origin functionality across the web.
If not done properly, then security vulnerabilities can easily arise and attackers are more than willing to take advantage.
Photo by Yaniv Cohen on Unsplash
Same Origin Policy (SOP) is a security feature that prevents other websites from reading resources on your site. But what if you want them to read some resources on your site? What if you have a public API you want other websites to interact with? Or what if you made a cool web font for other websites to use?
You can loosen the restrictions of SOP and let other sites access your resources with Cross-Origin Resource Sharing (CORS) headers.
Photo by Christin Hume on Unsplash
Same-origin policy is the backbone of web security, or so I hear.
So what is it? How does it work? How does it protect us and where does it fail?
Photo by Denny Müller on Unsplash
Have you ever wondered what really happens when you click on a link and a webpage magically appears? How does the browser get the data to load the webpage?
At it’s foundation, it’s actually a really basic concept - HTTP requests and responses. Let’s get into it.