With the node returned, you're able to use fragments to ask for specific node fields. Usually, this ID is the base64 encoded combination of the _typename and the id fields of a node. The Relay spec defines that each Node in a Graph must be accessible through a globally unique identifier. For that reason, we'll give this section a bit more structure. So, the range of possible attacks goes from simple denial of service attacks to more sophisticated approaches that return data which should not be returned. ![]() A GraphQL Operation can walk from node to node, wherever it wants, it you don't do anything about it. This has to do with the way GraphQL is designed. At this point, it's also a great chance for the framework user to mess up. When executing a GraphQL Operation, it's not only the frameworks' responsibility to do the right thing. The real trouble is still ahead of us, executing the Operation. If your library of choice validates a GraphQL Operation, you should still be cautious, especially when you're dealing with PII (personally identifiable information).Īt this point, we've probably passed a few bugs already by passing our request through the parser, normalization and validation. Summary: If a standard library can parse your URL, it's valid. Until then, don't trust any GraphQL validation library if you haven't tested it yourself. I hope, everybody is doing their best to get it right. You could also copy the tests from the reference implementation, but that's also no guarantee that the logic is 100% correct.Īgain, as we don't have a project like CATS anymore, we're not really able to prove if our implementations are correct. Other libraries and frameworks are probably taking different approaches. There are a lot of pitfalls you could fall into. Copy & paste Errors, general misunderstanding, implementing the logic to make the tests green while the logic is still wrong. There are various ways how this could go wrong. What I've done is, I copied the complete structure from the GraphQL Specification one by one and turned it into unit tests. One of the unit test files is more than 1000 LOC. I've implemented GraphQL Operation validation myself. GraphQL Operation Validation, an absolute minefield There's plenty of opportunities left for bugs.ģ. Turning a string into an AST is just one small piece of the puzzle. A lot of code means, a lot of potential for bugs.Īnd don't get me wrong, this is not about hand-written parsers vs. I'm the owner of an implementation written in Go. You should not trust any GraphQL library without heavy testing, including fuzzing. Parsing GraphQL Operations is a nightmare. ![]() Unfortunately, the project's last commit is from 2018.Īlright, parsing a URL seems simple and well understood. The idea was to build a tool so that different GraphQL implementations can prove that they work as intended. It's quite a mouthful, but the idea is brilliant. What if we add building a valid AST into the equation? What if we add executing the Operations as well? We almost forgot about validating Operations, a topic in itself.Ī few years ago, there was a small group of people who started an amazing open source project: CATS The GraphQL Compatibility Acceptance Test. Keep in mind that we're still talking about simply parsing the Operations. What if we picked all GraphQL libraries and frameworks and test them against numerous GraphQL Operations? What does this mean for us? The person who performed the benchmarks hand-picked a number of GraphQL libraries and ran a few benchmarks. At the same time, I was surprised that some libraries didn't accept the test Operations while other were able to parse them. It made me happy to see that my own library was performing quite well. If we factor in both variables, it's obvious that there must be a lot more experience and expertise in parsing URLs than parsing GraphQL operations.īut why is this even a problem? Recently, a friend of mine analyzed some popular libraries to see how fast they are in parsing GraphQL queries. So, it's fair to say that the GraphQL language is around 4 times more complex than the one defining a URL. The grammar for parsing a GraphQL document is 325 lines. The grammar for parsing a URL is 86 lines. Next, let's have a look at the antlr grammar for both. This gives parsing URLs an advantage of 20 years over parsing GraphQL Operations. If we search the same source for the birth of GraphQL, we can see, it's Sep 2014, around 7 years old. ![]() According to Wikipedia, the concept of the URL was first published in 1994, that's 27 years ago. REST? Let's compare a URL against a GraphQL Operation. ![]() Why? Why is GraphQL so much more vulnerable than e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |