회원 등급 변경 API가 화면에서는 숨겨졌지만 호출 가능한 경우

웹사이트나 앱에서는 사용자마다 서로 다른 권한이나 등급을 부여하는 경우가 많습니다. 일반 회원, 유료 회원, VIP 회원, 판매자, 강사, 관리자, 지점 관리자처럼 역할이 나뉘고, 등급에 따라 볼 수 있는 메뉴와 사용할 수 있는 기능이 달라집니다. 쇼핑몰에서는 할인율이 달라질 수 있고, 커뮤니티에서는 글쓰기 권한이 달라질 수 있으며, 교육 플랫폼에서는 수강 권한이 달라질 수 있습니다.

문제는 회원 등급을 바꾸는 기능이 화면에서는 숨겨져 있지만, 실제 API는 외부에서 호출 가능한 상태로 남아 있는 경우입니다. 일반 사용자 화면에는 “등급 변경” 버튼이 보이지 않으니 안전하다고 생각할 수 있지만, 서버 API가 권한 검사를 제대로 하지 않으면 사용자가 직접 요청을 보내 자신의 등급을 바꾸거나 다른 사람의 권한을 변경할 수 있습니다.

이 문제는 단순한 화면 오류가 아니라 권한 상승 취약점으로 이어질 수 있습니다. 사용자가 일반 회원에서 유료 회원, 판매자, 관리자 등급으로 바뀌면 원래 접근할 수 없던 기능과 데이터에 접근할 수 있기 때문입니다. 보안에서 중요한 것은 버튼을 숨기는 것이 아니라, 서버에서 권한을 검증하는 것입니다.

회원 등급 변경 API란 무엇인가

회원 등급 변경 API는 특정 사용자의 역할이나 등급을 수정하는 서버 기능입니다. 예를 들어 관리자가 회원 상세 페이지에서 “VIP로 변경”, “판매자 승인”, “관리자 권한 부여”, “정지 해제” 같은 버튼을 누르면 서버로 요청이 전송됩니다. 이 요청을 처리하는 기능이 등급 변경 API입니다.

API는 화면 뒤에서 작동합니다. 사용자는 버튼을 누르는 것처럼 보지만, 실제로는 브라우저가 서버에 userId, role, grade, status 같은 값을 보내고 서버는 그 값을 바탕으로 회원 정보를 수정합니다.

정상적인 구조라면 이 API는 관리자나 권한 있는 운영자만 호출할 수 있어야 합니다. 일반 회원은 자신의 등급을 직접 바꿀 수 없어야 하고, 다른 사람의 등급을 변경하는 것은 더더욱 불가능해야 합니다.

문제는 화면에서 버튼만 숨기고 서버 API 권한 검사를 하지 않는 경우입니다. 버튼이 보이지 않아도 브라우저 개발자 도구나 직접 요청 도구를 사용하면 API를 호출할 수 있습니다. 따라서 등급 변경 API는 반드시 서버에서 권한을 확인해야 합니다.

화면에서 숨기는 것과 서버에서 막는 것은 다르다

많은 보안 문제가 “화면에서 안 보이니까 괜찮다”는 착각에서 시작됩니다. 프론트엔드에서 버튼을 숨기거나 메뉴를 비활성화하는 것은 사용자 화면을 정리하는 역할일 뿐, 보안 통제는 아닙니다.

예를 들어 일반 회원에게는 관리자 메뉴가 보이지 않게 만들 수 있습니다. 하지만 관리자 메뉴에서 사용하는 API 주소가 그대로 살아 있고, 일반 회원이 그 주소로 요청을 보낼 수 있다면 실제로는 막힌 것이 아닙니다.

사용자는 브라우저 개발자 도구에서 네트워크 요청을 볼 수 있습니다. 관리자가 사용하는 요청 구조를 알거나, 자바스크립트 파일에서 API 주소를 발견하거나, 이전 화면에서 남은 요청을 재사용할 수 있습니다. 버튼이 없어도 요청은 직접 만들 수 있습니다.

