CORS에 대하여(2)

Cross-Origin Resource Sharing(이하 CORS)에 대한 글입니다.

CORS 기본 동작 순서

개발자는 API를 다루는 것에 있어 종종 Cross-Origin Resource Sharing(이하 CORS) error를 마주합니다.(특히 FE 개발자는 더욱이요!)

왜 클라이언트와 서버 사이에 있는 브라우저에는 CORS와 같은 정책이 존재할까요?

바로 웹서버를 거쳐서 요청하기 때문에 악용될 수 있기 때문입니다. 이를 이해하기 위해선 Same-Origin Policy(이하 SOP)를 알고 있어야 합니다.

SOP란 웹 브라우저에서 실행되는 스크립트나 다른 출처(origin)에서 로드된 리소스와 상호작용하는 것을 제한하는 보안 메커니즘입니다.
SOP에 예외 사항을 두는 것이 CORS입니다! 정책에서 허락하는 범위 내에서 출처간 리소스를 허용하거나 서버 측에서 특정 헤더를 설정하여 SOP를 우회할 수 있게 합니다.

문득 궁금해집니다. 웹서버를 거치면 어떻게 악용될 수 있을까요?

웹서버를 통해 요청하면 구체적으로 어떻게 악용될 수 있는지 알아보았습니다.

XSS 공격: XSS는 악의적인 사용자가 웹 페이지에 악성 스크립트를 삽입하여 다른 사용자의 브라우저에서 실행되도록 하는 공격입니다. 다른 도메인의 리소스에 접근할 수 있는 경우, 악성 스크립트가 포함된 웹 페이지에서는 다른 도메인의 리소스에 접근하여 정보를 탈취하거나 조작할 수 있습니다.
CSRF 공격: CSRF는 인증된 사용자가 자신의 의지와는 무관하게 공격자의 의도에 따라 특정 웹 사이트에 요청을 보내는 공격입니다. 다른 도메인의 리소스에 접근할 수 있는 경우, 악의적인 웹 사이트에서는 사용자의 인증 정보를 사용하여 다른 도메인의 서비스에 위조된 요청을 전송할 수 있습니다. 이러한 공격을 방지하기 위해 SOP이 도입된 것이고, 출처 간 통신을 안전하게 제어할 수 있도록 CORS가 생겼습니다.

나아가 더 궁금해집니다. 그렇다면 서버와 서버의 통신엔 CORS와 같은 정책이 존재할까요?

결론부터 말하자면 존재하지 않습니다. 서버와 서버 사이에서는 웹서버와 같은 중간 단계 없이 바로 통신이 이루어지기 때문입니다. 서버들은 신뢰할 수 있는 환경에서 동작합니다. 서로의 신원을 확인하고, 통신 데이터를 암호화하여 데이터의 기밀성과 무결성을 보장하기 때문입니다.

출처 비교 과정을 디테일하게 알고 싶어졌습니다.

3편에서 마저 다루도록 하겠습니다. 링크