Change:
Let's use this issue to capture possible items for the Security Considerations section of the spec. As discussed in URL, CPU exploits are possible using selectors such as: One mitigation would be to run the implementation in an environment, such as a Linux cgroup, which can restrict the CPU consumed.
NAME provided the following: A malicious user can submit a JSON object intended to cause explosive backtracking by a JSONPath implementation performing regular expression matching. This is known as a ReDOS [REDOS] attack. To defend against this attack, regular expressions in JSONPath filters SHOULD conform to RE2 syntax [RE2SYNTAX], which does not support backtracking. (but MAY not support "C" - move this to the filter section). Additionally, implementations SHOULD guarantee linear run time for regular expression matching, such as provided by the original RE2 library implementation [RE2IMPL] and Go's "regexp" library [GOREG]. [GOREG] The Go Authors, "Package regexp", January 2007, . [RE2IMPL] The RE2 Authors, "RE2", March 2010, . [RE2SYNTAX] The RE2 Authors, "Syntax", November 2014, . [REDOS] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic Complexity Attacks (In "Proceedings of the 12th USENIX Security Symposium")", August 2003.
NAME suggested adding the following to the Security Considerations section: Eavesdropping, replay, message insertion, deletion, modification and man-in-the-middle attacks are considered out of scope for JSONPath. These attacks are relevant to a network protocol, but not to a query language.
Granted, but I'm not sure this would be in-scope for the RFC.
Agreed about specific solutions not being in scope for the RFC. At most, I think we can identify several potential risks, but: It should be stated that such a list of risks cannot be comprehensive. Solutions will be specific and relevant according to the implementation, and so should not be included. As an exaample of point 2, an implementation that is designed for applications that run on Windows obviously cannot run in Linux.
Would it be worth giving special consideration to concerns for JavaScript in the security considerations? RFC 8259 does this, and there are similar concerns for this document too. For instance, some naïve implementations of JSONPath in JavaScript could run into trouble with paths that refer to things like or that try to invoke special functions like (which you can trigger by concatenating any non-string value with a string). JavaScript is special here in that it's very popular and there is a very strong conventional representation for JSON data -- whatever returns -- and that representation can, if you naïvely fetch its attributes, start returning things that the programmer might not expect to be manipulating. It may be worth talking to seasoned JavaScript security practitioners if we want to make any comment on the perils of walking arbitrary properties of . I am not such a person.
It may be worth mentioning that the recursive descent operator is a possible security issue. Naïve implementations that simply recurse down the stack may be vulnerable to attack, and would likely fail suitably designed fuzzer tests. At the least, the specification should require a limit to the depth of recursion.
How big of JSON objects are we talking about here? It's not like GraphQL where you can actually have requests for circular data. JSON is most definitely finite, and surely other mechanisms, such as limits on request size (an application concern), would capture JSON objects large enough to cause recursion issues. Unless your available call stack is really small, I suppose. But environmental awareness seems like a concern of either the app or the implementation, not this spec.
We're talking about attack files that are specifically generated to exploit vulnerabilities. That's what fuzz testing is about, bombarding your function calls with simulated attack files on a continuous basis, to detect whether your API is vulnerable to malicious attackers. Recursive algorithms are a big source of security vulnerabilities. Daniel
We still have to write the Security Considerations section. (Some of this also goes into .)

Discussion:
5. <del> This section gives security considerations, as required by RFC3552. </del> <ins> Security considerations for JSONPath can stem from attack vectors on JSONPath implementations, and the way JSONPath is used in security-relevant mechanisms. 5.1. Historically, JSONPath has often been implemented by feeding parts of the query to an underlying programming language engine, e.g., JavaScript.  This approach is well known to lead to injection attacks and would require perfect input validation to prevent these attacks (see RFC8259 for similar considerations for JSON itself).  Instead, JSONPath implementations need to implement the entire syntax of the query without relying on the parsers of programming language engines. Attacks on availability may attempt to trigger unusually expensive runtime performance exhibited by certain implementations in certain cases.  (See RFC8949 for issues in hash-table implementations, and I- D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. 5.2. Where JSONPath is used as a part of a security mechanism, attackers can attempt to evoke unexpected behavior, or take advantage of differences in behavior between JSONPath implementations. This also applies to underlying technologies such as UTF-8 (see RFC3629), the Unicode character set, and JSON.  A characteristic of JSON that can lead to varying results is the fact that JSON objects are unordered; therefore, the order in which results of a JSONPath query reflect the presence of JSON object members can vary with implementations. </ins>