따라서 권한 검사는 반드시 서버에서 해야 합니다. 서버는 요청이 들어올 때마다 “이 사용자가 이 기능을 실행할 권한이 있는가”를 확인해야 합니다. 화면은 편의를 위한 표시이고, 실제 보안은 서버 검증입니다.

회원 등급 변경이 위험한 이유

회원 등급 변경은 서비스 권한과 직접 연결됩니다. 일반 회원이 VIP 회원으로 바뀌면 할인, 포인트, 전용 콘텐츠, 이벤트 참여 권한을 얻을 수 있습니다. 판매자나 강사 등급으로 바뀌면 상품 등록, 강의 등록, 정산 정보 확인 같은 기능에 접근할 수 있습니다.

더 위험한 것은 관리자 권한입니다. 일반 사용자가 관리자 등급으로 변경할 수 있다면 사이트 전체가 침해될 수 있습니다. 회원 정보 조회, 주문 정보 확인, 게시글 수정, 댓글 삭제, 설정 변경, 파일 관리, 쿠폰 발급 같은 기능을 사용할 수 있기 때문입니다.

등급 변경 API가 허술하면 공격자는 자신의 권한을 높이는 데 그치지 않을 수 있습니다. 다른 사용자의 권한을 낮추거나, 특정 관리자 계정을 비활성화하거나, 여러 계정을 관리자 권한으로 바꾸는 식의 공격도 가능해질 수 있습니다.

회원 등급은 단순한 표시값이 아니라 접근 권한의 기준입니다. 따라서 등급 변경 기능은 일반 정보 수정 기능보다 훨씬 강하게 보호해야 합니다.

API 호출만으로 등급이 바뀌는 경우

가장 위험한 구조는 API 요청에 포함된 값을 서버가 그대로 믿는 경우입니다. 예를 들어 요청에 userId=123과 role=admin이 들어오면 서버가 별도 검증 없이 해당 사용자의 등급을 관리자로 바꾸는 식입니다.

이런 구조에서는 사용자가 요청 값을 바꿔 자신의 등급을 수정할 수 있습니다. 화면에서는 등급 변경 버튼이 없더라도, 직접 요청을 만들어 보내면 서버가 처리해버릴 수 있습니다.

특히 role, grade, level, isAdmin, isSeller, membershipType 같은 값은 민감합니다. 클라이언트에서 보내는 이런 값을 그대로 신뢰해서는 안 됩니다. 사용자는 브라우저에서 요청 값을 자유롭게 바꿀 수 있기 때문입니다.

서버는 등급 변경 요청을 받으면 먼저 요청한 사용자의 권한을 확인해야 합니다. 그리고 변경 대상, 변경 가능한 등급, 변경 사유, 업무 범위까지 검증해야 합니다. 단순히 값이 왔다고 데이터베이스를 수정하면 안 됩니다.

자기 자신의 등급을 바꾸는 문제

일부 서비스에서는 사용자 정보 수정 API에 등급 정보가 함께 포함되는 경우가 있습니다. 예를 들어 프로필 수정 요청에 이름, 전화번호, 주소와 함께 grade나 role 필드가 들어가는 구조입니다. 화면에는 등급 입력란이 없지만, 요청에 값을 추가하면 서버가 저장하는 경우가 있습니다.

이런 문제를 매스 어사인먼트 취약점과 연결해서 볼 수 있습니다. 서버가 사용자가 수정할 수 있는 필드와 수정할 수 없는 필드를 구분하지 않고, 요청에 포함된 값을 한꺼번에 저장하면 권한 필드가 변경될 수 있습니다.

예를 들어 일반 사용자가 프로필 수정 요청에 isAdmin=true를 추가했는데 서버가 이를 그대로 반영한다면 심각한 문제입니다. 사용자는 화면에서 관리자 체크박스를 본 적이 없어도 요청 값 조작으로 권한을 올릴 수 있습니다.

사용자 정보 수정 API에서는 허용 필드를 명확히 제한해야 합니다. 일반 사용자가 수정할 수 있는 것은 이름, 연락처, 배송지 같은 항목이고, 등급과 권한은 절대 포함되어서는 안 됩니다.

다른 사람의 등급을 바꾸는 문제

