API 보안 위험과 과제

F5 에코시스템 | 2025년 7월 21일

API는 서로 다른 애플리케이션이 다른 애플리케이션, 서비스 및 플랫폼과 통신하고 데이터를 교환할 수 있도록 해주는 연결 고리입니다. 조직은 API를 통해 외부 플랫폼 및 타사 서비스를 손쉽게 통합하고, 다양한 구성 요소를 연결하여 종합적인 솔루션을 구축할 수 있습니다. API는 분산 환경 전반에서 애플리케이션과 데이터를 이어주는 연결망 역할을 하므로 현대 디지털 인프라에서 그 중요성이 점점 더 커지고 있습니다.

예를 들어 여행 서비스 웹 애플리케이션에서는 항공권 및 호텔 예약, 렌터카, 여행지의 기온과 일기 예보를 제공할 수 있습니다. 하지만 이러한 항공편, 날씨, 렌터카 관련 데이터가 모두 여행 애플리케이션 자체에 저장되는 것은 아닙니다. 대신 웹 앱은 항공사, 렌터카 업체, 기상 정보 제공업체가 공개한 API를 통해 끊임없이 변하는 실시간 정보를 요청합니다. 여행 앱은 해당 데이터를 내부에 저장하거나 관리하지 않고도 사용자가 이용할 수 있도록 표시하므로, 훨씬 더 다양하고 풍부한 선택지를 원활하게 제공할 수 있습니다.

““API의 보편화는 조직의 공격 표면을 확대해 보안 위험을 초래하며, API를 해커들의 주요 표적으로 만듭니다.””

이 블로그 게시물에서는 API가 현대적인 웹 애플리케이션 개발에서 널리 사용되는 필수 요소가 된 이유를 살펴보고, API로 인해 발생하는 과제와 보안 위험, 가장 일반적인 API 취약점을 다룹니다. 또한 API를 보호하는 데 가장 효과적인 전략에 대한 조언도 제공합니다.

API의 부상

API가 현대적인 앱 개발에서 왜 그토록 중요한지 이해하려면, 과거의 애플리케이션 구축 방식과 오늘날의 설계 방식을 비교해 보는 것이 도움이 됩니다. 기존 웹 애플리케이션은 수천 줄의 긴밀하게 얽힌 ‘스파게티 코드’로 구성된 모놀리식 구조인 경우가 많았습니다. 애플리케이션을 업데이트하거나 변경할 때마다 코드의 상당 부분을 수정해야 하므로 개발 속도가 느려지고 복잡성이 커지며 오류가 발생할 가능성도 높아집니다.

반면, 최신 웹 애플리케이션은 일반적으로 API를 통해 서로 통신하거나 웹 또는 모바일 애플리케이션 프런트엔드와 통신하는 독립적인 모듈식 구성 요소, 즉 마이크로서비스로 이루어집니다. 각 구성 요소는 개별적으로 개발, 배포 및 확장할 수 있으며, 개발자는 모든 것을 처음부터 구축하는 대신 사내 팀이나 타사 제공업체의 기존 서비스를 재사용할 수 있습니다. API는 애플리케이션 개발 주기를 간소화하고 단축하여 사용자 피드백을 바탕으로 더 빠르게 개선하고, 타사 서비스를 통합하며, 관리하기 쉬우면서 확장성이 뛰어난 애플리케이션을 구축할 수 있게 해줍니다.

API는 현대적인 앱 개발의 근간을 이루는 핵심 요소이므로, 점점 더 많은 조직이 API 우선 접근 방식을 채택해 API부터 애플리케이션 설계를 시작하고 있습니다. 이로 인해 API가 급증했습니다. 현재 조직당 평균 400개 이상의 API를 관리하고 있으며, 조직의 68%는 API를 사용해 앱 제공 및 보안을 관리합니다.

API 보안 위험

하지만 API가 널리 사용되면서 조직의 공격 표면이 확대되어 보안 위험이 커지고, API는 해커의 주요 표적이 됩니다. API는 핵심 비즈니스 로직뿐 아니라 사용자 자격 증명, 개인 식별 정보(PII), 금융 데이터, 인증 자격 증명, 결제 처리와 같은 비즈니스 운영 등 민감한 정보를 의도적으로 또는 의도치 않게 노출하는 경우가 많습니다.

