여섯 번째 발걸음번호를 안다고 그 자료의 주인이 되지는 않는다

당신의 예약 번호는 51입니다. 주소창에 보이는 번호를 52로 바꾸었더니 다른 사람의 예약이 나타납니다. 문법 오류도 없고 데이터베이스의 오류 메시지도 나오지 않습니다. 요청 형식은 정상인데 허용할 범위가 잘못되었습니다. 이런 문제는 객체별 인가가 빠졌거나 잘못된 곳에서 판단되었을 때 생길 수 있습니다.

서버는 요청자가 누구인지 확인한 뒤, 그 요청자가 바로 그 객체에 바로 그 행동을 해도 되는지 판단해야 합니다. 예약 51을 읽을 수 있다는 권한이 예약 52를 읽을 권한으로 확장되지는 않습니다. 읽을 수 있다고 취소하거나 다른 이용자에게 넘겨도 되는 것도 아닙니다. OWASP API Security Top 10:2023의 BOLA는 이런 객체 수준의 인가 실패를 다룹니다.

수평 권한 상승은 비슷한 역할의 다른 이용자가 가진 자료나 기능에 접근하는 경우를, 수직 권한 상승은 더 높은 역할의 권한을 얻는 경우를 설명할 때 사용합니다. 사용자 A가 B의 예약을 보는 문제와 일반 사용자가 관리자용 전체 내보내기를 실행하는 문제는 확인할 정책이 다릅니다. 역할 이름만 검사하거나 화면에서 버튼을 숨기는 것으로 모든 인가를 대신할 수 없습니다.

객체 안의 속성별로도 권한이 달라질 수 있습니다. 이용자는 배송 주소를 바꿀 수 있지만 결제 완료 상태나 적립금 잔액을 직접 지정하면 안 됩니다. 요청의 여러 필드를 서버 객체에 자동으로 대입하는 대량 할당 기능을 제한 없이 사용하면, 허용하지 않은 속성까지 바뀔 수 있습니다. 반대로 응답 객체를 통째로 보내고 화면에서만 비밀 필드를 숨기면, 네트워크 응답에는 이미 정보가 나갔을 수 있습니다. 필요한 입력 필드와 반환 필드를 명시합니다.

번호를 긴 무작위 값이나 UUID로 바꾸면 추측은 어려워질 수 있습니다. 하지만 주소가 공유되거나 기록에서 노출되었을 때에도 권한 검사가 유지되어야 합니다. 식별자를 아는 것과 접근 자격은 별개입니다. 부서·기관별로 데이터를 나누는 서비스에서는 사용자 번호뿐 아니라 조직 경계도 서버가 확인한 신원과 연결해야 합니다.

# current_user_id는 검증된 서버 세션에서 얻은 값입니다.
sql = """
SELECT id, room, starts_at
FROM reservations
WHERE id = ? AND owner_id = ?
"""
row = db.execute(sql, (reservation_id, current_user_id)).fetchone()

검증에서는 두 개 이상의 가상 계정과 서로 다른 역할을 사용해 같은 객체를 요청해 봅니다. 자기 자료에는 정상 접근이 가능하고, 다른 사람 자료와 관리자 기능에는 정책대로 제한이 걸려야 합니다. 성공한 한 계정의 흐름만 따라가면 권한이 너무 넓은 구현도 정상처럼 보일 수 있습니다.

권한 검사 자체에 오류가 생겼을 때의 동작도 정합니다. 정책 조회가 실패했다는 이유로 일단 허용하면 장애가 곧 접근 우회가 될 수 있습니다. 보호 목표에 맞게 거부하고, 정상 업무를 위한 예외 절차는 별도로 승인·기록해야 합니다. “실패하면 허용”이라는 암묵적 코드 경로를 남기지 않는 것이 중요합니다.

참고　[215] · [228] · [229] · [230]