회원 등급 변경 API가 대상 사용자 ID를 요청값으로 받는 경우, 다른 사람의 등급을 바꾸는 문제가 생길 수 있습니다. 예를 들어 관리자가 회원 상세 화면에서 userId=1001의 등급을 변경하는 API가 있다고 가정할 수 있습니다.

이때 일반 사용자나 낮은 권한의 관리자가 userId 값을 다른 번호로 바꿔 요청하면 다른 회원의 등급이 바뀔 수 있습니다. 서버가 요청자의 권한과 관리 범위를 확인하지 않으면 발생하는 문제입니다.

특히 지점 관리자, 판매자, 강사처럼 제한된 관리자 권한을 가진 계정에서 이런 문제가 자주 중요해집니다. 지점 관리자는 자기 지점 회원만 관리해야 하고, 판매자는 자기 고객에 대한 제한된 정보만 볼 수 있어야 합니다. 그런데 API가 전체 회원 등급 변경을 허용하면 권한 범위를 넘어선 조작이 가능해집니다.

등급 변경 API는 “요청자가 등급 변경 권한을 가지고 있는가”뿐 아니라 “이 대상 사용자를 변경할 권한이 있는가”도 함께 확인해야 합니다.

관리자 권한 부여 기능은 더 엄격해야 한다

회원 등급 중에서도 관리자 권한 부여는 가장 민감합니다. 일반 회원을 관리자나 운영자로 바꾸는 기능은 사이트 운영 권한을 넘기는 기능과 같습니다. 따라서 일반 등급 변경보다 훨씬 엄격한 절차가 필요합니다.

관리자 권한 부여는 최고 관리자만 가능하게 제한하는 것이 좋습니다. 일반 관리자나 외부 업체 계정, 임시 운영자 계정이 다른 사람에게 관리자 권한을 부여할 수 있으면 위험합니다.

또한 관리자 권한 부여에는 추가 인증을 요구할 수 있습니다. 예를 들어 비밀번호 재확인, 2단계 인증, 승인 절차, 변경 사유 입력, 로그 기록을 적용하는 방식입니다. 단순 버튼 클릭 한 번으로 관리자 권한이 부여되는 구조는 위험합니다.

관리자 권한이 부여되면 즉시 알림이 가는 것도 좋습니다. 사이트 소유자나 최고 관리자에게 “새 관리자 계정이 생성되었습니다” 또는 “회원 권한이 변경되었습니다”라는 알림이 가야 이상 변경을 빠르게 발견할 수 있습니다.

회원 등급과 결제 권한이 연결된 경우

쇼핑몰이나 구독 서비스에서는 회원 등급이 결제 상태와 연결되는 경우가 많습니다. 유료 결제를 완료하면 프리미엄 회원이 되고, 정기구독이 끝나면 일반 회원으로 내려가는 방식입니다. 이 경우 등급 변경 API가 취약하면 금전적 피해가 생길 수 있습니다.

예를 들어 유료 강의 플랫폼에서 사용자가 자신의 등급을 유료 회원으로 바꿀 수 있다면 결제 없이 강의를 볼 수 있습니다. 쇼핑몰에서 VIP 등급으로 바꿀 수 있다면 할인이나 적립 혜택을 부정하게 받을 수 있습니다.

정기구독 서비스에서는 구독 상태, 결제 성공 여부, 환불 여부, 만료일이 서버에서 검증되어야 합니다. 클라이언트에서 membership=premium 같은 값을 보내고 서버가 이를 그대로 믿으면 안 됩니다.

회원 등급이 결제와 연결되어 있다면, 등급 변경은 반드시 결제 시스템의 결과를 기준으로 이루어져야 합니다. 사용자가 직접 요청한 값으로 등급이 바뀌어서는 안 됩니다.

판매자·강사·파트너 승인 기능의 위험

마켓플레이스나 교육 플랫폼에서는 일반 회원이 판매자, 강사, 파트너로 전환될 수 있습니다. 이 권한은 단순 회원 등급보다 더 많은 기능을 제공합니다. 상품 등록, 강의 등록, 정산 정보 입력, 고객 문의 확인, 매출 통계 조회 등이 가능해질 수 있습니다.

