CORS(Cross-Origin Resource Sharing)
웹 애플리케이션에서 다른 도메인의 자원을 요청하는 것을 허용하기 위한 보안 메커니즘입니다.
웹 브라우저는 보안상의 이유로 도메인간 자원 공유를 제한하는데,
이를 허용하기 위해서는 서버에서 CORS 설정을 해야합니다.
보통 웹 브라우저는 동일한 출처(Same-Origin)의 자원에 대해서만 요청을 허용합니다.
즉, 요청하는 웹 애플리케이션과 자원을 제공하는 서버가 동일한 도메인, 프로토콜, 포트 번호를 가지고 있어야합니다.
하지만 다른 출처의 자원에 대해서도 요청을 보내고자 하는 경우, CORS를 사용하여 이를 허용할 수 있습니다.
CORS는 브라우저와 서버 간의 통신에 HTTP 헤더를 추가하는 방식으로 동작합니다. 브라우저는 요청 헤더에 Origin 필드를 추가하여 해당 요청이 어느 출처에서 온 것인지 알립니다.
서버는 이 Origin 헤더를 확인하고, 허용된 출처인 경우 응답 헤더에 Access-Control-Allow-Origin 필드를 추가하여
요청을 허용합니다. 이때, 서버는 허용할 출처를 명시하거나 "*"를 사용하여 모든 출처를 허용할 수 있습니다.
CORS는 웹 애플리케이션에서 다른 도메인의 자원을 요청하는 기능을 제공하면서도 보안상의 위험을 최소화합니다. 하지만 CORS를 잘못 구성하면 보안상의 취약점이 될 수 있으므로, 적절한 설정이 필요합니다.
CORS (Cross-Origin Resource Sharing) 에러는 웹 브라우저에서 발생하는 보안 정책으로,
다른 출처(origin)에서 온 자원(resource)에 대한 접근을 제한하는 것입니다.
이것은 다른 도메인이나 포트 등을 가진 서버로부터 리소스를 가져올 때 발생할 수 있습니다.
서버와 서버 간 통신은 보안 정책에 영향을 받지 않습니다. 이는 서버 간 통신이 일반적으로 웹 브라우저를 통하지 않고 직접적으로 이루어지기 때문입니다. 따라서 서버 간 통신에서는 CORS 에러가 발생하지 않습니다.
+ 클라이언트 측 코드가 보안에 취약한 이유
- 클라이언트 측 코드는 브라우저 상에서 실행되기 때문에, 브라우저 보안과 밀접한 연관이 있습니다. 브라우저는 다양한 보안 기능을 제공하지만, 클라이언트 측 코드에 취약점이 있으면 이러한 보안 기능을 우회할 수 있습니다.
- 클라이언트 측 코드는 사용자의 컴퓨터에서 실행되기 때문에, 해당 컴퓨터에 있는 데이터나 시스템에 대한 악성 코드를 실행할 수 있습니다. 따라서, 사용자가 신뢰할 수 없는 웹 사이트에서 악성 코드를 다운로드 받거나, 악성 링크를 클릭하는 등의 행위를 하면, 해당 컴퓨터가 감염될 가능성이 있습니다.
- 클라이언트 측 코드는 서버로부터 다운로드 받는 자원 중에서 가장 많은 비중을 차지합니다. 이러한 클라이언트 측 자원은 쉽게 탈취될 수 있으며, 악성 스크립트를 주입하는 등의 공격에 취약합니다.
- 클라이언트 측 코드는 일반적으로 자바스크립트와 같은 스크립트 언어를 사용하기 때문에, 코드의 가독성과 유지보수성이 높아집니다. 하지만, 이러한 특성은 코드를 분석하고 해석하는 공격자에게도 유리합니다. 따라서, 보안에 취약한 부분을 제거하고, 코드를 안전하게 유지하기 위해서는 적절한 보안 규칙과 코딩 규칙을 준수하는 것이 중요합니다.
+ POSTMAN에서 get요청으로 보낼땐 cors에러가 발생하지않는 이유
CORS 에러는 브라우저에서 발생하는 문제이기 때문에 postman은 브라우저환경이 아니라 해당 문제가 발생하지않는다.
참고 링크 :
🌐 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕 👏
악명 높은 CORS 에러 메세지 웹 개발을 하다보면 반드시 마주치는 멍멍 같은 에러가 바로 CORS 이다. 웹 개발의 신입 신고식이라고 할 정도로, CORS는 누구나 한 번 정도는 겪게 된다고 해도 과언이
inpa.tistory.com
