# What are CORS proxies, and when are they safe?

DevFeed: [What are CORS proxies, and when are they safe?](<https://devfeed.tech/articles/what-are-cors-proxies-and-when-are-they-safe-19049.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/cors-proxies/>)

Author: HTTP Toolkit; Tim Perry

Published: 2021-04-01T09:30:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [Cross-origin resource sharing (CORS)](<https://devfeed.tech/topics/cors.md>), [Security](<https://devfeed.tech/topics/security.md>), [browser](<https://devfeed.tech/topics/browser.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [cors](<https://devfeed.tech/tags/cors.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

This tutorial explains how CORS proxies bypass browser security restrictions and examines the security risks they can create. It describes how CORS protects credentials, private network addresses, and responses from unauthorized cross-origin requests.

## Source excerpt

CORS can be complicated. If you're struggling with it, you might discover the concept of a 'CORS proxy' that promises to solve this, like cors-anywhere or one of the many 'free CORS proxy' hosted services. CORS proxies let you bypass the security restrictions that CORS applies, with just a tiny change of URL. That feels convenient, but turning off security feels dangerous. How do CORS proxies work, and what real-world security problems can they create? Why is CORS a problem? For a typical CORS request: You serve some content to your user via your origin (let's say https://home.example). Your content includes JavaScript, which makes a request to another origin (let's say https://other.example). The browser now needs to make a request from the user's machine to that other host. Browsers are very cautious about doing that last step, for two main reasons. First, browsers often have credentials (e.g. cookies) linked to each domain, and one website shouldn't be able to make requests which might use your credentials & sessions for an unrelated domain. Random sites on the internet shouldn't be able to make requests to your bank's servers with your session cookies. Second, the target server might be private, an internal network address like 10.0.0.1, localhost, or a remote server that only allows requests from certain IP addresses. These servers wouldn't normally be accessibly from the public internet, and remote websites shouldn't be able to make requests to them just by bouncing the request through your browser. Both of these are important security protections for end users who (quite reasonably) want to visit websites without losing control of either their online banking or their home router. To protect against this, browsers send CORS headers in requests (and sometimes a CORS preflight request, before the real request) to check that the server is happy to accept the request and share the contents of the response. If the target server isn't aware of CORS, or doesn't want