Spring Boot REST API 인증 우회로 인한 권한 상승 실무 점검 사례

실무에서 발견된 Spring Boot REST API 인증 우회 사례

Spring Boot 기반 REST API를 운영하며 인증·인가 흐름에 대한 내부 점검 중, 특정 엔드포인트에서 인증 우회로 인한 권한 상승이 실제로 발생했던 사례가 있다. 이 문제는 API별로 인증 우선순위와 필수 검증이 일관되지 않아, 권한이 없는 사용자가 관리자 혹은 타인의 데이터에 접근할 수 있게 된 것이 핵심이었다.

사례에서는 일부 API가 @PreAuthorize나 @Secured와 같은 어노테이션으로 보호되고 있었으나, 비슷한 기능을 하는 다른 엔드포인트는 단순히 컨트롤러 메서드 파라미터에서만 인증 정보를 참조하거나, 심지어 인증 체크가 누락된 채로 배포되어 있었다. 특히, 프론트엔드에서 메뉴 노출만 제한하고 API 자체는 누구나 호출 가능하게 된 부분이 실제 보안 구멍으로 이어졌다.

이처럼 실무에서는 인증·인가 코드가 누락된 API가 배포되는 경우가 종종 발생한다. 코드 리뷰나 QA 단계에서 누락을 발견하지 못하면, 운영 중 치명적인 보안 사고로 이어질 수 있다. 현장에서 막히는 지점은 "로그인한 사용자만 접근 가능한 API"와 "특정 권한을 가진 사용자만 접근 가능한 API"의 구분이 불분명하거나, 인증 절차를 컨트롤러 레벨에서 일관되게 적용하지 못하는 경우다.

이 문제를 가르는 점검 순서는 다음과 같다. 먼저, 모든 REST API 엔드포인트 목록을 추출하고 엔드포인트별로 인증·인가 어노테이션이 올바르게 적용되어 있는지 확인한다. 이후, 인증 로직이 컨트롤러/서비스 단에서 중복되거나 누락된 부분이 없는지 점검한다. 마지막으로, 실제로 권한이 없는 사용자가 비정상적으로 접근할 수 있는지 Postman 등으로 사전 테스트를 수행해야 한다.

인증 로직 누락이 발생하는 현장 패턴

현업에서 인증 로직이 누락되는 경우는 대체로 두 가지 패턴에서 발견된다. 첫째, 신규 API 추가 시 기존 코드를 복사해 빠르게 구현하다가 인증·인가 어노테이션을 빼먹는 경우다. 둘째, 인증이 프론트엔드 단에서만 이뤄지는 것으로 오해해, 백엔드 API에서는 인증 처리를 누락하는 경우다.

특히, 빠른 MVP 개발이나 긴급 패치 과정에서 "일단 동작만 되게" 코드를 작성하다가 인증 로직을 임시로 빼놓고, 추후 보완을 잊는 경우가 많다. 예를 들어, 관리자가 사용할 API를 임시로 오픈해두고, 실제 운영 전 인증 처리를 하겠다고 계획만 세워두는 경우다. 그러나 운영 일정이 촉박하거나 담당자가 변경되면서 이 부분이 그대로 남아 버릴 수 있다.

이러한 패턴을 예방하려면, API 개발 시점부터 인증·인가 정책을 명확히 정의하고, 모든 엔드포인트에 대해 "누가 접근할 수 있어야 하는가"를 체크리스트로 관리해야 한다. 그리고 코드 리뷰 단계에서 "이 API는 인증이 꼭 필요한가?"라는 질문을 항상 던져야 한다.

Spring Security 적용 시 흔히 놓치는 인증 우선순위

Spring Security를 사용할 때 가장 흔히 발생하는 실수는 인증 처리의 우선순위를 명확히 하지 않는 것이다. 예를 들어, 전체적으로 JWT 인증을 적용해놓고, 특정 엔드포인트만 permitAll()로 허용하거나, 특정 역할에만 제한을 걸었으나 예외 엔드포인트를 빠뜨리는 경우다.

