[[["わかりやすい","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)"]]
