CORS 정책을 바꿨지만 브라우저에 이전 preflight 허용이 남아 있습니다. 실제 요청의 안전성을 어떻게 유지하나요?
꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
01
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
preflight cache는 브라우저가 실제 요청을 보낼지에 영향을 주지만 서버의 현재 인가를 대신하지 않습니다. 이전 허용으로 요청이 도착해도 원본 API는 새 권한과 상태 규칙을 적용해야 합니다.
정책 전환 중 정상 client가 얼마나 오래 이전 허용을 사용하는지 max-age·구현을 확인합니다. 응답 노출의 CORS 설정과 변경 자체의 CSRF·인가를 구분합니다. OPTIONS만 차단하고 실제 endpoint를 느슨하게 두는 설계는 사용하지 않습니다.
02
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- preflight cache는 브라우저가 실제 요청을 보낼지에 영향을 주지만 서버의 현재 인가를 대신하지 않습니다. 이전 허용으로 요청이 도착해도 원본 API는 새 권한과 상태 규칙을 적용해야 합니다.
- OPTIONS만 차단하고 실제 endpoint를 느슨하게 두는 설계는 사용하지 않습니다.
03
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: preflight cache는 브라우저가 실제 요청을 보낼지에 영향을 주지만 서버의 현재 인가를 대신하지 않습니다.
04
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.