또한, Global Method Security를 활성화하지 않은 상태에서, 서비스 계층에 @PreAuthorize를 붙여도 무의미해진다. 개발팀 내에서 "컨트롤러 레벨에서만 인증 처리하면 충분하다"는 식으로 인가 체계를 단순화하다가, 실제로는 서비스 계층이나 리포지터리 레벨에서 인증 우회가 발생할 수 있다.

다음은 컨트롤러에서 인증을 누락한 예시다.

// 인증이 누락된 위험한 예시
@PostMapping("/admin/notice")
public ResponseEntity<Void> createNotice(@RequestBody NoticeDto dto) {
    // 인증 체크 없이 관리 공지 생성
    noticeService.create(dto);
    return ResponseEntity.ok().build();
}

이 코드에서는 별도의 인증·인가 체크 없이 누구나 공지사항을 생성할 수 있다. 실제로는 다음과 같이 @PreAuthorize를 추가하거나, Security Config에서 해당 엔드포인트를 명시적으로 보호해야 한다.

실제 점검 순서는 다음과 같다. 먼저, Security Config에서 엔드포인트별로 어떤 필터 체인이 적용되는지 확인한다. 그 다음, 컨트롤러와 서비스 계층에서 인증·인가 어노테이션이 누락된 부분이 있는지 점검한다. 마지막으로, 예상치 못한 인증 우회가 발생하는지 실제로 요청을 보내서 확인한다.

API 인증 점검 자동화의 한계와 실전 대응

API 인증 점검을 자동화하는 방법으로는 Swagger 문서와 연동한 엔드포인트 목록 추출, 정적 분석 도구를 통한 어노테이션 누락 탐지, 통합 테스트 코드 내 인증 실패 케이스 작성 등이 있다. 하지만, 이 방식만으로는 미묘한 인가 정책의 차이, 예외 처리 누락, 개발 환경과 운영 환경의 설정 불일치 등을 완전히 잡아내기 어렵다.

특히, 실무에서는 운영 환경에서만 발생하는 인증 우회 이슈가 있다. 예를 들어, 개발 환경에서는 CORS, HTTPS, 프록시 설정 등 보안 옵션이 완화되어 있다가, 운영 환경에서는 정책이 달라져 인증 로직이 정상 동작하지 않는 경우도 있다. 또한, 엔드포인트 경로가 리팩터링되거나, API Gateway와 연동되면서 인증 적용 범위가 예기치 않게 변경될 수 있다.

자동화 점검의 한계를 보완하려면, 주기적으로 운영 환경에서 "실제 권한이 없는 토큰"이나 "비정상 요청"을 사용한 침투 테스트를 직접 수행해야 한다. 또한, 장애나 사고 사례가 보고될 때마다, 비슷한 인증·인가 누락이 있는지 전체 엔드포인트를 재점검하는 프로세스를 갖춰야 한다.

Spring Boot REST API 인증·인가 실무 점검 체크리스트

• 모든 REST API 엔드포인트에 인증·인가 어노테이션(@PreAuthorize, @Secured)이 누락 없이 적용되어 있는지 정기적으로 점검한다.
• Security Config에서 엔드포인트별 접근 권한(permitAll, authenticated, hasRole 등)이 문서와 실제 코드에 일치하는지 비교 검증한다.
• 신규 API 추가 시, 기본적으로 인증·인가 정책을 명시적으로 정의한 후 코드 리뷰 단계에서 반드시 확인한다.
• 운영 환경에서 실제 권한이 없는 사용자로 각 엔드포인트에 접근해 인증 우회 가능 여부를 주기적으로 테스트한다.
• 인증·인가 정책 변경, 리팩터링, 신규 연동 시 전체 엔드포인트의 인증 흐름을 재점검하는 프로세스를 마련한다.