[Firebase] CROS정책 - 1

CORS(Cross-Origin Resource Sharing) 정책은 웹 브라우저에서 실행되는 JavaScript 코드가 다른 도메인의 서버에 리소스를 요청하는 것을 제한하는 보안 메커니즘
악의적인 웹사이트가 사용자의 민감한 정보를 탈취하는 것을 방지하기 위해 도입

CORS 정책의 작동 방식:

1. Same-Origin Policy (SOP): 웹 브라우저는 기본적으로 동일한 출처(프로토콜, 호스트, 포트가 모두 동일한 URL)의 리소스 간에만 자유로운 접근을 허용하고 다른 출처의 리소스에 접근하려고 하면 브라우저는 이를 차단한다
2. CORS의 역할: CORS는 SOP의 제한을 완화하여, 서버가 특정 출처의 요청을 허용하도록 명시적인 설정을 할 수 있게 한다. 서버는 HTTP 응답 헤더를 통해 어떤 출처의 요청을 허용할지, 어떤 HTTP 메서드를 허용할지 등을 브라우저에 알린다.
3. Preflight Request: 특정 조건의 교차 출처 요청(예: PUT, DELETE 메서드 사용, 특정 HTTP 헤더 포함 등)의 경우, 브라우저는 실제 요청을 보내기 전에 OPTIONS 메서드를 사용한 "preflight request"를 서버에 먼저 보내고 이 요청을 통해 서버는 해당 출처와 메서드의 요청을 허용하는지 확인하고, 브라우저는 서버의 응답에 따라 실제 요청을 보낼지 여부를 결정한다.

CORS 정책의 장점:

• 보안 강화: 악의적인 웹사이트가 다른 도메인의 민감한 데이터에 무단으로 접근하는 것을 방지하여 웹 애플리케이션의 보안을 강화한다.
• 유연한 리소스 공유: 서버 관리자는 필요한 경우 특정 출처에 대해서만 리소스 접근을 허용함으로써, 보안을 유지하면서도 필요한 교차 출처 요청을 허용할 수 있다
• API 확장성: 공개 API를 제공하는 서비스에서 CORS를 통해 특정 클라이언트 도메인만 접근하도록 허용하거나, 모든 도메인에 접근을 허용하여 API의 활용 범위를 넓힐 수 있다.
• 하위 호환성 유지: CORS가 도입되기 전에 존재하던 웹 서버와 클라이언트의 기존 동작 방식을 크게 변경하지 않으면서 새로운 기능을 추가할 수 있도록 설계되었다.

CORS 정책의 단점:

• 개발 복잡성 증가: 교차 출처 리소스 공유가 필요한 경우, 서버 측에서 적절한 CORS 헤더를 설정해야 하므로 개발 복잡성이 증가할 수 있다.
• 잘못된 설정 시 보안 취약점 발생 가능성: CORS 설정을 잘못하면(예: Access-Control-Allow-Origin: * 와 같이 모든 출처를 허용하는 경우) 오히려 보안 취약점이 발생할 수 있다.
• 브라우저 의존성: CORS 정책은 웹 브라우저에서 적용되는 정책이므로, 브라우저가 아닌 환경(예: 모바일 앱, 서버 간 통신)에서는 적용되지 않는다.
• 에러 발생 시 디버깅 어려움: CORS 에러는 브라우저 단에서 발생하며, 서버 로그에는 정상 응답으로 기록될 수 있어 문제 해결에 어려움을 겪을 수 있다.

요약하자면, CORS 정책은 웹 보안을 강화하고 필요한 경우 유연한 리소스 공유를 가능하게 하는 중요한 메커니즘이지만, 개발자는 이를 정확히 이해하고 적절하게 설정하여 보안 취약점을 만들지 않도록 주의해야 한다