WAF가 정상인데 쿠폰과 재고가 새는 이유: 자동화 봇의 업무 악용을 막는 기준

로그인에 성공한 계정도 업무를 남용할 수 있다

가상의 한정 판매입니다. 이벤트가 시작되자 상품이 빠르게 품절로 바뀝니다. 주문 수는 크게 늘지 않았는데 결제 대기 예약이 많고, 만료될 때마다 비슷한 묶음의 계정이 재고를 다시 점유합니다. 웹 방화벽이 차단한 공격 요청 수는 평소와 비슷합니다. 예약 API가 허용한 입력을 받았고, 각 계정의 요청 수도 아주 높지 않았기 때문입니다.

조사에는 시간대별 판매 완료 수, 가용 재고의 변화, 예약 수량과 유지 시간, 재점유까지 걸린 시간, 계정별 활성 예약 수를 함께 씁니다. 결제 오류가 많아 예약이 풀리지 않은 경우나 재고 화면이 늦게 갱신된 경우도 경쟁 가설입니다. 여러 계정이 같은 네트워크를 썼다는 사실만으로 자동화로 분류할 수는 없습니다. 기업과 학교, 공동주택, 모바일망의 사용자도 공인 IP를 공유하기 때문입니다.

OWASP API Security는 서버가 올바른 모양의 요청을 처리하고 있어도 민감한 업무 흐름으로 제한 없이 접근할 수 있으면 자동화된 악용이 생길 수 있다고 설명합니다. 먼저 어떤 흐름이 사업에서 민감한지 정의한 뒤, 그 흐름에 맞는 제한을 설계하도록 제안합니다. 요청 검증과 보안 계층별 책임은 API 보안 통제 비교에서도 다룹니다. OWASP API Security Top 10의 민감한 업무 흐름 항목^[1]

트래픽 차트에 없는 손실 단위

쿠폰 남용에서는 승인된 자격 없이 소진된 쿠폰 수 또는 할인액을 봅니다. 가입 남용에서는 지원팀의 검토 시간, 발송 비용, 정상 고객이 받지 못한 가입 혜택이 들어갑니다. 재고가 잠긴 경우에는 판매 가능했던 재고와 시간, 그 시간대의 정상 고객 구매 흐름을 함께 봅니다. 공개 조회 API는 호출처의 결과 행 수, 쿼리가 소비한 자원과 일시적으로 이용할 수 없었던 정상 요청을 함께 추적합니다.

‘예약이 100건 만료됐다’는 숫자만으로 손실 금액을 계산할 수 없습니다. 일부는 정상 구매자의 이탈이고 어떤 상품은 이후 다시 판매됩니다. 예약이 공급을 가렸던 시간으로 수량과 시간을 곱한 점유량을 기록하면 정책 전후를 비교할 수도 있습니다. 가상으로 상품 12개가 각각 5분 동안 예약되고 결제로 이어지지 않았다면 60개·분의 점유입니다. 실제로 잃은 판매액을 구하려면 당시 수요, 재입고, 뒤늦게 완료된 주문 등의 정보가 더 필요합니다.

자산별 통제 위치와 정상 사용 영향

표를 이용해 담당자가 자산을 하나 고르고, 그 자산의 최종 상태를 확정하는 서버를 찾습니다. 경계에서 걸러낼 수 있는 신호와 거래를 확정할 때 필요한 자격 조건을 함께 적습니다. 정상 사용의 피해 기준까지 합의하면 오탐으로 통제를 되돌릴 때도 근거가 남습니다.

같은 API에서 요청 한도를 걸더라도 제한할 단위를 둘 이상 둡니다. 로그인 전에는 IP 대역이나 연결 단위에서 과밀을 완화할 수도 있습니다. 로그인 후에는 계정과 캠페인별 신청 횟수, 사용자별 활성 예약 수, 상품 전체의 최대 점유량을 업무 서버에서 확인합니다. 계정 간 연계 신호는 보조 자료로 사용하고 근거가 약한 경우 허용 범위를 줄이거나 보류한 뒤 재확인합니다. 지역·브라우저 유형만으로 정상 여부를 정하면 여러 사용자 그룹에 불균형한 차단이 생길 수 있습니다. OWASP의 봇 방어 계층과 요청 한도 가이드^[2]

마지막 쿠폰과 마지막 재고는 서버가 결정한다

‘혜택을 쓸 수 있나요?’라는 조회와 실제 사용 확정의 시점이 다르면, 두 주문이 같은 답을 읽고 동시에 혜택을 쓸 수 있습니다. 자격 검증과 소비 기록 생성은 같은 일관성 경계 안에서 처리하는 편이 좋습니다. 한 캠페인에서 한 고객에게 한 번만 쓸 수 있는 혜택이라면 그 조건을 저장소에서 강제합니다. 여러 주문 채널이 동일한 혜택 원장을 확인하도록 하고 채널별로 독립적인 잔액을 두는 경우에는 정합성을 어떻게 보장할지 정합니다.