또한 API는 제대로 관리되지 않는 경우가 많습니다. API 보안은 모든 조직의 애플리케이션 보안 전략에서 핵심적인 요소이지만, 많은 조직의 보안 팀은 계속 늘어나는 API 자산을 완전히 파악하고 통제하지 못하고 있습니다. 이로 인해 API 인벤토리가 부실하게 관리되고, 배포되었지만 문서화되거나 관리되지 않는 미확인 ‘섀도’ API 또는 오래되어 지원이 중단된 API가 생겨 공격자가 쉽게 침투할 수 있는 경로가 만들어질 수 있습니다. F5 2025 애플리케이션 전략 현황 보고서에 따르면, 조직의 58%가 API 난립을 심각한 문제로 꼽았습니다.

또한 많은 조직이 API 보안을 위해 충분하지 않은 도구에 의존하고 있습니다. API 게이트웨이와 웹 애플리케이션 방화벽(WAF)은 API 트래픽을 관리하고 보호하는 데 필수적이지만, 오늘날과 같이 복잡한 분산 환경에서 발생하는 광범위한 API 보안 위험을 해결하기에는 이것만으로 충분하지 않습니다.

API 보안 위험은 디지털 인프라에 대한 기술적 위협을 넘어 비즈니스에도 중대한 영향을 미칩니다. API 공격은 침해 사고 대응 비용, 법적 조치, 규제 벌금뿐만 아니라 유료 서비스의 과도한 사용, 사기 또는 도난으로 인한 직접적인 손실까지 초래할 수 있습니다. 공격으로 인해 애플리케이션 전체의 성능이 저하되거나 작동이 중단될 수 있고, 핵심 서비스가 표적이 되어 사용자 경험에 부정적인 영향을 미치며 보안 및 운영 팀이 긴급 대응에 나서야 할 수도 있으므로 운영 중단 역시 위험 요소입니다. 민감한 사용자 데이터가 노출되거나 API 악용으로 인한 성능 문제가 반복되면 고객의 신뢰가 약화되고 평판에 장기적인 피해를 입을 수 있습니다.

API 보안의 7가지 주요 취약점

다음은 가장 일반적인 7가지 API 보안 취약점입니다:

1. 인증 및 권한 부여. 10가지 OWASP API 보안 위험 중 4가지는 다음과 같은 인증 및 권한 부여 취약점입니다. 객체 수준 권한 부여 취약점, 인증 취약점, 객체 속성 수준 권한 부여 취약점, 그리고 기능 수준 권한 부여 취약점.

이러한 위협은 공격자가 정상적인 사용자를 사칭하여 객체 참조를 조작하거나, 악의적으로 함수를 실행해 민감한 정보를 변경하거나 이에 대한 액세스 권한을 획득할 때 발생합니다. 이러한 취약점으로부터 보호하려면 적절한 액세스 제어와 함께 OAuth 또는 JSON 웹 토큰(JWT)과 같은 강력한 인증 및 권한 부여 메커니즘을 구현해야 합니다.

2. 비즈니스 흐름에 대한 무제한 액세스.

이러한 공격의 위험성은 공격자가 정상적인 비즈니스 흐름을 악의적으로 악용한다는 데 있습니다. 이러한 공격은 정상적인 활동처럼 보일 수 있고 잘못된 구성으로 인해 발생하는 것도 아니므로 방어하기가 어려울 수 있습니다. 이러한 공격을 탐지하려면 사람이 할 수 있는 속도보다 빠르게 여러 기능에 액세스하는 경우와 같은 자동화된 사용 패턴을 식별할 수 있도록 행동 분석을 배포하거나, 비즈니스 로직 흐름을 이해하고 추적하는 런타임 보호 기능을 구현하세요.

3. 인젝션 공격 이러한 취약점은 공격자가 백엔드 시스템의 입력 처리 방식을 조작할 목적으로 API 요청에 악성 데이터나 명령을 포함해 전송할 때 발생합니다. 일반적인 인젝션 공격에는 SQL 인젝션, 크로스 사이트 스크립팅, 또는 서버 측 요청 위조(SSRF)가 있습니다.

인젝션 공격은 API를 조작하여 데이터베이스, 검색 엔진, 운영 체제 명령과 같은 백엔드 서비스에 악성 입력을 전달하게 만들 수 있으므로 심각한 위험을 초래합니다. 이러한 백엔드 서비스는 해당 입력을 정상적인 명령으로 해석할 수 있습니다. 그 결과 데이터 유출, 무단 액세스 또는 의도하지 않은 기능 실행이 발생할 수 있습니다. 이러한 위험을 완화하려면 강력한 입력값 검증 및 정제 방식을 구현하여 API가 안전하고 예상된 형식에 맞게 올바르게 구성된 데이터만 처리하도록 해야 합니다.

