[🌐 네트워크] CORS & SOP

프론트엔드와 백엔드 간의 통신을 하려고 할 때 즉, 클라이언트에서 API를 직접 호출할 때 CORS 정책 위반으로 오류가 나는 상황이 발생한다. 

CORS는 "교차 출처 리소스 공유"를 의미하고, SOP는 그 반대인 "동일 출처 정책"을 의미한다. 

 

"출처가 교차한다"는 의미가 뭘까?

 

출처 (Origin)

우선 CORS와 SOP 공통으로 Origin(출처)이라는 단어를 포함하고 있다. 

출처란 URL에서 도메인, 프로토콜, 포트까지 포함하는 개념으로 이 중 하나라도 다르게 되면 CORS 에러를 만나게 되는 것이다. 

• 도메인 (Hostname) : myshop.com
• 출처 (Origin) : https://myshop.com

 

"출처가 교차한다" 👉 리소스를 주고받으려는 '두 출처가 서로 다르다'를 의미
CORS 설정 👉 "출처가 다른 서버 간의 리소스 공유"를 허용

 

 

 

 

CORS (Cross-Origin-Resource Sharing, 교차 출처 리소스 공유)

👉 서로 다른 출처라도 리소스 요청과 응답 허용할 수 있도록 하는 정책으로서 추가 HTTP 헤더를 사용하여 다른 출처의 자원에 접근가능한 권한 부여하도록 브라우저에 알려주는 체제

 

프론트엔드와 백엔드를 따로 구성하여 클라이언트에서 API를 직접 호출하는 방식을 사용하는 경우가 빈번하다.

보통 클라이언트와 API는 다른 도메인에 있는 경우가 많기 때문에 CORS 정책이 생겼다. 

출처가 다르더라도 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처(Origin)를 명시해주면 된다 !

 

🔹 해결 방법  

• 프론트 : Request Header에 CORS 관련 옵션을 넣는다.
• 서버 : Response Header에 프론트의 요청을 허용한다는 내용을 넣는다.

---

 

🔹 동작 방법 - 기본 흐름 

1. 웹 클라이언트 어플리케이션이 HTTP 프로토콜을 사용하여 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 보낸다. 
2. 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin이라는 값에 "이 리소스를 접근하는 것이 허용된 출처"라는 내용을 실어보낸다.
3. 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교하여 이 응답이 유효한지 결정한다. 

 

🔹 Preflight Request 

• 웹 어플리케이션을 개발할 때 가장 자주 마주치는 시나리오
• 브라우저는 요청을 한 번에 보내지 않고 예비 요청(Preflight)과 본 요청으로 나누어서 서버로 전송 
• 예비 요청에는 HTTP 메소드 중 OPTIONS 메소드가 사용됨

✨ Preflight Request

origin : 서버에 요청이 오는 출처를 알려준다.
access-control-request-method : 요청이 구현하는 HTTP 메서드를 서버에 알려준다.
access-control-request-headers : 요청이 포함된 헤더를 서버에 알려준다.

• 예비 요청의 역할 = 브라우저 스스로 이 요청을 보내는 것이 안전한지 확인
• 요청에 대한 응답으로 서버는 아래와 같은 헤더로 응답하여 이 출처에서 이러한 종류의 요청을 수락할지 여부 결정

✨ Preflight Response

access-control-allow-origin : 서버가 허용할 원본
access-control-allow-methods : 서버에서 허용할 쉼표로 구분된 메서드 목록 
access-control-allow-headers : 서버에서 허용하는 쉼표로 구분된 헤더 목록 
access-control-max-age : preflight 응답을 캐시하는 시간(초)을 브라우저에 알려준다.

 

 

✨ Preflight 요청을 해야하는 이유 ?

🔸 Preflight 요청을 통해 서버는 요청이 실행되기 전에 검사하고 허용 여부를 표시할 기회를 얻을 수 있다. 
🔸 서버는 개발될 때 허용하는 요청 및 헤더의 종류를 변경할 수 있다.  
🔸 서버가 다른 출에서 허용하지 않는 특정 요청을 차단함으로써 서버를 보호하는데 도움을 준다. 

 

---

🔹 Spring Boot에서 CORS 해결하기 

@Configuration
public class CorsConfiguration implements WebMvcConfigurer{
	
    @Override
    public void addCorsMappings(CorsRegistry registry){
    	registry.addMapping("/api")
        	.allowedOrigins("http://localhost:8081");
    }
}

 

 

 

 

 

 

SOP (Same-Origin-Policy, 동일 출처 정책)

👉 서로 다른 출처일 때 리소스 요청과 응답을 차단하는 정책 

 

🔹 차단하는 이유  : 사용자가 악성페이지에 접속하여 악의적인 JavaScript가 실행되면 사용자가 모르는 사이에 potal.example.com에 임의의 요청을 보내고 그 응답값을 해커의 서버로 재차 보내 사용자의 개인정보가 탈취될 수 있다. 

 

 

 

CORS와 SOP를 사용하는 이유 - XSS & CSRF

👉 다른 출처의 어플리케이션이 서로 통신하는 것에 대해 아무런 제약을 두지 않는다면 CSRF(Cross-Site Request Forgery)나 XSS(Corss-Site Scripting)와 같은 방법을 사용해 사용자의 정보를 탈취할 수 있다. 

 

🔹 XSS (Cross-Site Scripting) 

• 공격자가 악의적인 스크립트를 삽입하여 사용자의 브라우저에서 실행되도록 함으로써 공격 수행 👉 다른 웹사이트와 정보 교환하는 식으로 작동 
• 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 발생 
• 쿠키나 세션 정보 탈취
• 다른 사이트로 리다이렉트
• 웹페이지 조작

 

🔹 CSRF (Cross-Site Request Fogery) 

• 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제 등록 등)를 특정 웹사이트에 요청하게 하는 공격 
• 일반적으로 사용자가 이미 인증된 상태에서 공격자의 제어 아래 있는 웹페이지를 방문 시 발생
  ex) 사용자가 은행 웹사이트에 로그인한 상태에서 악의적인 웹페이지를 열면 그 페이지는 사용자의 인증정보를 사용하여 은행 거래 등의 악의적인 요청을 서버에 전송

 

 

 

 

참고자료

https://evan-moon.github.io/2020/05/21/about-cors/

https://docs.tosspayments.com/resources/glossary/cors