판매자나 강사 승인 API가 화면에서는 관리자만 쓸 수 있게 되어 있어도, 서버 검증이 약하면 일반 사용자가 직접 승인 요청을 조작할 수 있습니다. 승인 대기 상태에서 승인 완료 상태로 바꾸는 식의 문제가 생길 수 있습니다.

이런 권한은 금전과 개인정보에 연결됩니다. 판매자 권한을 얻으면 주문자 정보나 배송 정보를 볼 수 있고, 강사 권한을 얻으면 수강생 정보에 접근할 수 있습니다. 따라서 승인 상태 변경 API는 매우 민감합니다.

판매자·강사·파트너 권한 부여는 관리자 검토, 사업자 정보 확인, 약관 동의, 정산 정보 확인 등 절차가 필요할 수 있습니다. API 하나로 상태값만 바뀌는 구조라면 반드시 서버 권한 검증과 변경 로그를 강화해야 합니다.

API 응답에 권한 정보가 과하게 포함되는 문제

회원 등급 변경 API뿐 아니라 회원 정보 조회 API도 주의해야 합니다. 사용자 화면에는 등급 이름만 보이지만, API 응답에는 내부 권한값, 관리자 여부, 숨겨진 역할 목록이 함께 내려오는 경우가 있습니다.

예를 들어 응답에 isAdmin, roleId, permissionList, canChangeRole, internalGrade 같은 값이 포함되면 공격자는 권한 구조를 이해할 수 있습니다. 이런 정보는 등급 변경 API를 분석하는 데 단서가 됩니다.

화면에서 쓰지 않는 권한 정보는 사용자 API 응답에 포함하지 않는 것이 좋습니다. 일반 사용자에게 필요한 것은 본인의 현재 등급과 이용 가능 혜택 정도입니다. 내부 권한 구조와 관리자 기능 가능 여부는 내려줄 필요가 없습니다.

관리자용 API와 사용자용 API는 응답 필드를 분리해야 합니다. 같은 데이터를 쓰더라도 권한에 따라 필요한 값만 반환하는 방식이 안전합니다.

숨겨진 관리자 API가 자바스크립트에 남는 경우

프론트엔드 자바스크립트 파일에는 API 주소가 포함될 수 있습니다. 화면에서는 관리자 메뉴가 숨겨져 있어도, 번들된 자바스크립트 코드 안에 관리자 API 경로가 남아 있으면 사용자가 이를 찾을 수 있습니다.

예를 들어 /api/admin/users/change-role, /api/member/grade/update, /api/user/approve-seller 같은 경로가 자바스크립트 파일에 포함되어 있을 수 있습니다. 공격자는 이 주소를 보고 직접 요청을 시도할 수 있습니다.

API 주소가 노출되는 것 자체가 즉시 취약점은 아닙니다. 제대로 권한 검사가 되어 있다면 요청은 거부되어야 합니다. 하지만 서버 검증이 약하면 숨겨진 API 주소 노출이 실제 권한 상승으로 이어질 수 있습니다.

따라서 “API 주소를 숨기면 안전하다”는 생각도 위험하고, “화면에 버튼이 없으니 API를 호출할 수 없다”는 생각도 위험합니다. API는 발견될 수 있다는 전제로 서버에서 방어해야 합니다.

권한 변경 로그가 필요한 이유

회원 등급 변경 기능에는 반드시 로그가 필요합니다. 누가, 언제, 누구의 등급을, 무엇에서 무엇으로 바꿨는지 기록해야 합니다. 등급 변경은 일반 정보 수정보다 훨씬 민감한 작업이기 때문입니다.

로그가 없으면 사고가 발생했을 때 원인을 추적하기 어렵습니다. 특정 사용자가 갑자기 관리자 권한을 얻었는데 누가 변경했는지 알 수 없다면 대응이 늦어집니다. 내부자 실수인지, 외부 침해인지, API 취약점인지 판단하기 어렵습니다.

로그에는 변경 전 등급, 변경 후 등급, 변경 요청자, 대상 사용자, IP, 시간, 변경 사유가 포함될 수 있습니다. 특히 관리자 권한 부여, 판매자 승인, 유료 회원 변경은 별도로 모니터링하는 것이 좋습니다.

