인증은 했는데 왜 뚫릴까? API 보안의 숨은 허점

― “로그인은 통과했는데 사고는 왜 반복될까. API 시대의 보안은 더 이상 ‘인증’이 아니라, ‘어디까지 허용할 것인가’의 문제다.”

목차
   ­ㄴ 왜 ‘인증했는데’ 사고가 나는가?
   ­ㄴ 인증(Authentication)과 인가(Authorization)는 다르다
   ­ㄴ API Gateway만으로 충분하지 않은 이유
   ­ㄴ 실무에서 자주 발생하는 치명적 설계 실수
   ­ㄴ AI 시대, API 남용 공격은 더 빨라진다
   ­ㄴ 기업이 지금 점검해야 할 5가지
   ­ㄴ 결론: API 보안은 장비가 아니라 설계의 문제다

 

1. 왜 ‘인증했는데’ 사고가 나는가?

API 보안 사고의 공통점은 하나다.
공격자는 로그인에 실패하지 않았다는 점이다.

계정을 확보한 뒤 정상적으로 인증을 통과한다.
문제는 그 이후에 발생한다.

인증은 “신원 확인”일 뿐이다

예를 들어 사용자가 자신의 정보를 조회하는 API가 있다고 하자.

정상 요청

GET /api/users/1001
Authorization: Bearer {정상토큰}

 

 

정상 응답

{
  "user_id": 1001,
  "name": "홍길동"
}

 

여기까지는 문제없다.

숫자 하나 바꾸면 벌어지는 일

공격자가 URL의 숫자만 바꾼다.

GET /api/users/1002
Authorization: Bearer {정상토큰}

 

 

만약 서버가 이렇게 응답한다면,

{
  "user_id": 1002,
  "name": "이몽룡"
}

 

이 시스템은 인증은 했지만,
해당 데이터에 접근할 권한은 검증하지 않은 것이다.

사고는 로그인 실패가 아니라 “권한 검증 실패”에서 시작된다

많은 기업은 이렇게 생각한다.

• JWT 사용 중
• API Gateway 적용
• HTTPS 적용

하지만 이것은 입장권 확인에 불과하다.

API 보안의 핵심 질문은 이것이다.

“이 사용자가 이 데이터에 접근해도 되는가?”

이 질문이 코드에서 빠지는 순간,
인증은 의미를 잃는다.

핵심 정리

• API 사고는 대부분 정상 로그인 이후 발생한다.
• 인증은 신원 확인일 뿐이다.
• 데이터 접근 권한(Authorization)을 검증하지 않으면 사고가 난다.
• 숫자 하나 바꾸는 것만으로 유출이 가능해진다.

API 시대의 보안은
“로그인을 막는 것”이 아니라
**“로그인 이후를 통제하는 것”**에 달려 있다.

2. 인증(Authentication)과 인가(Authorization)는 다르다

API 보안 사고의 상당수는 기술 부족이 아니라
개념 혼동에서 시작된다.

많은 시스템이 이렇게 설계된다.

로그인 성공 → 접근 허용

하지만 인증과 인가는 전혀 다른 단계다.

인증은 “누구인가”를 확인하는 절차

예를 들어 사용자가 로그인하면 서버는 토큰을 발급한다.

POST /login

 

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

 

 

 

이 토큰은 사용자의 신원을 증명한다.

즉,

• 이 사용자가 누구인지
• 토큰이 위조되지 않았는지

까지만 보장한다.

인가는 “무엇을 해도 되는가”를 판단하는 절차

이제 사용자가 다음 요청을 보낸다.

GET /api/orders/5001
Authorization: Bearer {정상토큰}

 

 

서버가 반드시 확인해야 할 것은 이것이다.

• 이 주문이 해당 사용자 것인가?
• 이 사용자가 주문 조회 권한을 가지고 있는가?

인가 검증이 포함된 정상 로직은 이런 구조다.

if token.isValid() and isOwner(token.user_id, order_id):
    return order
else:
    return 403 Forbidden

 

 

인가 검증이 빠지면 200 OK가 되고,

그 순간 데이터 유출이 발생한다.

API Gateway가 대신해주지 않는 부분

많은 조직이 “Gateway에서 인증 처리 중”이라고 말한다.

Gateway는 토큰 유효성은 확인할 수 있다.
그러나 다음은 알 수 없다.

