대부분의 API 침해는 해킹이 아니라, 그냥 들어옵니다
Source: Dev.to
일반적인 오해
대부분의 개발자는 API 침해를 극적인 사건—암호가 깨지고, 비밀이 탈취되고, 무차별 대입 공격이 일어나는 상황—으로 상상합니다. 인증이 제대로 작동한다면 API는 안전하다는 위안이 되는 믿음이 있습니다.
API 침해의 실제
실제로 대부분의 API 사고는 유효한 토큰, 올바른 헤더, 그리고 기대된 흐름을 포함합니다. 공격자는 시스템과 싸우는 것이 아니라, 시스템과 협력하고 있는 것입니다.
API의 신뢰 계층
API는 여러 신뢰 계층 위에 구축됩니다:
- Identity provider – 사용자를 인증하는 소스를 신뢰합니다.
- Token – 클라이언트가 제시한 토큰을 신뢰합니다.
- User behavior – 권한이 부여된 사용자가 합리적으로 행동할 것이라고 가정합니다.
마지막 가정이 무너지는 지점입니다. API는 의도가 아니라 규칙을 평가합니다. 요청이 정의된 규칙에 부합하면, 데이터가 왜 요청되었는지, 얼마나 자주 요청되었는지, 접근 패턴이 타당한지와 관계없이 통과합니다. 이러한 고려사항은 명시적으로 강제되지 않으면 인간의 추측에 불과합니다.
전형적인 사후 분석 결과
침해 분석은 종종 “지루한” 결과를 보여줍니다:
- 사용자는 자신이 볼 권한이 있던 데이터를 접근했습니다.
- 레이트 리밋이 작동하지 않았습니다.
- 인증 실패가 발생하지 않았습니다.
- 그 외 모든 것이 기대대로 동작했습니다.
실수는 HTTPS나 OAuth가 누락된 것이 아니라, 인증이 안전과 동일하다고 믿은 것이었습니다. 인증은 누구인지만 답하고, 왜, 범위, 빈도, 영향에 대해서는 전혀 말해주지 않습니다.
설계 실패와 관대형 시스템
시니어 엔지니어들은 보안 실패가 설계 실패에서 비롯되는 경우가 많다는 것을 배웁니다. 시스템은 기본적으로 관대(permissive)하게 설계되고, 제한적(restrictive)인 것은 이론상에 불과합니다. API가 행동을 이해하기보다 토큰을 더 신뢰한다면, 그것은 안전한 것이 아니라 단지 공손한 것입니다. 그리고 공손함은 규모가 커질수록 비용이 많이 듭니다.
결론
보안은 외부 공격자를 차단하는 것만이 아니라, 신뢰된 엔티티가 어떻게 행동해야 하는지에 대한 올바른 기대치를 정의하고 강제하는 것입니다. 견고한 API를 구축하려면 인증‑만족 사고방식에서 벗어나, 의도, 빈도, 영향 등을 적극적으로 모니터링하고 설계해야 합니다.