재고도 조회 화면에서 ‘1개 남음’을 보였다는 사실만으로 채울 수 없습니다. 예약 시점에 최신 재고 상태와 활성 예약 수를 확인하고 두 건이 같은 마지막 상품을 확정하지 않도록 합니다. 만료가 12시인 예약에 결제 완료가 늦게 들어오면 재고가 이미 다른 고객에게 넘어갔을 수 있습니다. 결제 완료 알림을 기다리는 구간, 예약 재확보 여부, 고객 안내와 환불·정정 책임을 미리 정합니다. 이런 판정은 앱과 웹에서 동일하게 적용하고 이전 앱 버전도 서버 조건을 우회할 수 없는지 점검합니다.

보안을 넣는 위치에도 실패 정책을 둡니다. 예를 들어 지표 저장소 장애 때문에 계정별 점유를 확인할 수 없는 경우, 읽기는 유지하고 새 고위험 예약은 잠시 보류할 수도 있습니다. 원장이 정상이고 신호 시스템만 느리다면 승인된 한도를 낮춰 운영할 수도 있습니다. 어느 판단이 가능한지는 해당 흐름에서 보호할 재고와 이미 약속한 고객 업무에 따라 달라집니다.

추가 확인은 사용자의 구매 경로를 보호해야 한다

가는 길이 막힌 사용자가 다음 행동을 알아야 합니다. 요청을 잠깐 늦출지, 쿠폰 사용을 보류할지, 로그인을 다시 확인할지, 지원 채널로 연결할지는 거래 피해와 확인 비용으로 정합니다. 위험 신호가 약하면 그대로 허용하면서 관측하고 확인 비용이 낮다면 거래를 보호할 새 인증 방법을 선택할 수도 있습니다. 수동 검토가 필요하면 자동 취소 전에 어느 정보를 언제까지 확인해야 하는지 담당자에게 전달합니다. 결제의 차단·추가 확인·수동 검토 기준은 보류의 결과까지 보는 사례를 제공합니다.

CAPTCHA를 선택할 때는 시각, 청각, 키보드, 보조기술과 저속 연결을 쓰는 이용자의 완료 경로를 시험합니다. W3C의 접근성 연구 문서는 사람과 자동화를 구분하는 상호작용이 장애가 있는 사용자를 배제할 수 있고, 여러 방식에 해결해야 할 접근성 문제가 남는다고 설명합니다. 다른 확인 방식을 제공한다면 동일한 업무를 완료할 수 있는지와 대체 수단의 이용 시간을 봅니다. 접근성 시험을 통과한 UI에서도 반복 확인과 잦은 세션 만료가 실제 구매를 방해할 수도 있습니다. W3C의 CAPTCHA 접근성 검토^[3]

가상의 판매에서는 활성 예약 한도를 낮추기 전에 단체 구매를 별도 경로로 보냅니다. 일반 고객에게 예약 만료 시각과 결제 상태를 보여주고, 접근성이 확보된 확인 방법을 둡니다. 통제 발동에 쓰는 내부 임계값이나 다른 고객의 정보는 오류 화면에서 공개할 필요가 없습니다. 정상 고객이 차단된 사건은 차단 요청 ID와 정책 버전으로 담당자가 찾아볼 수 있어야 합니다. 웹 방화벽 규칙이 관여했으면 WAF 예외의 수명주기에서 예외 사유와 종료 시점을 관리할 수도 있습니다.

정책 시험은 손실과 오탐을 함께 센다

관측 전용 기간에는 후보 판정, 판단에 쓰인 정책 버전, 정상으로 확인할 수 있는 후속 신호를 남깁니다. 같은 기간 전반의 전환율만 비교하면 상품 인기도와 캠페인 유입 차이를 보안 결과로 착각할 수도 있습니다. 운영 제약 안에서 비교 가능한 상품군이나 시간대를 고르고 판단을 적용할 업무를 단계별로 제한합니다. 악용으로 확인한 건과 아직 모르는 건을 분리하고 검토한 표본에 속한 비율인지 전체 시도의 비율인지 표시합니다.

보호 성과는 부당 소진·점유량·차단되지 않은 반복 남용과 함께 정리합니다. 고객 영향은 정상으로 확인한 요청 중 추가 확인이나 차단에 걸린 비율, 확인 중 포기율, 실제 완료율, 보류 해제까지 걸린 시간으로 봅니다. 통제를 켰는데 정상 완료율이 떨어진 경우에는 먼저 어느 경로에서 떨어졌는지 확인하고 해당 범위만 축소합니다. 상품별 정책 변경 권한과 복귀 조건, 업무 흐름에 남은 보류 건을 인수할 사람을 지정해 두면 조치가 혼란을 더하는 일을 줄일 수 있습니다.