SOP
Same-Origin Policy
웹 브라우저의 보안 정책 중 하나로, 웹 페이지에서 로드된 스크립트가 다른 출처에서 온 리소스에 접근하지 못하도록 제한하는 역할을 한다.
여기서 ‘출처’는 세 가지 요소로 정의된다.
→ 프로토콜(http,https), 도메인, 포트 번호
이 세가지 요소가 모두 같아야 동일한 출처로 간주된다.
SOP가 필요한 이유?
웹 애플리케이션이 서버에 민감한 데이터를 요청할 때, 해커가 악의적인 스크립트를 사용해 다른 도메인의 데이터를 가로채거나 조작하는 것을 막기 위해 SOP가 필요하다.
<SOP가 허용하는 것>
- DOM 조작 : 동일한 출처의 스크립트는 해당 웹 페이지의 DOM에 자유롭게 접근하고 조작할 수 있다.
- 쿠키 접근 : 동일한 출처의 웹 페이지들은 서로의 쿠키에 접근할 수 있다.
<SOP가 제한하는 것>
- XHR(XMLHttpRequest)제한 : 한 출처의 웹 페이지는 다른 출처의 리소스에 XMLHttpRequest를 통해 직접 접근할 수 없다.
- DOM 접근 제한 : 다른 출처에서 로드된 프레임이나 탭의 DOM에 접근할 수 없다.
CORS
Cross-Origin Resource Sharing
SOP의 제한을 완화해 웹 페이지가 다른 출처의 리소스에 안전하게 접근할 수 있도록 하는 매커니즘이다. 이를 통해 한 출처의 웹 페이지가 다른 출처의 서버에 요청을 보내고 응답을 받을 수 있다.
CORS 동작 방식
서버가 브라우저에게 특정 출처의 웹 페이지에서 온 요청을 허용할지를 알려주는 HTTP 헤더를 사용해 동작한다.
- Preflight Request(사전 요청) : 브라우저가 실제 요청을 보내기 전에 ‘OPTIONS’ 메서드를 사용해 서버에 사전 요청을 보내 허용 여부를 확인한다. 이때, 서버는 ‘Access-Control-Allow-Origin’ 헤더를 사용해 어떤 출처의 요청을 허용할지 응답한다.
- Access-Control-Allow-Origin : 이 헤더는 서버가 허용하는 출처를 명시한다. 예를 들어, ‘Access-Control-Allow-Origin: https://exam.com’이면, exam.com에서 온 요청만 허용한다는 것이다. 모든 출처를 허용하려면 ‘*’을 사용해야한다.
- Access-Control-Allow-Credentials : 서버가 자격 증명 정보(쿠키, 인증 헤더 등..)를 요청과 함께 전송할 수 있는지 여부를 나타낸다.
CORS 예시
- 단순 요청 : GET, POST, HEAD 메서드와 몇 가지 제한된 헤더를 사용하는 경우, 브라우저는 사전 요청 없이 바로 서버에 요청을 보낸다.
- 비단순 요청 : PUT, DELETE 등의 메서드 혹은 커스텀 헤더를 사용하는 경우, 브라우저는 사전 요청을 통해 서버의 허용 여부를 먼저 확인한 후 요청을 보낸다.
CORS가 필요한 이유?
SOP의 엄격한 보안 정책 때문에 다른 출처의 API를 사용할 수 없는 상황을 해결하기 위해서 필요하다.
CORS는 개발자가 안전하게 웹 애플리케이션을 확장하고, 다른 출처의 리소스와 상호작용할 수 있는 유연성을 제공한다.
💡 SOP는 보안을 강화하는 데 중점을 두고, CORS는 이러한 보안 정책을 유지하면서 웹 애플리케이션의 유연성을 높이는 역할을 한다.