WAF가 정상 요청을 차단할 때, 예외 규칙을 어디까지 허용할까

문제와 판단 기준

웹 편집기에서 문서를 저장했는데 403 응답이 돌아옵니다. 로그인과 조회는 정상이고 특정 내용을 넣을 때만 저장이 실패합니다. 이런 상황에서 해당 경로를 통째로 허용하면 업무는 다시 움직일 수 있습니다. 하지만 무엇을 검사하지 않게 됐는지는 별개의 문제로 남습니다.

WAF 예외는 정상 동작과 충돌한 검사를 확인한 뒤, 필요한 요청과 규칙에만 적용해야 합니다. 적용 전에 남겨 둘 방어와 되돌릴 조건을 정하고 임시 예외에는 담당자·재검토 시각·만료 시각을 붙이는 방식을 권합니다. 차단이 줄었다는 사실만으로 변경을 완료하지 않습니다. 정상 기능이 복구됐고, 예외 밖의 요청과 나머지 보안 통제도 의도대로 처리되는지 확인해야 합니다.

아래는 2026년 9월 26일 확인한 공식 문서를 바탕으로 정리한 운영 가이드입니다. 제품별 동작은 각 문서의 적용 범위 안에서 설명하고 승인·만료·검증 절차는 팀이 정할 운영 설계로 제안합니다. 사례와 변경 기록은 모두 설계 예시이며 실제 고객 사건이나 테스트 결과가 아닙니다.

먼저 403을 누가 만들었는지 확인한다

403은 원본 웹서버의 접근 제한이나 애플리케이션의 권한 검사에서도 나올 수 있습니다. Cloudflare 역시 WAF뿐 아니라 다른 보안 기능과 일부 연결 처리에서 403을 반환합니다. 따라서 응답 코드나 차단 화면의 로고만 보고 WAF 오탐이라고 확정해서는 안 됩니다.^[1]

조사는 같은 요청을 각 계층에서 찾아 연결하는 일부터 시작합니다.

계층마다 식별자가 다르면 연결 관계부터 확인합니다. 값이 같을 것이라고 가정하거나, 시각 하나가 비슷하다는 이유로 다른 요청을 연결하지 않습니다. 요청 전체를 붙여 넣기보다 메타데이터와 민감정보를 제거한 재현 자료를 사용합니다.

특히 규칙에 일치했다는 기록과 최종 차단 원인은 다릅니다. AWS WAF 로그는 최종 액션, 종료 규칙, 규칙 그룹 내부의 일치 정보, 비종료 일치 정보를 구분합니다. 그룹 이름만 확인하고 그 안의 어느 규칙이 차단했는지 놓치지 않아야 합니다.^[2]

로그가 없다는 이유만으로 WAF를 원인에서 제외하는 것도 이릅니다. Cloudflare Security Events는 모든 유입 요청의 목록이 아니며, 표본 추출이 적용될 수 있고 한 요청이 여러 이벤트를 만들 수도 있습니다. 검색 시간 범위와 필터를 좁히고, 필요한 경우 다른 요청 로그와 대조합니다. 이벤트 건수를 그대로 사용자 요청 수로 계산하지 않습니다.^[3]

“정상 요청”이라는 근거를 먼저 만든다

사용자가 보냈거나 로그인한 상태라는 사실만으로 내용까지 안전하다고 판단하지 않습니다. 먼저 애플리케이션이 허용하기로 한 동작을 확인합니다. 문서 본문에서 제한된 HTML을 허용하는지, 해당 사용자가 그 문서를 수정할 권한이 있는지, 서버가 실제로 같은 입력 계약을 적용하는지를 살펴 판단합니다.

OWASP Core Rule Set(CRS)은 애플리케이션의 개별 업무 맥락을 모르는 일반 탐지 규칙이 정상 입력과 충돌할 수 있다고 설명합니다. 오탐 로그 자체에 비밀번호나 다른 민감정보가 담길 수도 있으므로, 원문 요청을 공개 이슈나 공용 문서에 복사하는 방식은 피해야 합니다.^[4]

