답변
CORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 서로 다른 출처(Origin) 간의 자원 요청을 제한하거나 허용하는 보안 메커니즘입니다.
주요 해결 방법은 다음과 같습니다:
- 서버 응답 헤더에
Access-Control-Allow-Origin
설정 - Preflight 요청(OPTIONS)에 대한 적절한 응답 처리
- 프록시 서버를 통한 요청 전달
Q. 출처(Origin)란 무엇인가요?
출처는 프로토콜, 도메인, 포트의 조합으로 결정됩니다. 이 중 하나라도 다르면 다른 출처로 간주됩니다.
예시
출처 비교 | 동일 출처 여부 |
---|---|
https://a.com:443 → https://a.com:443 | 동일 출처 |
https://a.com:443 → http://a.com:80 | 다른 출처 (프로토콜 다름) |
https://a.com:443 → https://b.com:443 | 다른 출처 (도메인 다름) |
https://a.com:443 → https://a.com:8080 | 다른 출처 (포트 다름) |
Q. CORS가 발생하는 이유는 무엇인가요?
브라우저는 보안상의 이유로 서로 다른 출처 간 리소스 요청을 기본적으로 차단합니다. 이때 다음과 같은 오류가 발생합니다:
Access to fetch at 'https://api.example.com/data' from origin
'https://example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Q. CORS를 해결하는 구체적인 방법을 알려주세요.
1. 서버 응답 헤더 설정
서버 응답 헤더에 Access-Control-Allow-Origin
을 설정하여 특정 출처를 허용할 수 있습니다.
Access-Control-Allow-Origin: https://example.com
2. Preflight 요청 처리
브라우저는 복잡한 요청(예: PUT, DELETE, JSON 데이터, 사용자 정의 헤더 사용 등)을 보내기 전에, 사전 점검 요청(Preflight, OPTIONS)을 서버에 전송합니다.
OPTIONS 요청 예시:
OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type
서버 응답 예시:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
3. 프록시 서버 이용
서버 측에서 직접 CORS를 설정할 수 없는 경우, 클라이언트와 동일 출처로 보이는 프록시 서버를 구축하여 요청을 전달할 수 있습니다.
Next.js를 이용한 프록시 설정 (next.config.js):
async rewrites() {
return [
{
source: '/api/:path*',
destination: 'https://api.example.com/:path*',
},
];
}
Q. CORS 설정 시 주의해야 할 점은 무엇인가요?
보안을 위해 반드시 필요한 최소한의 출처만 허용해야 합니다. 민감한 데이터가 포함된 요청에서는 *
를 사용하지 않고, 명확한 출처를 지정하는 것이 좋습니다. 인증(withCredentials)을 사용하는 경우 반드시 특정 출처를 설정해야 합니다.
인증 요청 시 설정 방법:
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Q. Preflight 요청이 정확히 무엇이며, 어떤 조건에서 발생하는지 설명해주세요.
Preflight 요청은 브라우저가 본 요청을 보내기 전에 서버의 허용 여부를 확인하는 OPTIONS 요청입니다.
다음과 같은 경우에 발생합니다:
- GET, POST, HEAD 외의 HTTP 메소드 사용 (PUT, DELETE 등)
- 커스텀 헤더 사용 (예: Authorization)
- 표준 폼 이외의 Content-Type 사용 (예: application/json)
서버는 Preflight 요청에 적절한 CORS 헤더로 응답해야 실제 요청이 성공할 수 있습니다.
Q. CORS와 관련된 브라우저의 동작 원리를 설명해주세요.
CORS는 브라우저에서 구현되는 보안 메커니즘입니다. 브라우저는 다음과 같은 순서로 동작합니다:
- 요청 전 검사: 현재 페이지의 출처와 요청 대상의 출처를 비교합니다.
- Preflight 요청: 복잡한 요청의 경우 OPTIONS 요청을 먼저 보냅니다.
- 응답 검사: 서버의 CORS 헤더를 검사하여 요청 허용 여부를 결정합니다.
- 에러 처리: CORS 정책 위반 시 응답을 차단하고 콘솔에 에러를 표시합니다.
주의할 점은 CORS 정책 위반 시에도 서버 로그에는 정상적인 요청으로 기록될 수 있다는 것입니다. 이는 CORS가 브라우저에서 구현되는 보안 메커니즘이기 때문입니다.