[네트워크] SOP와 CORS & REST

SOP와 CORS 두 정책은 모두 출처(origin)와 관련된 개념이다.

출처는 URL의 프로토콜, 호스트, 포트 3가지로 정의된다.

 

---

 

✅  SOP (Same Origin Policy)

: 같은 출처(same origin)에 한해서 리소스를 허용하는 정책 = 다른 출처의 리소스와 상호 작용하는 것을 제한하는 정책

 

앞서 말했듯이 URL의 프로토콜, 호스트, 포트가 모두 같은 출처를 동일 출처라고 한다.

 

• CSRF, XSS 등의 보안 공격으로부터 안전하다.
• 하지만, 외부에서 데이터를 불러올 수 없다. 

 

---

 

📍 동일 출처 예시

`http://store.com/dir/page.html` 를 기준으로 동일 출처인지 비교하면 다음과 같다.

• `http://store.com/dir2/page.html`는 동일 출처
• `http://store.com/dir/page2.html`는 동일 출처
• `https://store.com/dir/page.html`는 프로토콜(https)이 달라 다른 출처
• `https://store.com:81/dir/page.html`는 포트(:81)가 달라 다른 출처
• `https://store2.com/dir/page.html`는 호스트(store2)가 달라 다른 출처

 

---

 

✅ CORS (Cross Origin Resource Sharing)

: SOP를 완화해 주는 기술로, 서버에서 특정 리소스를 받아올 수 있도록 허용하는 정책

 

 

SOP의 한계 때문에 다른 출처의 리소스를 받아올 수 없다.

하지만 프런트엔드(React, 3000 포트)와 백엔드(Spring, 8080 포트)처럼 서로 다른 출처 간에도 통신이 필요할 수 있다.

 

이때 필요한 것이 바로 CORS이다.

 

서버에서 CORS를 통해 허용할 출처(origin)를 명시해 주면 브라우저는 요청을 허용한다.

 

---

 

✅  Preflight Request

: 브라우저가 실제 요청 전에 요청 허용 여부를 서버에 미리 확인하는 과정

 

 

Preflight Request는 클라이언트가 위험할 수 있는 요청을 보내기 전에 

해당 요청이 서버에 의해 명시적으로 허용되는지 확인하기 위해 필요하다.

 

📍언제 발생?

• 요청 메서드가 GET, POST, HEAD가 아닐 때 (예: PUT, DELETE 등)
• Content-Type이 `application/json` 등 일반적인 타입이 아닐 때
• `Authorization`, `X-Custom-Header` 등의 커스텀 헤더가 포함될 때

 

---

 

📍동작 방식

1. 브라우저가 OPTIONS 메서드로 Preflight 요청을 서버에 전송

OPTIONS /api/data HTTP/1.1
Origin: http://localhost:3000
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

 

 

2. 서버가 CORS 설정에 따라 허용 여부를 응답

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: Content-Type

 

3. 허용되면 실제 요청을 전송

 

---

✅  REST (Representational State Transfer)

 

: 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미 

 

결합도를 낮춰, 서버와 클라이언트가 별도로 구축될 수 있도록 한다.

 

1. HTTP URI를 통해 자원을 명시하고,
2. HTTP Method를 통해
3. 해당 자원에 대한 CRUD 연산을 적용하는 것을 의미

 

 

---

📍 REST 구성 요소

1. 자원(Resource) - HTTP URI
2. 자원에 대한 행위 - HTTP Method
3. 자원에 대한 행위의 내용 - HTTP Message Payload

 

---

📍 REST 제약조건 6가지

1. Client-Server: 클라이언트와 서버가 독립적으로 동작
2. Stateless: 각 요청은 독립적이며, 서버는 상태를 저장하지 않음
3. Cache: 클라이언트가 서버의 응답을 캐시 하여 성능 향상할 수 있음
4. Layered System: 클라이언트와 서버 사이에 여러 중간 계층 서버가 있을 수 있음
5. Uniform Interface: 전체적인 시스템 아키텍처를 간단하게 파악할 수 있도록 하기 위한 약속된 인터페이스 사용
   • JSON이 가장 유명한 방식
6. Code on Demand(Optional): 클라이언트에 보내는 데이터를 바로 실행 가능한 코드형태로 보내서 이것을 클라이언트 내에서 실행

 

---

📍 RESTful 이란

:  REST의 원리를 따르는 시스템

 

RESTful API는 REST의 6가지 제약조건을 잘 따르는 API

즉, 자원을 URI로 명확히 표현하고 HTTP 메서드를 사용하여 자원을 조작하는 API이다.