• 이 주문이 누구의 것인지
• 이 계좌에 접근 권한이 있는지
• 이 문서가 어떤 조직에 속하는지

이 판단은 애플리케이션 내부 로직의 책임이다.

핵심 정리

• 인증 = 신원 확인
• 인가 = 자원 접근 권한 판단
• 인증만 있고 인가가 없으면 사고가 난다
• API 보안의 핵심은 객체 단위 권한 검증이다

API 환경에서는
“로그인했으니까 괜찮다”는 사고방식이 가장 위험하다.

3. API Gateway만으로 충분하지 않은 이유

많은 기업이 API Gateway를 도입한 뒤 이렇게 생각한다.

“이제 API 보안은 정리됐다.”

토큰 검증도 하고,
HTTPS도 적용했고,
접근 통제도 걸어두었다.

그러나 Gateway는 입구를 지키는 장치일 뿐이다.

Gateway가 해주는 것

API Gateway는 다음을 수행한다.

• 토큰 유효성 검증
• 서명 확인
• 기본 접근 제어
• Rate Limiting
• IP 차단

예를 들어,

GET /api/users/1001
Authorization: Bearer {정상토큰}

 

 

Gateway는 토큰이 정상인지 확인하고

정상이면 내부 서비스로 전달한다.

여기까지는 안전해 보인다.

Gateway가 못하는 것

Gateway는 다음 질문에 답할 수 없다.

• 이 데이터가 해당 사용자 소유인가?
• 이 요청이 업무상 필요한 범위인가?
• 이 객체에 접근할 권한이 실제로 있는가?

즉, Gateway는 “문을 열어줄지”는 판단하지만,
“어떤 방까지 들어갈 수 있는지”는 판단하지 못한다.

실제로 발생하는 구조

공격자가 정상 토큰을 가진 상태에서 요청을 보낸다.

GET /api/users/1002
Authorization: Bearer {정상토큰}

 

 

Gateway는 통과시킨다.

왜냐하면 토큰은 정상이고, 접근 경로도 허용 범위이기 때문이다.

문제는 내부 애플리케이션이
1002번 사용자가 요청자 본인인지 확인하지 않을 경우다.

이 경우 Gateway는 아무 역할을 하지 못한다.

마이크로서비스 환경에서는 더 복잡해진다

현대 시스템은 단일 서버가 아니라
여러 내부 API가 서로 호출하는 구조다.

• 프론트엔드 → API Gateway
• Gateway → 내부 서비스 A
• 서비스 A → 서비스 B

이 과정에서 내부 호출은
“신뢰된 요청”으로 처리되는 경우가 많다.

하나의 서비스가 침해되면
연쇄적으로 다른 서비스까지 접근 가능해진다.

Gateway는 내부 서비스 간 권한 위임까지 통제하지 못한다.

핵심 정리

• API Gateway는 필요하지만 충분하지 않다.
• Gateway는 인증을 검증할 뿐, 비즈니스 권한은 판단하지 않는다.
• 객체 단위 인가 검증은 애플리케이션 내부 책임이다.
• 내부 API 호출 구조까지 고려하지 않으면 연쇄 침해가 가능하다.

API 보안은 장비로 완성되지 않는다.
설계와 코드에서 완성된다.

4. 실무에서 자주 발생하는 치명적 설계 실수

API 사고는 대부분 고급 해킹 기법 때문이 아니다.
설계 단계에서 놓친 기본 검증이 원인인 경우가 많다.

다음은 실제 현장에서 반복적으로 발견되는 유형들이다.

① 객체 단위 권한 검증 누락 (BOLA)

가장 흔한 실수다.

GET /api/accounts/3001
Authorization: Bearer {정상토큰}

 

 

서버 로직이 단순히 이렇게 되어 있다면,

if token.isValid():
    return getAccount(account_id)

 

 

계좌 소유자 검증 없이 데이터가 반환된다.

이 한 줄의 차이가 대량 개인정보 유출로 이어진다.

② 과도한 권한 부여 (Over-Permission)

관리 편의를 이유로 하나의 토큰에 여러 권한을 부여하는 경우가 많다.

예를 들어 일반 사용자 토큰이 다음과 같은 API도 호출 가능하다면,

GET /api/admin/users
Authorization: Bearer {일반사용자토큰}

 

 

 

권한 분리가 제대로 이루어지지 않은 구조다.

권한은 “역할(Role)”이 아니라
“행위(Action)” 기준으로 최소화해야 한다.