4. 무제한 리소스 소비. 이는 일련의 API 요청으로 인해 네트워크 대역폭, CPU, 메모리 또는 스토리지와 같은 리소스에 과부하가 발생할 때 나타납니다. 리소스 고갈이라고도 하는 이러한 공격은 서비스 거부(DoS),로 이어져 API 또는 기반 시스템의 성능이나 가용성을 저하시키고 서비스 중단을 초래할 수 있습니다.

이러한 유형의 공격은 핵심 서비스나 애플리케이션 전체를 중단시켜 운영에 심각한 영향을 미칠 수 있으며, 특히 API 서비스가 요청 건별로 과금되는 경우 과도한 인프라 및 운영 비용을 초래할 수 있습니다. 이러한 위험을 완화하려면 속도 제한을 구현하여 정해진 시간 간격 동안의 API 요청량을 제어하고, 요청 매개변수와 파일 업로드에 최대 크기 제한을 적용하며, 사용량 기반 과금 API 서비스에 지출 한도를 설정해야 합니다.

5. 보안 구성 오류.공격자는 패치되지 않은 취약점, 안전하지 않은 기본 구성으로 실행되는 서비스 또는 보호되지 않은 파일과 디렉터리를 찾아 API에 무단으로 액세스하려고 시도합니다. 이러한 공격은 전송 계층 보안(TLS)이나 교차 출처 리소스 공유(CORS) 정책과 같은 보안 제어가 잘못 구현되었거나 전혀 구현되지 않은 경우 또는 불필요한 기능이 활성화된 경우에 발생할 수 있습니다.

여기서 위험은 공격자가 자동화 도구를 사용하여 흔히 발생하는 잘못된 구성을 식별하고 악용함으로써 서비스와 민감한 데이터에 접근할 수 있다는 데 있습니다. 최신 아키텍처가 점점 더 분산화되고 멀티클라우드 환경 전반에 분산됨에 따라 이러한 위험은 더욱 커집니다. 이러한 위협을 방어하려면 조직은 API 개발 수명 주기 전반에 보안을 내재화하고 TLS 암호화를 비롯한 강력한 보안 정책을 시행해야 합니다. 또한 자동화된 보안 테스트 도구를 활용하고 정기적으로 API 보안 감사를 수행하여 취약점을 선제적으로 식별하고 해결해야 합니다.

6. 부적절한 인벤토리 관리. 조직이 API 자산을 완전히 파악하지 못하거나 최신 상태로 유지하지 않을 때 발생합니다. API는 시간이 지남에 따라 변경되고 업데이트되지만, 오래되었거나 안전하지 않은 API 버전이 운영 환경에 남아 있을 수 있습니다. 또한 이전 엔드포인트가 패치되지 않은 채로 실행되거나 취약한 보안 요구 사항이 적용되어 공격 및 악용 위험이 커질 수 있습니다.

적절한 API 인벤토리 관리가 이루어지지 않으면 해커가 패치되지 않은 이전 버전의 API나 제대로 보호되지 않은 섀도 API를 악용할 수 있어 위험합니다. 이러한 위험을 방지하려면 모든 API 엔드포인트의 최신 인벤토리를 유지하고, 사용하지 않는 API를 정기적으로 검토하여 폐기하며, 적절한 감독과 보안 통제하에 모든 API를 정기적으로 패치하고 업데이트해야 합니다.

7. 안전하지 않은 API 사용. 개발자는 서드 파티 API, 특히 잘 알려진 조직에서 제공하는 API를 통해 얻은 데이터를 암묵적으로 신뢰하는 경우가 많습니다. 그 결과 이러한 API의 데이터가 본질적으로 안전하다고 가정하여 입력값 검증, 데이터 정제, 전송 계층 보호 등의 보안 조치를 덜 엄격하게 적용할 수 있습니다. 외부 API가 침해되거나 예상과 다르게 작동할 경우 심각한 보안 취약점이 발생할 수 있습니다.

통합된 서드 파티 API의 보안을 신뢰하는 것은 상당한 위험을 초래합니다. 공격자는 이러한 종속성을 파악하고 취약한 API 보호 체계를 악용하여 악성 요청을 전송할 수 있으며, 이로 인해 승인되지 않은 URL 리디렉션, 도청, 데이터 가로채기 또는 민감한 정보에 대한 접근이 발생할 수 있습니다. 이러한 위협을 완화하려면 항상 암호화된 채널을 통해 서드 파티 서비스와 통신하고, 모든 수신 및 발신 데이터를 철저히 검증하고 정제하며, URL 리디렉션을 무조건 따르지 말고, 외부 서비스와의 상호 작용 범위와 빈도를 엄격하게 제한해야 합니다.