이 글에서는 다음을 예외 검토에 필요한 최소 증거로 제안합니다. 민감정보를 제거한 입력으로 허가된 테스트 환경에서 실패를 재현하고 어떤 필드가 어떤 규칙과 충돌하는지 설명합니다. 그 입력이 업무 계약상 허용된다는 확인과, 애플리케이션의 관련 보안 처리 근거를 함께 남깁니다. 예외를 적용한 뒤에는 HTTP 성공 응답뿐 아니라 실제 저장·재조회 결과까지 확인합니다.

이 증거가 없으면 예외를 넓히기보다 원인 조사를 계속하는 편이 낫습니다. WAF가 취약한 입력 처리를 대신 막고 있는 상황과 정상 입력의 오탐은 대응이 달라야 합니다.

요청의 범위를 좁히는 것과 사용자를 신뢰하는 것은 다르다

예외의 범위는 “이 사이트 전체”보다 “이 호스트의 이 경로로 들어오는 이 메서드”에 가깝게 잡습니다. 제품과 엔진이 지원한다면 문제를 일으킨 필드와 규칙까지 더 좁힙니다. 여기서 경로·메서드 조건은 예외가 적용될 요청을 고르는 조건이지, 그 요청이 안전하다는 증명은 아닙니다.

인증 맥락을 조건으로 쓰려면 해당 WAF 평가 시점에 검증된 신원 정보가 실제로 제공되는지 확인해야 합니다. 클라이언트가 넣을 수 있는 X-Trusted 같은 헤더, 임의 파라미터, 세션 쿠키의 존재만으로 “인증된 요청”을 만들지 않습니다. 특정 국가나 IP라는 이유만으로 나머지 검사를 모두 생략하는 방식도 이 글의 기본안으로 삼지 않습니다.

WAF 앞에서 신원을 검증할 수 없는 구조라면, 예외가 비인증 요청에도 적용된다는 사실을 위험 기록에 명시합니다. 애플리케이션의 인증·권한 검사는 그대로 유지해야 합니다. OWASP도 권한을 요청마다 검증하고 명시적으로 허용되지 않은 접근은 기본적으로 거부하도록 권고합니다.^[5]

제품마다 ‘예외’가 건너뛰는 대상이 다르다

CRS: 특정 규칙의 검사 대상에서 필드를 뺄 수 있다

CRS 문서는 규칙 전체를 제외하는 방식과 특정 변수만 검사 대상에서 제외하는 방식을 구분합니다. 조건부 런타임 예외를 이용하면 특정 요청에서 특정 규칙의 검사 대상만 조정할 수 있습니다. 다만 엔진과 규칙 구조에 제약이 있습니다. 체인 규칙의 모든 단계에서 원하는 필드 제외가 가능한 것은 아니며, 설정 시점 예외와 런타임 예외는 배치 순서도 다릅니다. 배포된 CRS 원본 규칙 파일을 직접 고치기보다 별도 예외 설정으로 관리합니다.^[4]

Cloudflare: 선택한 규칙을 해당 요청에서 건너뛰는 방식이다

Cloudflare Managed Rules의 예외는 일치 조건과 건너뛸 규칙·규칙 세트를 지정합니다. 따라서 경로를 좁혀 특정 관리형 규칙을 Skip하는 것과, 그 규칙이 검사하는 여러 필드 중 하나만 빼는 것은 같은 변경이 아닙니다. 계정 수준과 영역(zone) 수준의 적용 범위도 구분해야 합니다. 뒤에 평가되는 영역 수준 예외가 앞선 계정 수준 차단을 되돌리는 것은 아닙니다.^[6]

Custom Rules의 Skip에서는 선택에 따라 관리형 규칙뿐 아니라 Rate Limiting이나 Super Bot Fight Mode 등의 평가도 건너뛸 수 있습니다. 이름이 비슷한 Bot Fight Mode는 같은 방식으로 건너뛸 수 없습니다. 화면에서 선택한 대상을 변경 기록에 정확히 적고, 예외 요청의 로깅 여부도 확인합니다. Skip 규칙의 로깅을 끄면 해당 요청이 Security Events에 나타나지 않을 수 있습니다.^[7]

AWS WAF: Count는 검사를 생략하는 기능이 아니다