등급 변경 로그는 단순 기록용이 아니라 이상 탐지에도 활용해야 합니다. 새벽 시간대 대량 등급 변경, 낮은 권한 계정의 권한 변경 시도, 실패한 API 호출 반복은 공격 신호일 수 있습니다.

권한 변경 알림이 필요한 경우

중요한 권한 변경이 발생하면 알림이 필요합니다. 일반 회원이 관리자로 변경되거나, 판매자 권한이 승인되거나, 유료 회원 상태가 수동으로 변경되는 경우 담당자에게 알림이 가야 합니다.

사용자에게도 알림이 필요할 수 있습니다. 계정 등급이 변경되었거나 관리자 권한이 부여되었다면 계정 소유자가 알아야 합니다. 본인이 요청하지 않은 변경이라면 빠르게 대응할 수 있어야 합니다.

운영자에게는 더 강한 알림이 필요합니다. 관리자 권한 부여, 관리자 권한 회수, 외부 업체 계정 생성, 대량 등급 변경은 최고 관리자나 보안 담당자에게 전달되는 것이 좋습니다.

알림은 사고를 조기에 발견하는 데 중요합니다. API 취약점으로 권한이 변경되더라도 알림이 있다면 피해가 커지기 전에 확인할 수 있습니다.

안전한 회원 등급 변경 설계 방법

회원 등급 변경 기능을 안전하게 만들려면 먼저 서버 권한 검사를 적용해야 합니다. 요청자가 등급 변경 권한을 가지고 있는지, 대상 사용자를 변경할 수 있는지, 변경하려는 등급이 허용 범위인지 모두 확인해야 합니다.

두 번째로 일반 사용자 프로필 수정 API와 등급 변경 API를 분리해야 합니다. 일반 사용자가 수정할 수 있는 필드와 관리자만 수정할 수 있는 필드를 명확히 나눠야 합니다.

세 번째로 등급 변경에 허용 목록을 적용해야 합니다. 낮은 권한 관리자가 최고 관리자 등급을 부여할 수 없도록 제한해야 합니다. 예를 들어 지점 관리자는 지점 내 일반 회원 상태만 바꿀 수 있고, 관리자 권한은 부여할 수 없게 해야 합니다.

네 번째로 중요한 등급 변경에는 추가 인증을 적용해야 합니다. 관리자 권한 부여, 판매자 승인, 유료 회원 수동 변경은 비밀번호 재확인이나 2단계 인증을 요구할 수 있습니다.

다섯 번째로 변경 로그와 알림을 남겨야 합니다. 누가 어떤 등급을 바꿨는지 추적 가능해야 하고, 이상 변경은 즉시 확인할 수 있어야 합니다.

개발자가 점검해야 할 부분

개발자는 회원 등급 변경 API를 만들 때 클라이언트 요청값을 신뢰하면 안 됩니다. role, grade, isAdmin 같은 값은 서버에서 검증해야 하며, 사용자가 보낸 값을 그대로 저장하면 안 됩니다.

두 번째로 매스 어사인먼트를 방지해야 합니다. 사용자 정보 수정 요청에서 허용된 필드만 업데이트하고, 권한 관련 필드는 무시하거나 별도 관리자 API에서만 처리해야 합니다.

세 번째로 API별 인증과 권한 검사를 분리해서 적용해야 합니다. 로그인 여부만 확인하는 것으로는 부족합니다. 로그인한 사용자라도 등급 변경 권한이 없으면 요청은 거부되어야 합니다.

네 번째로 대상 사용자 권한을 확인해야 합니다. 관리자가 자기보다 높은 권한의 사용자를 수정하거나, 다른 지점 사용자를 수정하거나, 자기 자신의 관리자 권한을 임의로 올리는 것을 막아야 합니다.

다섯 번째로 테스트할 때 화면이 아니라 API를 직접 호출해봐야 합니다. 버튼이 없는 일반 사용자 계정으로 등급 변경 요청을 보내도 서버가 거부하는지 확인해야 합니다.

