접근통제와 업무 로직
객체 소유권, 역할, 요청 순서 검증
발생 상황
문의·게시글 ID를 전달하는 API, 역할 변경, 결제·쿠폰 처리처럼 사용자·객체·상태가 연결되는 기능에서 발생합니다.
주요 유형
IDOR/BOLA는 객체 수준 인가, 수직 권한 상승은 높은 역할의 기능 접근을 다룹니다. 중복 파라미터와 경쟁 조건은 파서 차이 또는 처리 순서를 악용하는 업무 로직 문제입니다.
분석할 때 주의할 점
다른 객체 ID가 보인다는 사실만으로 취약한 것은 아닙니다. 공개 여부와 소유권을 기준으로 판단합니다. 비활성 버튼·숨겨진 메뉴·readOnly 입력은 서버 인가가 아닙니다.
대응 방안
매 요청마다 인증된 사용자와 객체의 관계를 서버에서 검사합니다. 중복된 보안 관련 파라미터를 거부하고 파싱 규칙을 통일합니다. 상태 전이는 트랜잭션·잠금·유일성 제약으로 보장하고 재시도 요청의 중복 처리를 방지합니다.
자주 놓치는 부분과 특이사항
목록은 보호되지만 상세·수정·삭제 API가 누락되는 경우가 많습니다. 요청의 sessionUser 값을 신뢰해 사용자를 결정해서는 안 됩니다. 식별자를 UUID로 바꾸는 것은 인가 검사의 대체 수단이 아닙니다.
IDOR와 접근통제 더 알아보기
로그인 여부와 특정 객체에 대한 권한은 별개입니다. 문의 번호를 바꿨을 때 다른 사용자의 비공개 글을 읽거나 삭제할 수 있다면 객체 수준 인가가 빠진 것입니다.
버튼 숨김이나 readOnly 필드는 서버 권한 검사를 대신하지 못합니다. 수평 권한 상승은 다른 사용자의 객체 접근, 수직 권한 상승은 관리자 기능 접근입니다. 조회·수정·삭제 각각에서 소유권과 역할을 검사해야 합니다.
중복 파라미터와 업무 로직 더 알아보기
같은 이름의 role이 두 번 전달될 때 검증기는 첫 값을, 적용기는 마지막 값을 읽으면 권한 검증과 실제 처리 결과가 달라질 수 있습니다. JSON 배열과 중복 폼 파라미터의 차이도 확인합니다.
경쟁 조건은 여러 요청 사이의 검사와 변경이 원자적으로 묶이지 않은 문제입니다. 첫 댓글의 작성자를 관리자로 간주하는 설계처럼 순서를 권한 근거로 삼으면 안 됩니다. 시간 입력값을 조작하는 것과 실제 동시 요청 경쟁은 구분해야 합니다.
요청과 구현 비교
A/B 계정 권한표
비공개 객체를 기준으로 각 API를 독립적으로 시험합니다. 존재하지 않는 객체와 접근할 수 없는 객체의 응답 정책도 일관되어야 합니다.
행위 A → A 소유 B → A 소유
조회 허용 거부
수정 허용 거부
삭제 허용 거부
순차 요청과 실제 동시 요청을 구분하세요.
클라이언트가 적은 지연 시간은 동시성의 증거가 아닙니다.적용 조건과 재검증
역할 × 객체 × 행위
정책을 기본 거부로 시작하고 사용자 역할, 객체 소유자, 조회·수정·삭제 행위를 각각 확인합니다. 소유자 자신의 정상 작업은 허용하고 다른 사용자의 비공개 객체는 거부하는 회귀 검증을 작성하세요. 18번은 여기에 더해 두 요청이 동시에 통과하지 못하도록 원자적 상태 전이를 요구합니다.