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
- https://developers.kakao.com/
- 참고자료 https://velog.io/@imok-_/javascript-dom-bom-%ec%9d%b4%eb%9e%80
- https://ittrue.tistory.com/90
Archives
- Today
- Total
쿠쿠더님의 블로그
CORS란 본문
CORS (cross origin resourse shring)
CORS는 웹의 보안정책들 중에서 하나로 웹 어플리케이션의 서로 다른 도메인의 리소스를 접근할때 발생하는 보안의 이슈로 제어하기위한 정책을 해결하기 위한 방안이다. 쉽게 한줄로 보안은 유지하되 요청과 응답간에 서로 다른 도메인의 서버여도 리소스의 접근이 가능하게 해결한다. |
웹 브라우저 보안 정책 (same-origin-policy)
| 요청을 보낼때 헤더의 내용의 출처가 허용된 도메인인지 검증을 해서 해결 |
| 같은 도메인의 출처가 아닌경우 데이터의 요청과 응답을 허용하지 않는다. |
CORS 원리
| 특정 출처에 요청을 허용할수 있도록 하는 로직 개념 1. preflight 요청 즉 사전에 허용한 출처인지 검증하는 요청 - 다른 도메인에서 요청이 발생하면 프리플라이트 요청을 한번 검증하고 TCP통신이 이루어진다. - 클라이언트에서 메서드를 사용해서 서버에 실제 요청을 보내기 전에 한번검증을 거쳐서 리소스를 안전하게 전달하고 응답받을수 있는것. - HTTP 레벨에서 동작 TCP랑은 별개로 TCP요청은 이후에 진행이된다. - 프리플라이트 요청은 단순 요청에서는 필요가 없다. get과 post 사전검증은 단순 요청에서는 필요 없다. |
CORS의 구조
| 서버가 http 헤더를 사용해서 브라우저에게 특정 출처를 응답 메시지로 허용할지 여부를 알려준다. 두가지의 유형 단순 요청 : 요청 메서드가 get,post 두 요청 프리플라이트 요청(커스텀 헤더) : 요청 메서드가 get,post가 아닌 이외의 모든 요청 메서드인 put,delete 브라우저가 실제로 데이터의 요청과 응답을 주고 받기 전에 사전 요청을 보내서 검증을하고 이후에 데이터를 주고받을수 있다. 응답 헤더에 허용할 출처와 메서드의 내용을 응답헤더로 브라우저에게 응답 메시지를 전달해준다. 브라우저는 출처가 허용된 도메인으로 요청과 응답을 처리할수 있는 상태가 된다. |
CORS의 헤더
| 1. Origin : 클라이언트 요청 출처 |
| 2. Access-Control-Allow-Origin : 허용할 http 메서드 |
| 3. Access-Control-Allow-Methods : 허용할 http 메서드 |
| 4. Access-Control-Allow-Headers : 허용할 요청 헤더의 내용 |
| 5. Access-Control-Allow-Credentials : 자격 증명이나 세션 쿠기 등을 헤더의 내용에 포함될수 있게 허용 |
'NODEJS' 카테고리의 다른 글
| 웹 소켓이란? (0) | 2025.04.21 |
|---|---|
| OAuth 2.0 카카오 로그인 (0) | 2025.04.21 |
| Frountend와 Backend (0) | 2025.03.10 |
| AJAX, Fetch, Axios (0) | 2025.03.10 |
| Multer이란? (0) | 2025.03.10 |