LabHub
배우기 러닝패스 코스

테스트 도구 실전 · CORS 헤더와 인증의 경계를 테스트한다 · 실습

CORS 헤더와 인증의 경계를 테스트한다

LabHub 에서 이어서 보기

목표

허용·거절 프리플라이트를 비교하고 CORS를 인증으로 오해하는 회귀를 막습니다.

왜 중요한가

허용되지 않은 Origin의 요청이 서버에서 실행되자 개발자가 CORS 라이브러리 버그라고 판단했다. 하지만 브라우저의 읽기 제한과 서버 권한 검사는 다른 책임이었다. 시험 이름과 단언이 무엇을 보장하는지 정확하게 구분해야 한다.

단계

1. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: origin(value)는 http 또는 https URL이며 host가 있고 path·query·fragment·사용자 정보가 없으면 입력 문자열을 반환합니다. 그 외 ValueError입니다. 끝의 /도 path이므로 거절합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

처음 한 번 준비하세요. 기존 파일은 덮어쓰지 않습니다.

mkdir -p /root/work/test-cors-browser-boundary-labtest -e /root/work/test-cors-browser-boundary-lab/service.py || cp /opt/fixtures/ten_labs/test-cors-browser-boundary-lab/service.py /root/work/test-cors-browser-boundary-lab/service.pytest -e /root/work/test-cors-browser-boundary-lab/test_service.py || cp /opt/fixtures/ten_labs/test-cors-browser-boundary-lab/test_service.py /root/work/test-cors-browser-boundary-lab/test_service.pycd /root/work/test-cors-browser-boundary-lab

2. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: origins(values)는 각 항목을 origin으로 검증한 뒤 처음 나온 순서대로 중복을 제거한 새 리스트입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

3. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: methods(values)는 GET·POST·PUT·DELETE·OPTIONS만 허용하고 대문자로 바꿔 중복을 제거합니다. 빈 목록이나 그 외 값은 ValueError입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

4. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: policy(allowed, credentials)는 credentials가 bool인지 확인합니다. allowed에 '*'가 있으면 ValueError이고, {allow_origins:origins(allowed), allow_credentials:credentials}를 반환합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

5. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: create_app(allowed, credentials=True)는 policy를 검증하고 CORSMiddleware를 설정한 앱입니다. GET/POST만 허용하고 Content-Type·X-Request-ID 요청 헤더를 허용하며 X-Trace 응답 헤더를 expose합니다. GET /data는 {ok:True}, X-Trace='trace-1'을 반환합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

6. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: preflight_headers(source, method, requested='X-Request-ID')는 Origin, Access-Control-Request-Method, Access-Control-Request-Headers 세 키를 가진 딕셔너리입니다. method는 대문자입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

7. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: preflight_status(app, source, method, requested='X-Request-ID')는 TestClient로 /data에 OPTIONS 요청을 보내 HTTP 상태를 반환합니다. 다른 출처·DELETE·X-Secret 헤더는 400이어야 합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

8. /root/work/test-cors-browser-boundary-lab/test_service.py에서 제공된 service.py의 다음 공개 계약을 테스트하세요: cors_observation(app, source)는 GET /data를 보내 (상태, Access-Control-Allow-Origin 값 또는 None, JSON 본문)을 반환합니다. 허용되지 않은 출처여도 200 본문은 실행되지만 허용 출처 헤더는 없어야 합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

참고

8단계

  1. 출처 형식을 검증한다 — 테스트
  2. 중복 출처를 제거한다 — 테스트
  3. 메서드를 허용 목록으로 제한한다 — 테스트
  4. 자격 증명과 별표를 함께 허용하지 않는다 — 테스트
  5. 실제 CORS 미들웨어를 단다 — 테스트
  6. 프리플라이트 요청을 만든다 — 테스트
  7. 거절 행렬을 계산한다 — 테스트
  8. CORS와 인증의 차이를 관찰한다 — 테스트