일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- 트라이 자료구조
- java
- 이분탐색
- queue
- 알고리즘
- expired key
- 벌크헤드패턴
- 자바
- 예외처리
- thundering herd
- Stack
- Entity Manager
- 타임아웃
- ddl-auto
- prg패턴
- 외부 서비스 장애
- 비관적 락
- JPA
- 이진탐색
- 캐시 스탬피드
- BFS
- DP
- 스택
- session인증
- 슬라이스 테스트
- id생성
- 베타락
- 다중 서버
- 백준
- 낙관적 락
- Today
- Total
Coding 01
CORS 본문
CORS(cross origin resource sharing)는 출처가 다른 곳의 리소스를 요청할 때 접근 권한을 부여하는 메커니즘이다.
리소스를 주고받는 두 곳의 출처가 다르면 출처가 교차하는데, 출처가 허용되지 않았다면 cors에러가 발생한다.
출처는 URL뿐 아니라, 프로토콜과 포트까지 포함된다.
cors는 웹 브라우저에서 보안상의 이유로 실행되는 보안 정책이다.
과거에는 csrf(cross-site request forgery) 문제가 있었다고 한다. 피해자의 브라우저에서 다른 애플리케이션으로 가짜 클라이언트 요청을 전송하는 공격이다.
이 csrf를 예방하기 위해 브라우저는 동일 출처 정책(sop, same-origin policy)을 구현했다.
sop가 구현된 브라우저는 클라이언트와 동일한 출처의 리소스로만 요청을 보낼 수 있다. 하지만 sop의 한계가 있어 확장된 cors가 필요하다.
현대의 웹 애플리케이션은 다른 출처의 리소스를 사용하는 경우가 많기 때문이다.
CORS의 작동 방식
cors는 브라우저가 다른 출처로 HTTP 요청을 보낼 때 Origin 헤더를 포함시킨다.
서버는 Access-Control-Allow-Origin헤더로 어떤 출처를 허용할지 응답한다.
브라우저는 이 헤더를 확인하여 요청의 허용 여부를 결정한다.
Preflight요청
브라우저는 실제 요청 전에 OPTIONS메서드로 preflight요청을 보낸다.
서버가 해당 요청을 허용하는 지 먼저 확인한다.
주로 PUT, DELETE같은 위험할 수 있는 요청에서 발생한다.
브라우저가 자동으로 수행하기 때문에 개발자가 직접 구현할 필요가 없다.
preflight가 발생하는 경우는 PUT, DELETE 메서드를 사용할 때, Content-type이 application/json인 경우이다.
실제로 대부분의 api요청에서 preflight가 발생한다고 보면 된다.
'기술면접' 카테고리의 다른 글
TimeOut (0) | 2025.01.07 |
---|---|
private 메서드와 @Transactional (0) | 2025.01.03 |
HTTP 메서드에서 멱등성이란? (0) | 2024.12.27 |
단위 테스트와 통합 테스트의 차이 (0) | 2024.12.23 |
공유 락과 베타 락에 대해서 (1) | 2024.12.21 |