배경
야 너...
CORS 설명해봐!.. (쭈글)..
REST API 방식으로 프로젝트를 진행하면서 CORS 문제를 해결하기 위해 서버 설정에서 localhost:3000 으로 CORS 설정을 해주었다.
개념적으로 알고있지만, 잘 와닿지 않아서 한번 더 공부해보려고 한다.
CORS(CrossOriginResourceSharing)
"어디에서" 백엔드 서버에 요청을 보내면 CORS로 막히게 될까?
바로 브라우저에서 요청할 때 이다.
즉, 브라우저를 통해 사이트에 접속하고, 사이트에서 서버로 요청을 보낼 때 브라우저가 이 요청보내는 사이트를 못믿고 CORS 제한을 거는 것이다.
언제 문제가 될까?
나쁜 사람들이 사용자로 하여금 자신들이 만든 나쁜 사이트 xxx.com 으로 접속을 유도한다.
현재 내 "브라우저"는 나의 귀중한 정보(인증정보)등을 가지고 있다.
근데 만약 나쁜 사이트 xxx.com에 접속해버리면 해당 사이트의 html, css, "javascript" 코드가 내 브라우저로 받아질 텐데,
이때 이 악성 javascript 코드로 브라우저에서 귀중한 정보를 탈취해버릴 수 있다.
javascript가 인증정보를 가지고 해당 인증 사이트에 조회 요청을 보내버리고, 받아온 정보(개인 정보) 를 xxx.com 서버로 보내버릴 수 있다.
SOP(Same-Origin Policy)
이러한 문제로 사이트가 서버로의 요청을 막고있는 역할을 하는것이 SOP 이다.
SOP(동일 출처 정책)가 사이트에서 서버로의 요청을 막기 때문에 우리가 CORS 문제를 마주하는 것이고, 이를 풀어주기 위해 CORS 정책을 서버에 설정하는 것이다.
CORS는 "서로 다른 출처"끼리 정교교환을 가능하게 하다 라는 의미이다.
원래 기본은 서로 다른 출처끼리는 정보교환이 안되었는데, 웹사이트가 발전하고 서로 다른 사이트간 정보 공유가 활발해지면서 이런 정책 필요성이 생겼다.
그래서 "어떤 기준"을 충족시키면 리소스 공유가 되도록 만들어진 메커니즘이 CORS 이다.
어떤 기준?
요청을 받는 백엔드 서버에서 허락할 다른 출처들을 미리 명시하면 된다.
그래서 위의 프로젝트에서 나는 localhost:3000 경로에 allowedOrigins라고 명시해서 서로 다른 출처이지만 정보 교환이 가능하도록 설정한 것이다.
서로 다른 출처?
포스트맨과 같은 API 도구들로 서버에 API 요청을 하면 CORS문제가 발생하지 않는다.(브라우저가 아니기 때문)
하지만 리액트와 같은 브라우저 상에서 요청하면 서로 다른 출처라고 판단해서 문제가 발생하게 되는데,
Protocol + Host + Port가 같으면 같은 출처로 판단한다.
브라우저는 다른 출처끼리 요청할 때는 header에 Origin 값을 담아서 요청한다.
Origin 안에는 scheme(http, https ..), 도메인, 포트 정보가 담긴다.
서버는 답장에 Access-Control-Allow-Origin 정보를 담아서 보낸다.
여기서 브라우저는 Origin에 보낸 값이 서버에서답장해준 Access-Control-Allow-Origin 안에 있으면 안전한 요청으로 간주하고 응답 데이터를 받아온다.
토큰등 식별 정보가 담긴 중요한 요청에 대해서는 보내는 쪽에서 credentials 항목을 true로 세팅해야함.
받는 서버도 *(와일드카드)가 아닌 정확한 출저를 명시해주고, Access-Control-Allow-Credential 항목을 true로 해줘야한다.
CORS의 2가지 요청
- Simple Request
GET, POST와 같은 일정 조건의 요청들에 사용된다.
- Preflight Request
PUT, DELETE등은 본 요청 전에 프리플라이트 요청을 먼저 보내서 본 요청이 안전한지 확인하고, 허락이 떨어지면 본 요청을 보낸다.
왜 ??? -> 요청에 의해서 서버 데이터가 변경될 위험이 있기 때문.
Simple Request도 서버 데이터 변경 위험이 있을 수 있으므로, 서버에서 안전하게 대비해야 한다.
[학습 출처]
https://www.youtube.com/watch?v=bW31xiNB8Nc
'궁금한 내용은 바로 알아보기!' 카테고리의 다른 글
[모호하면 바로] Nginx는 어디에 사용되는걸까? (1) | 2024.10.14 |
---|---|
[모호하면 바로] HTTP Method의 Patch 동작방식? (0) | 2024.09.21 |
[모호하면 바로] JWT(토큰)의 보안 취약점과 해결 방법? (0) | 2024.09.18 |
[모호하면 바로] 해시함수가 머야? 인코딩이랑의 차이는? (0) | 2024.09.18 |
[모호하면 바로] 인덱스가 왜 B트리를 사용할까? (0) | 2024.09.18 |