대부분의 팀은 API 보안을 인증 문제로 다룹니다. 토큰을 발급하고, 모든 경로에서 그것을 검사하고, 할 일은 끝났다고 생각합니다. 그러다 어느 날 테스터가 URL의 숫자 하나를 바꾸고 다른 고객의 청구서를 읽어냅니다.

인증된 상태와 인가된 상태 사이의 그 틈이 실제 API 침해의 대부분이 살고 있는 곳이며, 스캐너가 안정적으로 찾아내는 종류의 문제도 아닙니다. 자동화 도구는 유효한 토큰과 200 응답을 보고 성공이라고 보고합니다. 그 응답 안에 남의 데이터가 들어 있었다는 사실은, 여러분의 업무 규칙을 이해하는 사람만 알아차립니다.

핵심 구분: 인증은 누가 호출하는지를 증명합니다. 인가는 그 호출자가 무엇을 보고 무엇을 바꿀 수 있는지를 결정하며, 모든 객체에 대해, 모든 요청마다, 데이터 계층에서 강제되어야 합니다. 심각한 API 취약점은 거의 언제나 앞의 것이 완벽하게 작동하는 동안 뒤의 것이 실패해서 생깁니다.

객체 수준 인가 실패가 압도적으로 많은 이유

가장 흔한 심각한 API 결함은 설명하기에는 가장 단순한 것이기도 합니다.

엔드포인트는 /api/invoices/48213 입니다. 호출자는 인증되어 있으므로 핸들러는 청구서 48213을 가져와 반환합니다. 그 청구서가 정말 이 호출자의 것인지는 아무도 확인하지 않습니다. 숫자를 바꾸면 남의 청구서가 나옵니다. API는 작성된 대로 정확히 동작했고, 잘못된 것은 작성 방식이었습니다.

이 실패는 여러분에게 불리한 방향으로, 공격자에게 유리한 방향으로 규모가 커집니다. 순차적인 식별자가 있으면 반복문 하나로 데이터셋 전체를 열거할 수 있습니다. 추측하기 어려운 식별자로 바꾸는 것은 조금 도움이 되지만 해결책은 아닙니다. 식별자는 다른 엔드포인트, 내보내기 파일, 안내 메일을 통해 계속 새어 나가기 때문입니다.

해결은 우연이 아니라 구조여야 합니다. 소유권은 쿼리 자체에서 확인해야 합니다. 즉 이 고객에게 속한, 이 식별자의 청구서를 가져오는 것이지, 청구서를 먼저 가져온 뒤 나중에 무엇인가가 확인해 주기를 바라는 것이 아닙니다. 그리고 그 강제를 데이터 접근 계층에 두십시오. 여섯 달 뒤에 이 문단을 한 번도 읽어 본 적 없는 누군가가 새 컨트롤러를 작성할 때에도 잊어버릴 수 없게 됩니다.

같은 실패는 객체뿐 아니라 기능에도 적용됩니다. 관리자용 엔드포인트가 일반 사용자 화면에서 링크되지 않는다는 사실만으로 보호되고 있다면, 그것은 전혀 보호되고 있지 않은 것입니다.

실제로 지적되는 API 보안 결함

인가를 빼면 몇 가지 문제가 지적 사항의 대부분을 차지합니다. 여기서 표준 참고 자료는 OWASP API Security Top 10이며, OWASP는 이를 주기적으로 개정하므로 요약본이 아니라 현재 판을 확인하십시오.

화면이 보여 주는 것보다 더 많이 반환하기. 그렇게 하는 편이 편했다는 이유로 엔드포인트가 사용자 객체 전체를 반환하고, 프런트엔드는 그중 세 개의 필드만 표시합니다. 나머지 열두 개, 이를테면 비밀번호 재설정 토큰과 내부 위험 점수는 여전히 응답 안에 남아 있습니다. 네트워크 탭을 열어 본 사람은 누구나 그것을 가져갑니다. 직렬화는 의도적으로 하십시오. 모델을 그대로 쏟아 내지 말고, 이름을 지정한 필드로 응답을 구성해야 합니다.

들어오는 쪽의 대량 할당. 정확히 그 거울상입니다. 프로필 수정 엔드포인트가 도착한 필드를 무엇이든 받아 레코드에 기록하기 때문에, 호출자가 "role": "admin" 을 덧붙여 스스로를 승격시킵니다. 요청 본문을 통째로 받아들이지 말고, 허용된 필드 목록에 명시적으로 바인딩하십시오.

소비량에 제한이 없음. 제한이 없으면 한 호출자가 페이지당 백만 건을 요청하고, 비싼 검색을 반복문으로 돌리고, 비밀번호 재설정을 수천 건 발생시킬 수 있습니다. 이것은 서비스 거부만의 문제가 아닙니다. 엔드포인트 뒤에 언어 모델이 있는 경우처럼 요청 하나하나가 비용을 발생시킨다면, 이것은 과금에 대한 공격입니다. 속도 제한은 소비자별로, 엔드포인트별로 두어야 하며, 비싼 작업은 싼 작업보다 더 촘촘하게 조여야 합니다.

