API 인가 실패는 조용히 일어난다: 모든 객체·역할·작업을 테스트하라

요약: 인증은 누가 요청했는지를 증명하고, 인가는 그 신원이 무엇을 할 수 있는지를 결정합니다. 팀이 첫 번째 질문만 테스트하고 두 번째 질문도 모든 곳에서 제대로 처리된다고 가정할 때 API 보안은 무너집니다.

유효한 토큰이 곧 허가증은 아니다

현대 API는 객체 수준 통제가 약한데도 강력한 인증을 앞단에 두는 경우가 많습니다. 요청에 완전히 유효한 세션이나 액세스 토큰이 있어도 다른 고객의 청구서, 프로젝트, 내보내기 자료 또는 관리 작업을 요구할 수 있습니다. 핸들러가 호출자의 로그인 여부만 확인한다면 API는 잘못된 보안 질문에 답한 것입니다.

일반적인 제품 테스트는 의도된 경로를 따르므로 이런 실패를 놓치기 쉽습니다. 소유자는 자신의 레코드를 열고 관리자는 관리자 엔드포인트를 사용하며 모든 요청은 예상대로 성공합니다. 인가 결함은 신원, 객체, 테넌트 또는 작업을 의도적으로 서로 맞지 않게 조합할 때만 드러납니다.

완전한 인가 매트릭스를 구축하라

• 모든 객체 작업을 소유자, 같은 테넌트의 동료, 다른 테넌트의 사용자, 미인증 호출자 입장에서 각각 테스트합니다.
• 읽기, 생성, 수정, 삭제, 내보내기, 초대, 승인 작업을 서로 독립적으로 실행합니다. 한 메서드가 보호된다고 해서 다른 메서드도 보호된다는 뜻은 아닙니다.
• 눈에 띄는 URL 필드만 테스트하지 말고 경로, 쿼리 매개변수, JSON 본문, 헤더, 중첩 객체의 식별자를 바꿉니다.
• 강등되거나 제거된 사용자가 캐시된 클레임을 통해 권한을 유지하지 못하도록 역할 변경과 오래된 세션을 검증합니다.

데이터 경계에서 기본적으로 거부하라

가장 신뢰할 수 있는 설계는 모든 쿼리를 요청된 객체와 호출자에게 허용된 범위 모두에 결합합니다. 식별자로 레코드를 가져온 뒤 나중에 소유권을 확인하면 누락된 검사, 부채널, 일관되지 않은 오류 처리의 여지가 생깁니다. 테넌트나 소유권 경계 안에서 쿼리하면 안전 조건 자체가 조회 과정의 일부가 됩니다.

중앙 정책 헬퍼는 편차를 줄이지만 테스트를 대신하지는 못합니다. 각 엔드포인트에는 금지된 신원에 데이터가 전달되지 않고 상태도 바뀌지 않았음을 증명하는 부정 검증이 여전히 필요합니다. 데이터베이스와 하위 시스템의 부작용이 전혀 없을 때만 403 응답이 유용한 증거가 됩니다.

금지된 경로가 닫힌 채 유지됐음을 증거로 입증하라

유용한 인가 테스트는 호출자, 역할, 테넌트, 대상 객체, 요청, 응답, 요청 후 상태를 기록합니다. 이 증거는 실제 통제와 프런트엔드 제한, 또는 이미 실행된 작업을 감추는 상태 코드를 구별해 줍니다.

KENSAI는 액세스 제어 검증을 단일 정상 경로 스캔이 아니라 매트릭스로 다룹니다. 목표는 신원과 작업 사이의 격리를 입증하고, 경계 실패를 재현하며 수정 여부를 검증할 수 있을 만큼 충분한 증거를 보존하는 것입니다.

핵심 요약

인가는 신원, 객체, 작업 사이의 관계입니다. 세 차원을 모두 부정 사례로 테스트하고, 금지된 요청이 데이터 노출도 부작용도 일으키지 않음을 입증해야 합니다.