AWS WAF의 Count는 규칙 일치를 기록하면서 후속 평가를 계속하는 비종료 액션입니다. Allow는 해당 웹 ACL의 평가를 끝내므로 뒤의 WAF 규칙을 계속 검사하게 하는 대안이 아닙니다. 또한 규칙 그룹의 반환 액션만 Count로 바꾸는 것과, 그룹 내부의 개별 규칙 액션을 Count로 바꾸는 것도 다릅니다. 전자는 그룹 안의 평가 흐름까지 바꾸지는 않습니다.^[8]

AWS가 설명하는 예외 처리에는 개별 규칙을 Count로 바꾸고, 그 규칙이 붙인 label을 후속 규칙에서 사용하는 패턴이 있습니다. 차단 규칙을 조정하는 경우라면 “그 label이 있고 좁은 예외 조건에는 해당하지 않는 요청”을 다시 차단하는 식으로 설계할 수 있습니다. 실제 label 제공 여부·정확한 이름·평가 순서를 확인해야 하며 후속 차단을 누락하면 예외 밖의 요청까지 보호가 약해집니다.^[9]

한편 관리형 규칙 그룹의 scope-down statement는 그 그룹에 들어갈 요청 자체를 제한합니다. 그룹에 들어가지 않는 요청은 그 안의 다른 규칙에도 평가되지 않습니다. 이를 한 필드나 한 규칙만 제외하는 설정으로 취급해서는 안 됩니다.^[10]

이 차이 때문에 벤더를 바꿀 때 예외 조건 문자열만 옮겨서는 안 됩니다. 예외에 들어가는 요청, 빠지는 검사, 계속 남는 검사를 함께 비교해야 합니다.

예외 변경 기록은 이렇게 작성한다

다음은 제한된 HTML을 허용하는 문서 편집 기능의 설계 예시입니다. 자체 운영 CRS 환경에서 해당 규칙의 필드 단위 제외가 가능하다고 가정했습니다. R, A, B는 설명용 식별자이며 실제 규칙 ID나 배포 버전이 아닙니다. Cloudflare나 AWS WAF에 그대로 옮길 설정은 아닙니다.

보완 통제는 빠진 방어와 같은 위험을 다뤄야 합니다. XSS 검사를 뺐는데 속도 제한만 추가했다고 같은 위험이 보완되지는 않습니다. HTML 입력이 필요한 기능은 적절한 HTML 정제가 필요하고 일반 문자열은 출력 위치에 맞는 인코딩이 중요합니다. OWASP는 WAF를 애플리케이션 XSS 원인 자체의 해결책으로 보지 않습니다.^[11]

각 통제가 맡을 일을 정리하려면 WAF·API Gateway·Rate Limit·Schema Validation·JWT·mTLS의 역할 비교에서 각 통제의 역할을 비교합니다.

정상 요청뿐 아니라 예외의 경계도 다시 검증한다

검증은 소유하거나 명시적으로 허가받은 테스트 환경에서 합니다. 실제 고객 토큰이나 운영 요청 본문을 옮기지 않고, 필요한 특징만 보존한 합성 입력을 사용합니다. 다음 표는 앞선 사례의 기대 결과를 정하는 설계 예시이지 실행 완료 보고서가 아닙니다.

이 검증에서 “막혀야 한다”는 결과를 모두 WAF의 403으로 통일하지 않습니다. 권한 검사는 애플리케이션이 거부할 수 있고, HTML 정제는 안전한 값으로 바꾸는 방식일 수 있습니다. 어느 계층이 어떤 결과를 책임질지를 먼저 정해야 잘못된 통과 판정을 피할 수 있습니다.

팀의 변경 기록에는 선정한 테스트뿐 아니라 제외한 항목과 이유도 남깁니다. 기록 형식이 필요하면 기존 변경별 회귀 테스트 범위 결정 워크북을 사용하고 WAF 예외 때문에 추가된 경계와 보안 기대 결과를 연결합니다.

제한 적용 뒤에는 차단 수보다 기능과 방어를 함께 본다