자산 목록과 외부 시스템에 대한 신뢰

문서화되지 않은, 잊힌 엔드포인트. 버전 2는 운영 중이고 문서도 있는데, 버전 1이 예전 인가 로직 그대로 계속 돌아가고 있고, 운영 데이터를 가진 스테이징 API가 인터넷에서 접근 가능합니다. 공격자는 정확히 이런 것을 찾습니다. 배포된 모든 API, 모든 버전, 모든 환경의 목록을 유지하고, 방치가 아니라 의도적으로 폐기하십시오.

호출하는 시스템을 믿는 것. 여러분의 API는 다른 API를 소비하고, 그 응답은 여러분의 데이터베이스와 화면 렌더링으로 흘러 들어옵니다. 파트너라서 안전하다고 가정하지 말고, 돌아온 것을 검증하십시오. 신뢰하는 상대의 장애나 사양 변경이 그대로 여러분 쪽의 결함으로 드러나는 일은 드물지 않습니다. 같은 관계의 신뢰성 측면은 서드파티 API 연동 안내에서 다룹니다.

인증을 제대로 하기

인증은 대부분의 팀이 대체로 맞게 하고 있는 부분이므로, 여기서는 그것을 무너뜨리는 세부 사항을 다룹니다.

만료되지 않는 장수명 키 대신, 갱신이 가능한 짧은 수명의 액세스 토큰을 사용하십시오. 영원히 유효한 자격 증명이 유출되면 그것은 영구적인 침해입니다. 십오 분 뒤 만료되는 것이 유출되면 끝이 정해진 사고일 뿐입니다.

토큰의 범위를 좁게 지정하십시오. 리포팅 연동에 발급된 토큰으로 사용자를 생성할 수 있어서는 안 됩니다. 스코프가 있으면 각 핸들러의 검사에 기대지 않고 중앙에서 그것을 강제할 수 있습니다.

토큰 검증을 제대로 하십시오. 이는 대부분의 경우 토큰이 스스로 주장하는 알고리즘을 받아들이지 않는다는 뜻입니다. 기대하는 서명 알고리즘을 고정하고, 발급자와 대상을 확인하고, 만료를 검사하십시오. 이것을 기본값으로 처리해 주는 라이브러리가 있습니다. 실수가 사는 곳은 직접 손으로 만든 검증 쪽입니다.

자격 증명은 일정에 따라 교체하고, 소비자가 중단 없이 교체할 수 있는 방법을 제공하십시오. 보통은 전환 기간 동안 두 개의 키를 동시에 유효하게 두는 방식입니다. 교체가 장애를 일으킨다면 아무도 교체하지 않게 됩니다.

마지막으로, 자격 증명을 절대 URL에 넣지 마십시오. 쿼리 문자열은 서버 로그, 브라우저 기록, 프록시 로그, 리퍼러 헤더에 남습니다. 헤더를 사용하십시오.

침투 테스트가 실제로 찾아내는 것

자동 스캔과 수동 테스트는 서로 다른 것을 찾아내며, 서로 다른 이유로 둘 다 필요합니다.

스캐너는 알려진 취약한 의존성, 빠진 보안 헤더, TLS 설정 오류, 명백한 인젝션을 찾는 데 능합니다. 값이 싸고 회귀를 잡아 주므로 파이프라인 안에서 계속 돌리십시오.

스캐너가 할 수 없는 일은 여러분의 비즈니스를 이해하는 것입니다. 할인 코드 엔드포인트를 반복 호출하면 할인이 중첩된다는 것, 유료 기능이 무료 요금제에서 API를 직접 호출하는 것만으로 접근된다는 것, 출고 이후에 주문을 취소하면 재고 확인 없이 환불이 실행된다는 것. 실제로 돈이 나가는 발견은 이런 것들이고, 이런 것들은 그 API가 무엇을 위한 것인지 이해하는 사람이 있을 때에만 드러납니다.

특히 API라면 역할을 가로지르는 인가 테스트를 포함해 달라고 요청하십시오. 즉 테스터가 서로 다른 두 고객의 자격 증명을 들고, 한쪽 토큰으로 다른 쪽 계정의 데이터에 도달할 수 있는지를 체계적으로 시도하는 것입니다. 이 한 가지 작업이 나머지 전부를 합친 것보다 더 많은 것을 찾아냅니다. 침투 테스트의 종류 를 정리한 글은 테스터에게 어느 정도의 접근 권한을 줘야 하는지를 설명하며, 문서와 자격 증명을 제공하는 편이 아무 정보 없는 테스트보다 훨씬 나은 결과를 냅니다.

예산 이야기를 하면, API 중심 테스트는 보통 잘 문서화된 작은 API에서 약 £3,000부터, 역할과 연동이 여러 개인 큰 표면에서는 £15,000 이상까지 갑니다. 침투 테스트 비용 가이드 가 이 범위를 움직이는 요인을 분해해서 보여 줍니다.