API 보안의 과제를 극복하세요

강력한 API 보안을 구현하려면 다음 모범 사례를 따르세요:

  • 강력한 액세스 제어, 인증 및 권한 부여를 사용하세요. 다음과 같은 강력한 인증을 결합한 액세스 제어 메커니즘은 OAuth 또는 JSON 웹 토큰(JWT), 세분화된 권한 부여와 함께 민감한 데이터나 기능에 대한 무단 액세스를 방지하는 데 매우 중요합니다. 이러한 모범 사례는 각 사용자, 애플리케이션 또는 시스템에 해당 기능을 수행하는 데 필요한 최소한의 액세스 권한과 사용 권한만 부여하고 그 이상은 허용하지 않는 최소 권한 원칙을 적용하는 데도 도움이 됩니다.
  • 모든 클라이언트 입력을 철저히 검증하세요. Content-Type 헤더가 올바른지 확인하고, 엄격한 스키마 검증을 적용하며, 각 엔드포인트에 명시적으로 정의된 HTTP 메서드만 허용하세요. 이렇게 하면 입력이 스키마 또는 검증 규칙을 준수하도록 보장하고, 공격자가 지원되지 않는 메서드를 사용해 논리적 결함을 악용하거나 통제를 우회하려는 콘텐츠 스푸핑 및 메서드 변조를 방지할 수 있습니다.
  • 모든 단계에서 민감한 데이터를 보호하려면 종단 간 암호화를 사용하세요. TLS를 사용하여 전송 중인 데이터를 보호하고, 민감한 필드에는 필드 수준 암호화를 적용하는 등 강력한 암호화 표준을 사용하여 저장된 데이터를 보호하세요. 클라이언트와 서버 간에 교환되는 모든 데이터를 암호화하면 중간자 공격, 도청 및 데이터 변조를 방지할 수 있으며, 저장된 데이터를 암호화하면 시스템이 침해되더라도 데이터베이스, 로그 또는 백업에 저장된 민감한 데이터를 보호할 수 있습니다.
  • 데이터 노출을 제한하세요. API 응답에는 클라이언트의 작업에 필요한 데이터만 포함하고, 시스템 또는 보안 세부 정보가 유출되지 않도록 오류 메시지를 정제하여 정보 유출 및 공격자의 사전 정찰 위험을 최소화하세요.
  • 지속적인 보안 테스트를 수행하세요. 개발 및 배포 과정에서 API의 취약점을 검사할 수 있도록 자동화 도구를 통합하고, 정기적인 보안 감사와 수동 검토를 병행하세요. 이를 통해 위험을 조기에 탐지하고 해결하여 API의 전체 수명 주기 동안 보안을 유지하고 프로덕션 환경에서 취약점이 노출되는 것을 최소화할 수 있습니다.
  • API 사용량을 모니터링하세요 지속적으로. 신규 또는 관리되지 않는 API를 탐지할 수 있도록 API 검색 도구를 구현하여 API 에코시스템에 대한 가시성을 확보하세요. 실시간 위협 탐지 및 보고를 위해 모든 API 트래픽을 기록하여 감사, 이상 징후 탐지 및 규정 준수에 활용하세요.
  • API 거버넌스 정책을 구현하세요. 안전하고 일관되며 품질 높은 API 개발 및 관리를 위해 조직 전반에 적용되는 표준을 정의하고 시행하세요. 거버넌스에는 인증, 데이터 보호, 수명 주기 관리, 문서화, 보안 태세 및 규정 준수가 포함되어야 하며, 이를 통해 API가 설계 단계부터 안전하고 대규모 환경에서도 관리 가능하도록 해야 합니다.

API 보안을 강화하기 위한 실용적인 지침은 블로그 게시물 API 보안 체크리스트에서 더 자세히 확인하세요.

공유

관련 블로그 게시물

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5 에코시스템 | 2023. 07. 13.

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A

F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.

TLS 검사에서 피터 파커 원칙 다루기
F5 에코시스템 | 2019. 12. 09.

TLS 검사에서 피터 파커 원칙 다루기

“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.

Venafi와 F5를 통한 머신 아이덴티티 보호
F5 에코시스템 | 2018. 12. 11.

Venafi와 F5를 통한 머신 아이덴티티 보호

‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
F5 에코시스템 | 2018. 07. 23.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다

물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...

내 클라우드에서 나가!
F5 에코시스템 | 2016. 10. 12.

내 클라우드에서 나가!

F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.

Shift(웹 앱) 보안 레터
F5 에코시스템 | 2015. 07. 06.

Shift(웹 앱) 보안 레터

웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.