③ 내부 API는 안전하다는 착각

많은 기업이 내부망 API에 대해 별도의 인가 검증을 하지 않는다.

GET http://internal-service/api/user-list

 

 

“외부에서 접근 못하니까 괜찮다”는 판단이다.

그러나 내부 계정 탈취나 SSRF 취약점이 존재하면
이 API는 그대로 공격 통로가 된다.

내부 API도 외부와 동일한 기준으로 보호해야 한다.

④ 토큰 검증은 하지만 범위(scope)는 확인하지 않는 구조

OAuth 기반 시스템에서 자주 발생한다.

{
  "scope": "read write admin"
}

 

 

 

토큰에 다양한 scope가 포함되어 있지만
실제 API에서는 이를 확인하지 않는 경우가 많다.

if token.isValid():
    processRequest()

 

 

scope 검증이 빠지면

권한 분리는 의미를 잃는다.

⑤ 대량 호출에 대한 통제 부재

정상 사용자라도 자동화 도구를 사용하면
짧은 시간에 수천 건의 요청을 보낼 수 있다.

GET /api/users/1001
GET /api/users/1002
GET /api/users/1003
...

 

 

Rate Limiting이나 이상 탐지 로직이 없다면

합법적인 요청으로 위장한 대량 수집이 가능해진다.

핵심 정리

실무에서 발생하는 API 사고의 특징은 단순하다.

• 권한 검증 누락
• 최소 권한 원칙 미적용
• 내부 API 무방비
• scope 확인 생략
• 대량 호출 통제 부재

이 모든 문제는
장비가 아니라 설계와 코드에서 발생한다.

API 보안은 복잡해서 사고가 나는 것이 아니다.
기본 검증을 생략했기 때문에 사고가 난다.

5. AI 시대, API 남용 공격은 더 빨라진다

과거 API 침해는 사람이 직접 테스트하고,
엔드포인트를 하나씩 분석하는 방식이 일반적이었다.

지금은 다르다.

AI와 자동화 도구의 결합으로
API 탐색·변조·수집이 훨씬 빠르고 정교해졌다.

자동화된 엔드포인트 탐색

AI 기반 스캐닝 도구는 다음을 자동으로 수행한다.

• 공개 문서(Swagger, OpenAPI) 분석
• 파라미터 구조 추론
• 응답 패턴 비교
• 권한 검증 누락 여부 탐지

예를 들어, /api/users/{id} 형태가 발견되면
자동으로 ID 범위를 추정하고 반복 호출한다.

GET /api/users/1001
GET /api/users/1002
GET /api/users/1003
...

 

 

이 과정이 초 단위로 이루어진다.

 

토큰 재사용 및 자동화 공격

공격자가 정상 계정 하나만 확보해도
AI는 다음을 자동화할 수 있다.

• 토큰 유효 시간 분석
• 만료 전 대량 호출
• 응답 구조 학습
• 유의미한 데이터 선별 저장

이제 공격은 “가능한가”의 문제가 아니라
“얼마나 빠른가”의 문제로 바뀌고 있다.

LLM 기반 공격 시나리오

LLM은 단순한 코드 생성 도구가 아니다.
API 문서를 입력하면 다음과 같은 전략을 제안할 수 있다.

• 취약 가능성이 높은 엔드포인트 예측
• 권한 검증 누락 추정
• 우회 테스트 케이스 생성
• 자동화 스크립트 코드 작성

즉, 전문 지식이 부족한 공격자도
AI를 통해 고급 테스트를 수행할 수 있다.

남용(Abuse) 탐지가 더 어려워진다

AI 기반 공격은 전통적인 “비정상 트래픽”과 다르다.

• 로그인 정상
• 요청 형식 정상
• 응답 코드 정상
• 속도도 제한 범위 내 조절 가능

모든 것이 정상처럼 보이지만
행위의 목적이 비정상이다.

이런 유형은 단순 WAF나 Gateway 정책으로는 탐지하기 어렵다.

핵심 정리

• AI는 API 탐색과 공격 자동화를 가속화한다.
• 정상 계정 하나만으로 대량 수집이 가능해진다.
• LLM은 취약 가능 지점을 스스로 추론한다.
• 남용 탐지는 점점 더 어려워지고 있다.

API 보안은 이제
“막을 수 있는가”가 아니라
“얼마나 빠르게 악용될 수 있는가”를 기준으로 설계해야 한다.