조사할 수 있을 만큼 기록하기

사고와 재앙을 가르는 것은 대개 무슨 일이 있었는지를 나중에 재구성할 수 있는가입니다.

인증 이벤트, 인가 실패, 그리고 상태를 바꾸는 모든 작업을 호출자 신원, 대상 객체, 상관 식별자와 함께 기록하십시오. 특히 인가 실패는 조기 경보입니다. 정상적인 연동은 이것을 거의 만들지 않으므로, 한꺼번에 몰려 나온다면 누군가 찔러 보고 있는 것입니다.

민감한 값 자체는 기록하지 마십시오. 토큰, 카드 정보, 개인 정보가 로그 파일에 들어가는 순간, 봉쇄되어 있던 침해가 신고 대상 침해로 바뀝니다.

경보는 양이 아니라 패턴에 대해 울리십시오. 한 호출자가 여러 객체 식별자에 걸쳐 인가 실패를 만들어 내고 있다면 그것은 열거가 진행 중이라는 뜻이고, 사람을 깨울 가치가 있습니다. 전체 오류율은 그렇지 않습니다.

보관 기간은 쓸모 있을 만큼 길게 잡으십시오. 침해는 시작된 지 몇 주 뒤에 발견되는 경우가 많고, 삼십 일치 로그로는 침입 경로를 찾기에 너무 짧을 때가 많습니다.

실제로 배포한 API를 테스트하십시오

Mecanik은 애플리케이션 보안 테스트 를 제공하며, 자동화 도구가 놓치는 인가와 비즈니스 로직 결함에 초점을 맞춥니다. 여기에는 여러 역할의 실제 자격 증명을 사용한 계정 간 교차 테스트도 포함됩니다.

우리는 표면을 추측하는 대신 여러분의 명세와 문서를 가지고 작업하며, 그 부산물로 문서화되지 않은 엔드포인트와 버전 잔재가 드러납니다. 작업이 인프라와 네트워크 테스트까지 확장된다면 침투 테스트 서비스 가 그 영역을 다룹니다. 아직 API를 설계하는 중이라면 맞춤형 API 개발 비용 안내가 인가와 속도 제한과 로깅을 나중에 덧붙이지 않고 구축 과정의 어디에 두어야 하는지 짚어 줍니다.

명세와 역할 설명을 보내 주시면 위험이 어디에 몰려 있는지 알려 드리겠습니다.

관련 게시물: 영국의 침투 테스트 - 2026년에 기대할 수 있는 것 , 2026년 영국 개발자를 위한 GDPR 기술 준수 , Cloudflare Zero Trust: 엔터프라이즈 액세스 보안 가이드 , 사업주를 위한 OWASP Top 10 쉬운 설명 .

자주 묻는 질문

가장 흔한 API 보안 취약점은 무엇인가요? 객체 수준 인가 실패입니다. 인증된 호출자가 요청 안의 식별자만 바꿔서 다른 사용자의 데이터에 도달할 수 있는 상태를 말합니다. 인증 자체는 정상적으로 작동하지만 요청된 객체가 그 호출자의 것인지는 아무도 검증하지 않습니다. 따라서 소유권은 쿼리 안에서 강제해야 합니다.

API 키만으로 충분한 보안이 되나요? 그것만으로는 부족합니다. 만료되지 않는 장수명 키는 한 번의 유출을 영구적인 침해로 만듭니다. 갱신이 가능한 짧은 수명의 액세스 토큰을 사용하고, 소비자가 실제로 필요한 범위로 스코프를 좁히고, 중단 없는 교체를 지원하며, URL이 아니라 항상 헤더로 전송하십시오.

자동 스캔만으로 API를 지킬 수 있나요? 지킬 수 없지만 계속 돌릴 가치는 있습니다. 스캐너는 알려진 취약한 의존성, 빠진 헤더, 명백한 인젝션을 찾아냅니다. 다만 업무 규칙을 이해하지는 못하므로 할인 중첩, 무료 요금제에서 접근되는 유료 기능, 계정을 넘나드는 데이터 접근은 놓칩니다.

API 침투 테스트 비용은 얼마인가요? 잘 문서화된 작은 API의 경우 보통 약 £3,000부터, 역할과 연동이 여러 개인 큰 표면은 £15,000 이상까지 갑니다. 비용을 좌우하는 것은 엔드포인트 수, 서로 다른 역할의 수, 그리고 문서와 자격 증명이 제공되는지 여부입니다.

보안을 위해 API는 무엇을 기록해야 하나요? 인증 이벤트, 인가 실패, 그리고 상태를 바꾸는 모든 작업을 호출자 신원, 대상 객체, 상관 식별자와 함께 기록해야 합니다. 토큰이나 개인 정보는 절대 기록하지 마십시오. 한 호출자가 여러 식별자에 걸쳐 인가 실패를 만들어 낸다면 열거의 신호이므로 경보를 울려야 합니다.