250x250
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 호이스팅
- 실행 컨텍스트
- django westagram
- Jest
- 프로미스
- CORS
- 자바스크립트
- typescript
- javascript
- TypeError: this.boardRepository.createBoard is not a function
- on_delete
- nodeJS
- async/await
- OSI7계층
- westagram
- crud2
- bcrypt
- Django
- 스코프
- 노드
- node
- JWT
- docker
- 장고초기세팅
- 트랜잭션
- rebase
- pm2
- status code
- wecode
- manytomanyfield
Archives
- Today
- Total
될때까지
개념정리 :: CORS? 본문
728x90
이 블로그에 정리되어있는 모든 개념들은 학습 개념으로 혼자 정리한 내용입니다.
잘못 기술한 부분이 있을 수 있으니 발견하시면 언제든지 지적해주세요😄
🥦 SOP(Same Origin Policy)
- 다른 출처의 리소스를 사용하는 것에 제한을 두는 보안 방식
- 브라우저에서 보안을 위해 같은 출처인 경우에만 정보를 주고받을 수 있도록 한 정책이다.
- Origin(출처) => URL의 Protocol + Host + Port가 "모두" 같아야 같은 출처로 여겨진다.
- 옛날에는 하나의 브라우저에서 다른 출처로 요청을 보낼 필요가 없었단 이야기.
이제는 다른 출처로 요청을 보내고 응답을 받는게 자연스러워졌고 또 필요하게 되었다.
🥦 CORS(Cross-Origin Resource Sharing)
- 다른 출처의 자원을 공유한다.
- 추가 HTTP 헤더를 사용하여 한 출처에서 실행중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게 알려주는 체제다.
- 기본값으로 CORS는 막혀있기 때문에 다른 서버의 자원을 요청하면 에러가 발생한다.
- CORS 접근 제어 시나리오 : 단순요청(Simple Request) / 프리플라이트 요청(Preflight Request) / 인증정보 포함 요청(Credentialed Request)
- 요청 헤더의 Origin 헤더와 응답 헤더의 Origin 필드를 비교하여 응답의 유효성을 판단한다.
- Simple Request
- Preflight 요청없이 바로 요청을 날린다.
- 아래 조건을 "모두" 만족해야 한다.
- 메소드 : GET, POST, HEAD
- Content-Type
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
- 헤더는 Accept, Accept-Lauguage, Content-Language, Content-Type만 허용된다.
- Preflight Request
- OPTIONS 메소드를 통해 도메인의 리소스에 요청이 가능한 지 먼저 확인하는 작업이다.
- 요청이 가능하다 응답을 받으면 실제 요청(Actual Request)를 보낸다.
- Preflight REQUEST
- Origin : 요청 출처
- Access-Control-Request-Method : 실제 요청의 메소드
- Access-Control-Request-Headers : 실제 요청의 추가 헤더
- Preflight RESPONSE
- Access-Control-Allow-Origin : 서버 측 허가 출처
- Access-Control-Allow-Methods : 서버 측 허가 메소드
- Access-Control-Allow-Headers : 서버 측 허가 헤더
- Access-Control-Max-Age : Preflight 응답 캐시 기간
- Preflight는 1번의 요청을 보낼 때 사전요청과 실제요청 총 2번의 요청이 발생하기 때문에 리소스의 소모가 큰 편이다.
이를 위해 Preflight 응답에 대해 캐싱을 해두고 동일한 요청은 캐싱된 정보에서 찾아 바로 본요청을 보내게 된다. - Prefligt의 응답코드는 200번대, 응답 바디는 비어있는 것이 좋다는 특징이 있다.
- Credentialed Request
- 인증 관련 헤더를 포함할 때 사용하는 요청이다.
🥦 Simple Request로 1번만 요청을 보내면 간단한데 왜 Preflight가 필요한걸까?
정답 : CORS를 모르는 서버를 위해서 필요하다.
- Preflight가 없다면 이미 서버는 요청한 로직 수행 후 응답값이 브라우저에 전달되지만 CORS에러로 인해 계속 서버의 오류로 남아있기 때문에 이를 방지하기 위해(만약 지우는 요청이라면 서버는 삭제 완료된 상태란 의미) 사용한다.
- Preflight로 보내면 사전요청이기 때문에 서버엔 아무 영향도 주지않고 CORS에러 상태로 유지할 수 있다.
728x90
'학습 > 개념정리' 카테고리의 다른 글
개념정리 :: 프로세스, 쓰레드 (0) | 2022.04.04 |
---|---|
개념정리 :: break와 continue (0) | 2022.02.27 |
개념정리 :: JWT? (0) | 2022.02.22 |
개념정리 :: ORM? (0) | 2022.02.22 |
개념정리 :: git ? github? (0) | 2022.02.20 |