테스트를 통과했다고 전체 사이트에 예외를 복사하지 않습니다. 원인이 확인된 기능과 경로에 먼저 적용하고 누가 관측하며 어느 조건에서 중단할지 정합니다. AWS 역시 운영 적용 전 테스트·조정을 권고하며 설정 변경이 전파되는 동안 일시적으로 서로 다른 동작이 나타날 수 있다고 설명합니다. 변경 API가 성공했다는 응답과 모든 관측 지점에서 새 정책이 작동한다는 확인은 구분합니다.^[12]

관측 항목은 예외에 일치한 요청의 범위, 해당 업무의 성공 여부, 예외 밖의 차단, 애플리케이션의 인증·입력 오류를 함께 잡는 방식이 좋습니다. 차단 건수만 내려갔다면 검사를 덜 해서 내려간 것인지, 실제 오탐을 줄인 것인지 아직 알 수 없습니다. 표본 이벤트로 전체 오탐률을 계산하거나, Skip한 검사에서 탐지가 없다는 사실을 안전의 증거로 쓰지 않습니다.

만료 시각은 규칙 설명란에 날짜를 적는 것으로 끝나지 않습니다. 자동 제거 기능이나 승인된 자동화가 있으면 실제 동작과 실패 알림을 확인하고 없다면 담당자에게 제거·재승인 작업과 확인 절차를 배정합니다. 모든 WAF가 예외를 자동 만료시켜 주는 것은 전제로 삼지 않습니다. 여기서 제안하는 만료는 조직의 운영 통제입니다.

예외를 제거하면 원래의 정상 요청 차단이 돌아올 수도 있습니다. 이때도 전체 허용으로 확대하기보다 위험을 다시 평가하고 필요하면 해당 기능을 제한하거나 대체 업무 경로를 제공합니다. 긴급 예외가 꼭 필요한 경우에도 승인자·범위·종료 조건을 남깁니다.

달력상의 만료 전이라도 재검토할 때가 있습니다. 경로·메서드·파서·인증 흐름이 바뀌었거나 규칙 세트가 갱신됐다면 기존 예외의 근거를 다시 확인합니다. Cloudflare의 2026년 9월 22일 변경 기록에도 관리형 규칙의 액션을 Log에서 Block으로 전환한 항목이 있습니다. 애플리케이션 코드가 그대로여도 보안 규칙의 동작은 달라질 수 있습니다.^[13]

애플리케이션을 고쳐야 할 때는 예외로 덮지 않는다

입력 형식이 서버의 계약과 어긋나거나, HTML을 그대로 저장·출력하고 있거나, 권한 검사가 빠져 있다면 먼저 그 설계를 고치는 편이 맞습니다. 반대로 업무상 필요한 정상 입력을 일률적으로 삭제해 오탐을 없애는 것도 좋은 해결책은 아닙니다. 허용할 입력과 안전하게 처리할 방식을 정한 뒤 예외 필요성을 판단합니다.

검사를 피하려는 목적으로 내용을 다른 인코딩이나 불투명한 데이터로 감추는 변경은 이 글의 해결안에 포함하지 않습니다. 예외가 필요하더라도 탐지를 피했다는 사실이 아니라, 허용할 동작과 보완 통제의 검증으로 정당화해야 합니다.

다음 상태라면 예외 유지를 승인하지 않는 기준을 권합니다. 원래 규칙이 막던 위험을 설명할 수 없거나, 필요한 보완 통제가 없거나, 실제 구현이 의도한 최소 범위보다 훨씬 넓거나, 변경을 관측하고 되돌릴 담당자가 없는 경우입니다. 안전한 운영 조건을 만들 수 없다면 기능을 잠시 제한하는 선택까지 검토합니다.

WAF 예외를 끝내는 시점은 사용자의 저장 버튼이 다시 작동한 순간이 아닙니다. 정상 기능의 복구, 남겨 둔 방어의 유지, 예외의 제거 또는 재승인까지 확인했을 때 변경을 닫을 수 있습니다.

규칙·로그·복귀 책임이 여러 팀에 나뉘어 있다면 IXC 웹방화벽·DDoS 방어 서비스의 규칙 설계·운영 범위를 확인하고 내부에서 맡을 일과 지원받을 일을 구분할 수 있습니다.