테스트 도구 실전 · 접근 제어를 깨뜨리는 테스트 행렬 · 이론

접근 제어를 깨뜨리는 테스트 행렬의 설계 원리

한 줄 요약

인증 없음·권한 없음·타인 소유·정상 요청을 분리한 부정 테스트를 작성합니다.

개념 지도: 한 줄 요약 · 왜 이게 필요했나 · 어떻게 동작하나 · 계약을 읽고 실패를 예측하는 워크시트

왜 이게 필요했나

성공 응답만 확인한 접근 제어 시험이 초록불이었다. 경로에서 Header 주입을 빠뜨리거나 scope 검사를 지워도 시험은 깨지지 않았다. 검증자는 허용 사례만 나열하지 않고 각각의 거절 이유를 따로 관측해야 한다.

어떻게 동작하나

각 단계에서 사용자·문서·권한 조합을 직접 만든다. 응답 dict와 상태 코드에 대한 단언을 함께 쓰고, 원본 scopes를 변경하는 복사 결함도 드러낸다. 마지막에는 TestClient로 200·401·403·404 행렬을 실제 실행한다.

학생 테스트 → 정상 구현: 실제 시험 모두 통과           └→ 계약 위반 구현: 해당 동작에서 실패수집 실패·0개 실행·강제 종료 ≠ 결함 검출

계약을 읽고 실패를 예측하는 워크시트

다음은 구현을 통째로 외우는 답안이 아니라 단계별 코드 리뷰입니다. 각 변경 조각은 의도적으로 계약을 깨뜨립니다. 변경 후에도 정상 사례가 통과할 수 있다는 점에 주의하세요. 실행 전에 어느 입력·예외·상태를 관측하면 차이가 드러날지 예상하고, 구현 후에는 그 예상과 결과를 비교합니다.

1. Bearer 헤더를 분리한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: bearer(header)는 정확히 'Bearer '로 시작하고 뒤에 공백 없는 토큰 하나가 있을 때 토큰을 반환합니다. None·빈 토큰·다른 scheme·추가 공백은 ValueError입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 헤더를 임의로 여러 조각으로 나누면 공백 오류를 정상 토큰으로 받아들일 수 있습니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

header[6:]

이 조각이 들어간 함수의 공개 계약과 비교해 보세요. 성공 사례 하나로는 구분되지 않는다면 거절되어야 할 입력이나 실패 이후의 상태를 관측 대상으로 선택합니다.

2. 신원을 복사해 반환한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: principal(token, users)는 토큰 사전의 사용자 {id, scopes}를 반환하되 scopes 리스트까지 복사합니다. 모르는 토큰은 ValueError입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 반환된 scopes를 수정해 원래 사용자 권한까지 바뀌면 요청 간 권한이 섞입니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

user["scopes"]

3. 권한은 정확히 비교한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: require_scope(user, scope)는 scopes에 scope 문자열이 정확히 있을 때 None, 없으면 PermissionError를 냅니다. read-all은 read가 아닙니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 부분 문자열 비교는 더 긴 권한 이름을 다른 권한으로 오해합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

if False:

4. 소유권을 별도로 확인한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: visible(user, document)는 document가 None이 아니고 owner가 user의 id와 정확히 같을 때만 True입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 리소스 없음과 타인 소유를 같은 판정으로 묶습니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

True

5. 응답 필드를 허용 목록으로 고른다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: public_document(document)는 id와 title만 가진 새 딕셔너리입니다. owner나 internal_cost는 포함하지 않습니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 원본에서 필드를 지우지 말고 새 응답을 조립합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

("id", "title", "owner")

6. 오류를 HTTP 계약에 맞춘다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: authenticate(header, users)는 bearer와 principal을 연결합니다. ValueError는 HTTPException(401)이며 headers의 WWW-Authenticate 값은 Bearer입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 인증 실패와 애플리케이션 오류를 500 하나로 뭉치지 않습니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

HTTPException(403,

7. 거절 순서를 고정한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: read_document(user, documents, document_id)는 read scope 없으면 HTTPException(403), 없거나 남의 문서면 HTTPException(404), 아니면 public_document 결과입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 인증 이후에도 scope와 소유권은 각각 확인해야 합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

HTTPException(403, "not found")

8. 실제 요청에서 경계를 닫는다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: create_app(users, documents)는 GET /documents/{document_id}에서 Authorization 헤더를 받아 authenticate와 read_document를 호출하는 FastAPI 앱을 반환합니다. 200·401·403·404와 비공개 필드 제거를 실제 요청으로 검증하세요. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 함수가 따로 맞아도 경로에서 호출을 빠뜨리면 접근 제어는 적용되지 않습니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

authorization: str | None = None

현장에서 만나는 모습

고정 토큰 사전은 교육용 입력이다. 운영 인증에는 만료·서명·폐기·안전한 보관이 추가로 필요하다. 404를 같게 만드는 것만으로 응답 시간이나 접근 로그를 통한 모든 추론이 사라지는 것도 아니다. 거절된 요청이 원본 데이터까지 바꾸지 않았는지 같이 검사한다. 제공 구현은 읽어도 되지만 채점은 별도 사본을 사용한다. 소스 문구 검사나 파일 수정으로 결함을 우회하지 말고 공개 인터페이스의 실행 결과를 검사한다.

다음 실습에서 할 것

여덟 단계가 하나의 실행 가능한 결과물로 이어집니다. Bearer 헤더를 분리한다 — 테스트 → 신원을 복사해 반환한다 — 테스트 → 권한은 정확히 비교한다 — 테스트 → 소유권을 별도로 확인한다 — 테스트 → 응답 필드를 허용 목록으로 고른다 — 테스트 → 오류를 HTTP 계약에 맞춘다 — 테스트 → 거절 순서를 고정한다 — 테스트 → 실제 요청에서 경계를 닫는다 — 테스트.

각 단계는 함수나 파일이 존재한다는 사실이 아니라 실제 반환값·예외·상태 변화를 검사합니다. 정답을 본 뒤에는 일부러 경계 비교나 정리 코드를 바꾸어 어떤 시험이 실패하는지 확인하세요. 앞선 시험이 다음 단계에서도 유지되는 이유를 설명하고, 이 실습이 보장하지 않는 운영 조건을 한 가지 적어 보세요.