워드프레스와 회원제 플러그인에서 주의할 점

워드프레스 사이트에서는 회원 역할이 매우 중요합니다. 관리자, 편집자, 글쓴이, 기여자, 구독자 같은 기본 역할이 있고, 회원제 플러그인이나 쇼핑몰 플러그인을 사용하면 유료 회원, 판매자, 강사 같은 역할이 추가될 수 있습니다.

회원제 플러그인이나 커스텀 코드에서 역할 변경 기능을 제공한다면 권한 검사를 확인해야 합니다. 일반 사용자가 자신의 역할을 변경할 수 있거나, 낮은 권한 관리자가 관리자 역할을 부여할 수 있으면 위험합니다.

워드프레스 REST API나 AJAX 요청을 통해 사용자 역할이 변경되는 경우도 있습니다. 이때 current_user_can 같은 권한 확인이 제대로 적용되어야 합니다. 단순히 로그인 여부만 확인하면 안 됩니다.

우커머스 멤버십, LMS, 커뮤니티 플러그인을 사용할 때도 주의해야 합니다. 유료 회원, 강사, 판매자 권한은 콘텐츠 접근과 개인정보 조회에 영향을 줄 수 있으므로 역할 변경 기능을 반드시 점검해야 합니다.

운영자가 확인해야 할 체크리스트

회원 등급 변경 기능을 점검할 때는 먼저 일반 사용자 계정으로 등급 변경 API를 호출할 수 있는지 확인해야 합니다. 화면에 버튼이 없어도 서버가 요청을 거부해야 합니다.

두 번째로 프로필 수정 요청에 role, grade, isAdmin 같은 값을 추가해도 반영되지 않는지 확인해야 합니다. 일반 사용자가 수정 가능한 필드는 제한되어야 합니다.

세 번째로 낮은 권한 관리자 계정으로 테스트해야 합니다. 지점 관리자, 판매자, 상담원 계정이 권한 밖 사용자의 등급을 바꿀 수 없어야 합니다.

네 번째로 관리자 권한 부여 기능에 추가 인증이 있는지 확인해야 합니다. 최고 관리자만 가능한지, 변경 로그가 남는지도 봐야 합니다.

다섯 번째로 권한 변경 로그를 확인해야 합니다. 누가 언제 어떤 회원의 등급을 바꿨는지 추적 가능해야 합니다.

여섯 번째로 권한 변경 알림이 작동하는지 확인해야 합니다. 관리자 권한 부여나 판매자 승인 같은 중요 변경은 담당자에게 알림이 가는 것이 좋습니다.

일곱 번째로 API 응답에 내부 권한 정보가 과하게 포함되어 있지 않은지 확인해야 합니다. 일반 사용자에게 관리자용 권한 구조를 내려줄 필요는 없습니다.

결론

회원 등급 변경 API가 화면에서는 숨겨져 있지만 호출 가능한 상태로 남아 있으면 심각한 보안 문제가 생길 수 있습니다. 버튼을 숨기거나 메뉴를 보이지 않게 하는 것은 보안이 아닙니다. 사용자는 직접 API 요청을 만들 수 있고, 서버가 권한 검사를 하지 않으면 자신의 등급이나 다른 사람의 권한을 바꿀 수 있습니다.

회원 등급은 할인, 유료 콘텐츠, 판매자 기능, 관리자 기능, 개인정보 조회 권한과 연결될 수 있습니다. 특히 일반 회원이 관리자나 판매자 권한을 얻으면 사이트 운영 정보와 고객 데이터에 접근할 수 있어 피해가 커질 수 있습니다.

안전하게 운영하려면 등급 변경은 반드시 서버에서 권한 검사를 해야 합니다. 일반 사용자 수정 API와 관리자 권한 변경 API를 분리하고, 권한 관련 필드는 허용 목록 방식으로 처리해야 합니다. 중요한 등급 변경에는 추가 인증, 로그 기록, 알림을 적용해야 합니다. 회원 등급 변경은 단순 설정값 수정이 아니라 서비스 권한을 바꾸는 핵심 보안 기능으로 관리해야 합니다.