프런트엔드 보안의 기초: SOP와 CORS 완벽 이해하기
·
6 views
·10 min read
보안
🚀 프런트엔드 보안의 시작과 끝: SOP & CORS 완벽 가이드
웹 개발을 하며 가장 빈번하게 마주치는 에러가 바로 CORS다. 단순히 "서버에서 헤더 하나 열어주면 해결되는 귀찮은 문제"로 치부하기 쉽지만, 사실 이는 브라우저가 사용자의 데이터를 보호하기 위해 설계한 정교한 보안 메커니즘이다. 우리가 왜 이 에러를 마주해야만 하는지, 그 근원인 SOP부터 파헤쳐 보자.
1. 보이지 않는 방화벽: 동일 출처 정책 (SOP)
**SOP(Same-Origin Policy)**는 "어떤 출처에서 불러온 문서나 스크립트가 다른 출처의 리소스와 상호작용하는 것을 제한"하는 브라우저의 핵심 원칙이다.
🔍 '출처(Origin)'를 가르는 3대 기준
브라우저는 다음 세 가지가 단 하나라도 다르면 서로 다른 출처로 간주하고 통제한다.
- 프로토콜(Protocol):
http와https는 엄연히 다르다. - 호스트(Host): 도메인 이름이 다르면 남이다.
- 포트(Port): 같은 도메인이라도
80포트와3000포트는 다른 집이다.
🚫 왜 브라우저는 '읽기'를 막는가?
책에서 언급한 **'아파트 비유'**처럼, 102호 사람이 201호의 창문을 열어 내부 물건을 훔쳐보는 행위를 막는 것과 같다.
- 차단되는 행위 (Read): 자바스크립트(
fetch,XMLHttpRequest)로 교차 출처의 응답 데이터를 읽어오는 것. - 허용되는 행위 (Embed/Execute): 다른 출처의 리소스를 페이지에 포함하여 실행하는 것. (예: 구글 애널리틱스 스크립트, CDN 이미지 등)
이러한 제약이 없다면 어떤 끔찍한 일이 벌어질까? SOP가 사라진 세상을 상상해 보면 브라우저의 고집이 이해가 가기 시작한다.
💡 Deep Dive: SOP가 없는 세상을 상상해 본다면
SOP가 사라지면 우리가 신뢰하는 웹의 안전망은 순식간에 붕괴된다.
시나리오 1: 실시간 금융 및 개인정보 유출
인터넷 뱅킹과 Gmail에 로그인된 상태에서 악성 사이트 https://cute-cat.com에 접속하면, 배경에서 조용히 내 계좌 잔고를 fetch로 읽어 해커의 서버로 전송할 수 있다. 브라우저에 저장된 내 인증 쿠키가 자동으로 함께 실려 가기 때문이다.
