RegularExpressionProtection 정책은 입력 매개변수 또는 흐름 변수에서 런타임에 평가되는 정규 표현식을 정의합니다. 일반적으로 이 정책을 사용하여 SQL 또는 자바스크립트 삽입과 같은 콘텐츠 위협을 방지하거나 이메일 주소 또는 URL과 같은 잘못된 형식의 요청 매개변수를 확인할 수 있습니다.
정규 표현식은 요청 경로, 쿼리 매개변수, 양식 매개변수, 헤더, XML 요소(XPath로 정의된 XML 페이로드), JSON 객체 속성(JSONPath를 통해 정의된 JSON 페이로드)에 정의할 수 있습니다.
다음과 같은 RegularExpressionProtection 정책 예시는 SQL 삽입 공격으로부터 백엔드를 보호합니다.
기본 수량자(*, +, ?)는 기본적으로 탐욕적이므로 항상 가장 긴 시퀀스와의 매칭을 시작합니다. 일치하는 항목이 없으면 점진적으로 되돌아가서 패턴 매칭을 시도합니다. 패턴과 일치하는 결과 문자열이 매우 짧으면 탐욕적 수량자 사용 시간이 필요 이상으로 길어질 수 있습니다. 페이로드가 수십 또는 수백 KB로 큰 경우에 특히 그렇습니다.
다음 예시 표현식에서는 탐욕적 연산자인 .*의 여러 인스턴스를 사용합니다.
<Pattern>.*Exception in thread.*</Pattern>
이 예시에서 RegularExpressionProtection 정책은 먼저 가장 긴 시퀀스인 전체 문자열 매칭을 시도합니다. 일치하는 항목이 없으면 정책이 점진적으로 되돌아갑니다. 일치하는 문자열이 페이로드의 시작 부분이나 중간 부분에 가까울 경우 .* 같은 탐욕적 수량자를 사용하면 .*? 같은 까다로운 한정자 또는 (일반적이지 않은) .*+ 같은 독점적 수량자보다 훨씬 더 많은 시간과 처리 능력이 소요될 수 있습니다.
까다로운 수량자(예: X*?, X+?, X??)는 페이로드 시작 부분에서 단일 문자를 매칭하기 시작하고 점진적으로 문자를 추가합니다.
독점적 수량자(예: X?+, X*+, X++)는 전체 페이로드에 대해 한 번만 매칭을 시도합니다.
위의 패턴에 대한 다음 샘플 텍스트를 보겠습니다.
Hello this is a sample text with Exception in thread
with lot of text after the Exception text.
이 경우 탐욕적 .*를 사용하면 성능이 저하됩니다. .*Exception in thread.* 패턴은 141단계로 매칭을 수행합니다. 까다로운 수량자를 사용하는 .*?Exception in thread.* 패턴을 대신 사용할 경우 55단계만 거치면 됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-18(UTC)"],[[["\u003cp\u003eThis document covers the use of the RegularExpressionProtection policy in Apigee and how greedy quantifiers in regular expressions can negatively impact performance.\u003c/p\u003e\n"],["\u003cp\u003eThe RegularExpressionProtection policy is used to protect against content threats like SQL or JavaScript injection by evaluating regular expressions on input parameters or flow variables.\u003c/p\u003e\n"],["\u003cp\u003eGreedy quantifiers, like \u003ccode\u003e.*\u003c/code\u003e, try to match the longest possible sequence first and can lead to increased latency, higher CPU utilization, and potential API request timeouts.\u003c/p\u003e\n"],["\u003cp\u003eReluctant quantifiers (e.g., \u003ccode\u003e.*?\u003c/code\u003e) and possessive quantifiers (e.g., \u003ccode\u003e.*+\u003c/code\u003e) are more performant alternatives to greedy quantifiers when used within the RegularExpressionProtection policy.\u003c/p\u003e\n"],["\u003cp\u003eThe document emphasizes the best practice of avoiding greedy quantifiers and instead using reluctant or possessive quantifiers within regular expressions in the RegularExpressionProtection policy for enhanced performance.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/greedy-quantifiers) documentation.*\n\nThe [RegularExpressionProtection policy](/apigee/docs/api-platform/reference/policies/regular-expression-protection) defines regular expressions that are evaluated at\nruntime on input parameters or flow variables. You typically use this policy to protect against\ncontent threats like SQL orJavaScript injection, or to check against malformed request parameters\nlike email addresses or URLs.\n\nThe regular expressions can be defined for request paths, query parameters, form parameters,\nheaders, XML elements (in an XML payload defined using XPath), JSON object attributes (in a JSON\npayload defined using JSONPath).\n\nThe following example RegularExpressionProtection policy protects the backend from SQL\ninjection attacks: \n\n```world-of-warcraft-toc\n\u003c!-- /antipatterns/examples/greedy-1.xml --\u003e\n\u003cRegularExpressionProtection async=\"false\" continueOnError=\"false\" enabled=\"true\"\n name=\"RegexProtection\"\u003e\n \u003cDisplayName\u003eRegexProtection\u003c/DisplayName\u003e\n \u003cProperties/\u003e\n \u003cSource\u003erequest\u003c/Source\u003e\n \u003cIgnoreUnresolvedVariables\u003efalse\u003c/IgnoreUnresolvedVariables\u003e\n \u003cQueryParam name=\"query\"\u003e\n \u003cPattern\u003e[\\s]*(?i)((delete)|(exec)|(drop\\s*table)|\n (insert)|(shutdown)|(update)|(\\bor\\b))\u003c/Pattern\u003e\n \u003c/QueryParam\u003e\n\u003c/RegularExpressionProtection\u003e\n```\n\nAntipattern\n\nThe default quantifiers (`*`, `+`, and `?`) are greedy in\nnature: they start to match with the longest possible sequence. When no match is found, they\nbacktrack gradually to try to match the pattern. If the resultant string matching the pattern is\nvery short, then using greedy quantifiers can take more time than necessary. This is especially\ntrue if the payload is large (in the tens or hundreds of KBs).\n\nThe following example expression uses multiple instances of `.*`, which are greedy\noperators: \n\n```\n\u003cPattern\u003e.*Exception in thread.*\u003c/Pattern\u003e\n```\n\nIn this example, the [RegularExpressionProtection policy](/apigee/docs/api-platform/reference/policies/regular-expression-protection) first tries to match the longest possible\nsequence---the entire string. If no match is found, the policy then backtracks\ngradually. If the matching string is close to the start or middle of the payload, then using a\ngreedy quantifier like `.*` can take a lot more time and processing power than reluctant\nqualifiers like `.*?` or (less commonly) possessive quantifiers like\n`.*+`.\n\nReluctant quantifiers (like `X*?`, `X+?`, `X??`) start by trying\nto match a single character from the beginning of the payload and gradually add characters.\nPossessive quantifiers (like `X?+`, `X*+`, `X++`) try to match the\nentire payload only once.\n\nGiven the following sample text for the above pattern: \n\n```\nHello this is a sample text with Exception in thread\nwith lot of text after the Exception text.\n```\n\nUsing the greedy `.*` is non-performant in this case. The pattern\n`.*Exception in thread.*` takes 141 steps to match. If you used the pattern\n`.*?Exception in thread.*` (which uses a reluctant quantifier) instead, the result would\nbe only 55 steps.\n\nImpact\n\nUsing greedy quantifiers like wildcards (`*`) with the\n[RegularExpressionProtection policy](/apigee/docs/api-platform/reference/policies/regular-expression-protection) can lead to:\n\n- An increase in overall latency for API requests for a moderate payload size (up to 1MB)\n- Longer time to complete the execution of the RegularExpressionProtection policy\n- API requests with large payloads (\\\u003e1MB) failing with 504 Gateway Timeout Errors if the predefined timeout period elapses on the Apigee Router\n- High CPU utilization on Message Processors due to large amount of processing which can further impact other API requests\n\nBest practice\n\n- Avoid using greedy quantifiers like `.*` in regular expressions with the [RegularExpressionProtection policy](/apigee/docs/api-platform/reference/policies/regular-expression-protection). Instead, use reluctant quantifiers like `.*?` or possessive quantifiers like `.*+` (less commonly) wherever possible.\n\nFurther reading\n\n- [Regular Expression Quantifiers](https://docs.oracle.com/javase/tutorial/essential/regex/quant.html)\n- [RegularExpressionProtection policy](/apigee/docs/api-platform/reference/policies/regular-expression-protection)"]]