6. 기업이 지금 점검해야 할 5가지

API 보안은 복잡한 기술 문제가 아니다.
대부분은 기본 점검 항목을 놓쳤기 때문에 사고가 난다.

지금 바로 확인해야 할 핵심 5가지는 다음과 같다.

① 객체 단위 권한 검증이 있는가

모든 주요 API에 대해 다음 질문을 던져야 한다.

• 요청 객체가 실제 사용자 소유인가?
• 다른 ID를 넣었을 때 403이 반환되는가?

테스트 예시:

GET /api/users/1002
Authorization: Bearer {1001번 사용자 토큰}

 

 

정상이라면 반드시

HTTP/1.1 403 Forbidden

 

 

이 반환되어야 한다.

 

② 최소 권한 원칙이 적용되어 있는가

• 일반 사용자 토큰으로 관리자 API 호출이 가능한가?
• 서비스 계정이 과도한 권한을 가지고 있지는 않은가?
• scope 값이 실제 코드에서 검증되고 있는가?

권한은 “편의성”이 아니라 “제한” 중심으로 설계해야 한다.

③ 내부 API도 동일한 기준으로 보호하는가

• 내부망 API에 인증·인가 검증이 있는가?
• 서비스 간 호출에도 권한 범위 제한이 있는가?
• 내부 API를 외부와 동일한 보안 기준으로 점검하는가?

내부라는 이유로 면제되는 API는 없어야 한다.

④ 대량 호출과 남용(Abuse)을 탐지하는가

• 동일 토큰으로 단시간 반복 호출 시 탐지되는가?
• 객체 ID 순차 호출 패턴을 모니터링하는가?
• 단순 Rate Limiting을 넘어 이상행위 분석이 있는가?

정상 로그인 이후의 비정상 행위를 식별해야 한다.

⑤ 로그는 남기고 있는가, 분석하고 있는가

• 사용자 ID + 요청 객체 ID가 함께 로그에 남는가?
• 403 응답이 반복되는 계정을 탐지하는가?
• 관리자 API 호출 이력이 별도로 모니터링되는가?

로그는 저장만 하는 것이 아니라
행위 분석의 기반이 되어야 한다.

핵심 정리

API 보안 점검의 출발점은 다음이다.

• 인증 이후 권한 검증이 있는가
• 최소 권한이 적용되어 있는가
• 내부 API까지 통제하고 있는가
• 남용을 탐지할 수 있는가
• 로그를 분석하고 있는가

이 다섯 가지만 점검해도
대부분의 API 기반 사고는 사전에 차단할 수 있다.

7. 결론: API 보안은 장비가 아니라 설계의 문제다

많은 기업이 API 사고 이후 가장 먼저 하는 일은
보안 장비를 추가 도입하는 것이다.

• API Gateway 강화
• WAF 정책 추가
• 인증 체계 업그레이드

물론 필요하다.
하지만 사고의 원인은 대부분 장비 부족이 아니다.

문제는 설계 단계에서 빠진 한 가지 질문이다.

“이 사용자가 이 데이터에 접근해도 되는가?”

API는 데이터 중심 구조다.
그리고 데이터 접근 권한은 네트워크 장비가 아니라
애플리케이션 로직 안에서 결정된다.

로그인은 시작일 뿐이다

API 사고의 대부분은
인증 우회가 아니라 정상 로그인 이후에 발생한다.

• 토큰은 정상
• 암호화도 정상
• 요청 형식도 정상

그럼에도 데이터가 유출된다면
그 원인은 인가 설계에 있다.

API 시대의 보안 관점 전환

과거 보안은
“외부 침입을 막는 것”이 중심이었다.

지금은 다르다.

• 내부 사용자도 위협이 될 수 있고
• 정상 계정도 남용될 수 있으며
• 자동화 도구는 대량 수집을 가능하게 한다

API 보안의 핵심은
누가 들어오는지를 확인하는 것이 아니라
어디까지 허용할 것인가를 통제하는 것이다.

최종 정리

• 인증은 입장권이다.
• 인가는 접근 범위 통제다.
• Gateway는 필요하지만 충분하지 않다.
• 사고는 설계 단계에서 시작된다.

API 보안은 장비 경쟁이 아니다.
권한을 얼마나 정교하게 설계했는가의 문제다.

그리고 그 설계는
코드 한 줄에서 결정된다.