작성하게 된 이유:

어제 연결 세션을 하다보니 백엔드를 너무 모르는 것도 안 될 것 같다라는 생각이 들었다. 기초지식 함양 레츠고
어제 보았다 CORS 에러 로그

Cross Origin Resource Sharing 의 줄임말
해석해보면 교차 출처(다른 출처) 리소스 공유 !
Origin = url 주소 상에서 프로토콜 + Domain 이름 + 포트

참고로 포트번호는 생략 가능하다.
http, https 프로토콜의 기본 포트번호가 정해져 있기 때문!
명시적으로 표기된 게 아니라면 http는 80번 https는 443번 포트가 디폴트 값이다.

그러니까 CORS에러는 다른 출처일 때 나타나는 것이다!

same origin 상에서는 요청 오는 곳 = 처리하는 곳!
➡️ 특별히 보안상 처리를 해줄 필요가 없다.
하지만 cross origin에서 오는 요청이라면 내가 요청으로 받아온 결과를 믿을만한지 검증하는 과정이 필요하다. 왜냐하면 브라우저는 기본적으로 다른 서버를 신뢰하지 않아서 다른 서버에 요청을 보내거나 응답 받는 걸 차단하기 때문이다.
(참고로 이런 브라우저 정책을 SOP라고 한다.)
가장 일반적인 방법으로 서버 측에서 cors 헤더를 설정하여 도메인에서 오는 요청을 허용한다.
아래는 허용하는 도메인을 정의하는 코드 !
// 모든 도메인의 요청을 허용하는 경우
Access-Control-Allow-Origin: *
// 특정 도메인(https://example.com)의 요청만 허용하는 경우
Access-Control-Allow-Origin: https://example.com
아래는 특정한 요청 메서드 또는 커스텀 된 헤더를 허용하도록 정의하는 코드
// 허용되는 메서드를 설정하는 경우
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
// 허용되는 헤더를 설정하는 경우
Access-Control-Allow-Headers: Content-Type, Authorization
// +) 브라우저가 인증 정보가 포함된 요청을 보내는 경우
Access-Control-Allow-Credentials: true

cors 에러를 우회하는 방법이다.
프록시 서버는 클라이언트와 타깃 서버 사이에 위치하며 모든 출처에 대한 요청 및 응답을 허용한다.
따라서 클라이언트가 보내는 요청을 프록시 서버가 대신 타겟 서버에게 전달해주고, 받은 응답을 다시 클라이언트에 반환해준다!
상세하게까지 작성하진 않았지만 우선 CORS 에러에 대한 기초 개념은 알게 된 것 같다 (?)
연결 할 때 이제 CORS 얘기 나오면 괜히 아는 척 할 수 있을 듯 죄송합니다
출처
https://docs.tosspayments.com/blog/payment-window-cors-error
https://velog.io/@jh100m1/posts
https://selfish-developer.com/