(WEB_PORTAL) 관리자 권한 상승을 API 레벨에서 원천 차단하기

개요

3단계 권한 체계를 도입한 다음 단계로, 실제로 각 권한이 서로를 침범할 수 없는지 API 단에서 다시 한번 점검했습니다. 화면에서 버튼을 숨기는 것만으로는 충분하지 않고, API 요청 자체를 서버에서 검증해야 진짜 보안이라는 원칙을 지키기 위한 작업이었습니다.

핵심 구현 포인트

1. 권한 상승 시도 차단

일반 관리자가 신규 인원을 등록할 때 역할 값을 함께 보낼 수 있는 구조였는데, 이 값을 그대로 신뢰하면 이론적으로 관리자가 자신이나 타인을 최종 관리자로 만들 수 있는 여지가 있었습니다. 이를 막기 위해 일반 관리자가 생성 요청을 보낼 때는 역할 값을 서버에서 무조건 기본값(일반 직원)으로 덮어쓰도록 했습니다.

2. 상위 권한 계정 보호

일반 관리자가 최종 관리자 계정을 수정하거나 삭제하려는 요청, 그리고 역할 자체를 변경하려는 요청은 서버에서 명시적으로 거부하도록 했습니다.

요청자 = admin, 대상 = super_admin 계정 → 수정/삭제 거부
요청자 = admin, 요청 본문에 role 변경 포함 → 거부

3. 역할 변경 전용 API 분리

역할 자체를 바꾸는 기능은 기존 인원 관리 API에 욱여넣지 않고, 최종 관리자만 접근할 수 있는 별도 API로 분리했습니다. 자기 자신의 역할은 스스로 바꿀 수 없도록 막아서, 실수로 권한을 낮추거나 계정이 고립되는 상황도 함께 예방했습니다.

회고

• "화면에 버튼이 안 보이니 안전하다"는 가정은 보안 관점에서는 틀린 전제라는 걸 다시 확인했습니다. 클라이언트에서 아무리 UI를 숨겨도, 요청은 얼마든지 직접 보낼 수 있기 때문에 실제 방어는 항상 서버 쪽 검증이 최종 기준이어야 했습니다.
• 권한 관련 로직은 기능 단위 API에 조건문을 늘리는 대신, 민감한 동작은 아예 별도 API로 분리해서 "이 엔드포인트는 이 역할만 호출 가능"이라는 규칙을 명확하게 만드는 편이 실수를 줄이는 데 유리했습니다.