0:01

This is Software Engineering Radio, the

0:03

podcast for professional developers on the

0:05

web at se-radio.net. SE

0:08

Radio is brought to you by the IEEE

0:10

Computer Society and by IEEE Software Magazine, online

0:13

at computer.org/software. Hi,

0:19

everyone. I'm Priyanka Raghavan for Software

0:21

Engineering Radio. And

0:23

today I'm charting with Shahar

0:26

Benyamin, the CEO and co-founder

0:28

of Inigo, to talk about

0:30

GraphQL security. Shahar is a

0:32

software engineer by trade. He

0:34

has extensive experience working on

0:37

many high-profile enterprise applications and

0:39

security projects. He has

0:41

written several articles and given talks at technology

0:43

conferences, all of which are added to our

0:45

show notes. So welcome to the show, Shahar.

0:48

Hey, Priyanka, great to be here. One

0:51

of the things we've done is we've done a

0:53

deep dive on GraphQL, which is episode 530. So

0:56

listeners can obviously listen to that episode

0:58

to understand the history and the basics

1:00

of GraphQL. Having said that, since

1:03

we have you on the show and it's been

1:05

a while since we did that, I have to

1:07

ask you if you could just briefly define for

1:09

us what is GraphQL. I know it's tough, but

1:12

maybe a little bit, one or two lines. And

1:14

then can you also tell us why the state

1:16

of GraphQL adoption is so great or

1:18

whether you think it's otherwise, but I personally

1:20

think there's a big adoption in the GraphQL

1:23

space. What is the state

1:25

of GraphQL adoption? Yeah,

1:27

absolutely. Great question. So

1:29

GraphQL is merely a spec. It's

1:31

an API spec that came out of Facebook, now

1:33

meta, back in 2016. And

1:36

it's a query-based API and really

1:38

was there to solve some of

1:40

the rest limitations of under-fetching and

1:43

over-fetching. It's a great tool that

1:45

really expedited front-end developers, allowed them

1:47

to move freely, extract any data

1:49

that they want in any type

1:51

of hierarchy. And we've seen

1:53

a lot of it when it comes out of Facebook. We've

1:56

seen the open source communities, specifically

1:59

developers. really adopting it and

2:01

you can actually find an implementation

2:03

of GraphQL in any programming language

2:05

you might think of. Now when

2:07

we think about the adoption of

2:09

GraphQL, I would say

2:11

that like any developer-driven technology,

2:14

developer brings it into the organization. They

2:16

get all hyped about it and like

2:18

any new technology, like let's put this

2:20

everywhere. It doesn't work everywhere, but it

2:23

does work really well when it's the

2:25

right place like a client server or

2:27

we have an open API. So

2:29

it had a rough path at the beginning

2:31

with rejections and like a lot of excitement,

2:34

a lot of rejection, and now

2:36

it's really finding its place and actually

2:38

becoming mainstream in many enterprises. And

2:41

just kind of following up on that question,

2:43

you had an article on DevZone which

2:45

is titled You Love GraphQL, now how

2:47

to make sure your organization does too.

2:49

So why do you think GraphQL is

2:51

popular among developers and what could they

2:54

do to bring it into their organizations?

2:56

Maybe you have like a case study

2:58

where you work with a company where the developers

3:00

liked it and then they had a success story of

3:02

bringing the organization in. Usually,

3:05

there's always one champion and maybe this

3:07

person worked with GraphQL in their previous

3:09

company and that's the story we see

3:11

a lot and then people move around

3:13

and they say, hey, we know about

3:15

this new technology and there's always a

3:17

new feature, there's always a new product.

3:19

Some legacy companies say, okay, it's time

3:21

to refresh our stack and

3:23

then GraphQL is becoming a

3:25

discussion. Can we do this? And

3:27

front-end developers when we hear about this, they

3:29

say, yes, this is what we want. So

3:32

now you have the back-end champion and the

3:34

front-end team pushing for the same thing. And

3:36

usually it will start with the side product,

3:39

with some exploration. But now

3:41

if you want you as the

3:43

champion to push this down the org, then

3:45

you need more supporters. And

3:48

when it even gets to a point

3:50

that you would like to productize it,

3:52

what we're seeing in a lot of

3:54

technology companies, this new concept of

3:57

platform teams or API teams, some call

3:59

them R&B. architect teams or core team,

4:01

the name is really vast. And now

4:03

you basically need to ask them to

4:05

own this other type of

4:07

API as part of the API responsibility.

4:10

And you need to have a good

4:12

reason, a good mandate, and a really

4:14

good set of building blocks to allow

4:17

an organization to adopt new technology. If

4:19

we think about the equivalent to Kubernetes

4:22

when developers brought it in and then

4:24

they said to the DevOps, hey, now

4:26

you need to operate this. And

4:28

maybe two minutes later, the security team will

4:30

come and say, hey, now how do we

4:32

secure it? We can see a similar story

4:34

with GraphQL with the platform teams, those API

4:37

teams. They say, hey, why is this? You're

4:39

asking us to do this. But

4:41

how do we do this? And I'm sure we'll break it down.

4:44

That's very interesting. To summarize, I think what

4:46

you're saying, this is probably true for any

4:49

new technology, right? They go

4:51

through a review board and then pass

4:53

it on to a central team, which

4:55

then allows the whole sort of spread

4:57

of that new technology across the organization.

4:59

And the security teams come in. I

5:01

think that probably then goes on to

5:03

my next question on why is GraphQL

5:05

security important? Let's

5:08

unfold this question. Okay. Okay.

5:11

When adopting a free form

5:13

API, which is the nature

5:15

of GraphQL, which is super

5:17

powerful, intentionally or

5:19

unintentionally in many cases, it couldn't

5:21

get abused. So GraphQL, because of

5:24

its nature, it opens

5:26

the door to a new paradigm of

5:28

attack surfaces. Think about all

5:30

the attacks you could have with REST

5:32

API and now add a whole new

5:35

set level of tools that are specifically

5:37

for GraphQL. You can see this, I

5:39

guess, in four places of attack surfaces.

5:42

You can think about the spec itself

5:44

can be abused, which is interesting,

5:47

the parser, the logic. And

5:49

we know that not all GraphQL implementations are

5:51

the same. You can think

5:53

about resource exhaustion. When

5:55

you allow to ask questions in hierarchy,

5:58

what is the cost of such a call? Well, are

6:00

you protecting from data leakage, which is

6:02

much more open? If you think about

6:05

REST again, if we take a step

6:07

back, it's a contract between the sender

6:09

and the supplier. These are the questions.

6:11

These are the response. Very strict. GraphQL

6:13

is free. Not

6:15

all requests are the same. There

6:17

are unlimited number of requests unless you put

6:19

the right guardrails. So the same as the

6:21

responses. And lastly, how

6:24

do you bring these all notions

6:26

of access control that you already have in

6:28

your system and you bring them to GraphQL

6:30

as well? So a whole new set of

6:32

challenges, but who's the owner of

6:34

them? That's another question. Okay.

6:36

Wow. That's great because it's very

6:39

interesting because I also notice in

6:41

the OAuth top 10 2023

6:43

API edition, I noticed that there were

6:45

so many examples in every category, which

6:48

had like, how can it be

6:50

abused by GraphQL APIs? You know,

6:52

so that's very interesting from what you said, because

6:54

I think that's one of the things I thought we can

6:56

dive in a bit deep in the next section, but what

6:59

are your thoughts on that? Well,

7:01

absolutely. Like anything you can do with REST, you

7:03

can do with GraphQL and more. What

7:05

sometimes is frustrating is that you

7:07

go to the OAuth website or

7:10

other API gateways

7:12

or other WAF

7:14

tools, and you go and see what they

7:16

can do for you for security, and

7:20

sometimes it's very limited. And

7:22

sometimes it ends with just a list of

7:25

recommendations. So how do

7:27

we take these recommendations and put them in

7:29

play? That is a big question. And

7:32

it's great in the last, I

7:34

think two years specifically, there is

7:36

a lot of content about GraphQL

7:38

security and articles like this are

7:40

perfect because before that, the

7:42

information out there was like extremely

7:45

limited. People were talking about

7:47

height and depth and N1,

7:49

which is a great example, but it's

7:51

tip of the iceberg. And

7:55

if you really want to increase education

7:57

around it more and

7:59

more calls and information and

8:01

blog posts are coming out there really

8:03

enriching the community, which

8:05

is very important just because of the variation

8:09

of implementations of GraphQL out there.

8:12

Interesting. So I think as the

8:14

implementations differ, you're saying that the

8:17

documentation also has to keep up to

8:19

know the different ways it can be exploited.

8:22

Last year, what was something that

8:24

we've done is we wanted to

8:27

be super critical about our deals,

8:29

vulnerabilities really exist. So

8:31

we have done two interesting things. First

8:34

of all, we licked into the CVE database

8:36

and we just wrote GraphQL to

8:38

see what will come up. And

8:41

then we saw a lot of incidents.

8:44

And remember to import, not all incidents are

8:46

reported, not all the ones we reported are

8:48

actually getting the CVE, but you start to

8:50

see a trend. And then we tried

8:52

to analyze where

8:54

those vulnerabilities really rely.

8:56

And you can see a lot

8:59

about authorization, a lot about DOS.

9:01

And then do you have the other

9:04

classical like code execution and injections and

9:06

maybe a disclosure. So we had so

9:08

much fun doing this exercise. We

9:10

did the same with HackerOne. And

9:13

we went to the HackerOne

9:15

vulnerability database. And

9:17

we said, let's try to do the same.

9:19

And it's actually the first one dated to

9:21

2018, which is even before

9:25

the first CVE. And

9:27

we've noticed bounties

9:30

really ranging from 250 even

9:32

to 20k. And

9:34

that's the beginning. That's all the different

9:37

implementations are coming out and companies are

9:39

going out and say, hey, can someone, we

9:42

don't even have the tools to try to

9:44

hack ourself and we need help here. This

9:46

is a new territory. This is new water.

9:49

And for HackerOne, all of it was almost

9:51

90% was

9:53

about the authorizations flow, which makes sense.

9:55

You don't usually go to HackerOne for

9:57

someone to DOS you. So all

9:59

those are are out there and

10:03

we can talk about it seriously to

10:05

see what hackers how they do it and we

10:07

can break it down. Okay so

10:09

I think one of the things I

10:11

should ask you before we move in the next section is

10:13

also why and

10:15

how do attackers hunt the

10:18

GraphQL API is it just because the fact that

10:20

like you said in the beginning the REST contract

10:22

is very rigid so therefore

10:24

it is just more easier.

10:28

Okay so what do hackers do with GraphQL? Well

10:30

they do two things first they detect it then

10:37

they will fingerprint it and

10:40

then they will abuse it so let's talk about

10:42

detecting. GraphQL

10:45

will always return something which is

10:47

one of the biggest blind spot

10:49

of every GraphQL owner or developer

10:51

that there's a big blind

10:53

spot upon the responses and errors there

10:55

because the error or the content or

10:57

the intent relies in the body and

11:00

not in the HTTP response so there's

11:02

always response even if it's hey you're

11:04

wrong there is a response and

11:07

there are very specific

11:10

notions on how companies put

11:12

their GraphQL endpoint it could

11:14

be slash GraphQL slash query

11:16

slash API slash playgrounds

11:19

graphical there's specific notions that

11:21

are very very very common

11:23

to use so nothing is

11:25

preventing an abuser to go

11:28

to any domain and just

11:30

write slash GraphQL and send the query

11:32

it doesn't need to be a valid

11:34

query it's just sending something so

11:36

you can go over every company

11:38

any domain and start say hey

11:40

something will reply at some point

11:42

and you can automate this obviously

11:44

and once you get the JSON

11:47

reply even doesn't matter what is reply

11:49

then you know then you have a GraphQL

11:52

server or an endpoint out there so that's

11:54

the the sex part now

11:56

based on their reply and again

11:58

you don't need to have to you don't need to know the introspection,

12:00

you don't need to know the schema, you can

12:02

just send type name. And again, please

12:04

don't use this. It's very basic once

12:07

you hear it now, but then why not

12:09

use it? And so don't, we

12:11

don't want to encourage the abuse of this, but

12:13

we want to educate that the ones who actually

12:15

own GraphQL servers, the response

12:18

could be very different between the

12:20

different implementations. One of

12:22

them can have the warding syntax syntax

12:24

error, and one of them can

12:26

have the warding syntax GraphQL error. So

12:29

based on this, you can actually fingerprint

12:32

what implementation is being

12:34

used in some cases, you can even

12:36

fingerprint the version. It

12:38

could be PHP, Golang, JavaScript,

12:41

Java, Haskell, Rust. They're

12:44

all built by different

12:46

open source communities and

12:48

they all have different levels of

12:50

efforts in them or dedication in

12:53

them. And there's a lot

12:55

of, you also published ones, there's other who

12:57

published a whole table that

13:00

identify the vulnerabilities in

13:02

each implementation. In

13:04

Golang, there's a few implementations of GraphQL

13:07

server. So knowing able to

13:09

detect, able to fingerprint the implementation

13:11

and be able to now

13:14

equipped with all those, you

13:16

can run against the vulnerabilities

13:18

of that specific implementation. Then

13:21

that's just the spec abuse. It

13:23

goes even before. So that's what's out

13:25

there. So what can you do? I

13:27

don't know. Don't use

13:30

the classic endpoint

13:32

so people can guess and

13:34

then we can talk about how,

13:36

what does it mean really to harden a GraphQL

13:38

endpoint? I think that's a

13:41

very interesting one. It's opened up a whole lot of

13:43

questions, which I hadn't really thought about. About

13:45

the hardening part. Yeah, I think

13:47

that's interesting. So I think the first thing you

13:50

said is also that the big takeaway from

13:52

this is also not to make your, you know,

13:54

the endpoints have to be a bit, not so

13:56

easy to find, right? I think the very first

13:58

thing that we should tell people. to

14:00

protect their GraphQL. I'm

14:03

not the biggest supporter of security by obfuscation,

14:05

but anything

14:08

you can do to reduce automation against

14:10

you is just good practice. Absolutely,

14:13

because nowadays I think automation

14:15

is, yeah, everybody is running those scripts to

14:17

do everything. So I think it obviously makes

14:19

sense to follow security by

14:22

obfuscation, even though it's

14:24

not really obscurity, actually security by

14:26

obscurity, even though it's

14:28

not the most intelligent thing to do. I

14:32

think now it would be a good time to dive

14:34

into some of those issues that you talked about, briefly

14:37

alluded to the fact that one

14:39

of the things that you see in a lot

14:41

of your research has shown that the

14:43

authorization errors, they seem to

14:45

crop up a lot in these use cases. So one

14:48

of the things I noticed when

14:50

I was reading the OWASP top

14:53

10 API security checklist was

14:55

the broken object level authorization, where essentially

14:57

one of the things you do, you

14:59

have these API endpoints where they might

15:02

be querying something like an ID, for

15:04

example, and that seems to be

15:06

one of the very good attack vectors. And

15:08

there was an example there also with this

15:10

can be abused by for GraphQL

15:13

API. So is that something that you can

15:15

just briefly talk us through what

15:17

you're seeing? I'll break it

15:19

into answer into three. First of

15:22

all, visibility, and then attribute access control

15:24

and then role based access control. The

15:27

first thing, which is the baseline

15:29

is even knowing it's happening or able ability

15:31

to know it happened. It really

15:33

goes into deep observability and monitoring tool

15:36

that is also still a big gap

15:38

when it comes to GraphQL is

15:40

the ability to know when these things happen

15:42

in case of an audit or an incident

15:44

or even trying to figure out what goes

15:46

wrong and what can be improved. And we're

15:49

seeing many, many companies that it's

15:51

a massive blind spot, everything,

15:54

all the GraphQL traffic and

15:57

all sort of attempts to putting

16:00

their rest hat, let's say, Hey, I'll

16:03

just throw everything to my log

16:06

tool to my SIM Splunk or

16:09

Datadog. Doesn't really help and really,

16:11

really hard to create insights and

16:14

understanding of what's happening. So

16:16

if you're blind to everything, there's no point in

16:18

trying to do it. That's the first step. First

16:20

line of defense is even knowing what's going on

16:23

and then later. And

16:26

the second thing, let's talk about role-based

16:28

access control. Your schema could be big

16:30

or could be small, but doesn't mean

16:32

that everyone should see it. And

16:36

the idea is, is to bring

16:38

your existing notions of roles in

16:40

your organizations, maybe anonymous user, maybe

16:43

a member, a user, an admin,

16:46

and really shape the interest,

16:48

the schema when call for introspection to

16:50

not to only allow what this specific

16:53

role is allowed to do and enforce

16:56

it at that time. So when they

16:58

call introspection or when they call queries

17:00

or mutations, you start

17:03

to differentiate who connects us what

17:05

in the schema and the

17:07

sooner you do it, the better before it hits

17:09

your business logic. And

17:11

lastly is the ABAC is like,

17:13

where do you put those business logic that

17:16

are specific to your org of

17:18

who can access what

17:20

specific data fields in

17:22

your org? And if we're thinking about, I'm

17:25

trying to get a specific, let's, let's take

17:27

a Twitter or X as an example, maybe

17:30

anonymous user should not be allowed to read

17:32

comments. So if they never logged in, if

17:34

they don't have a JWT, if they try

17:37

to have the query mutation about comments

17:39

information, they're blocked immediately. They

17:42

cannot, but if they are

17:44

logged in a user and they try to

17:46

get the field comments, then you have to

17:48

write your own unique business logic that says,

17:50

Hey, this user is user seven. They

17:53

cannot access and that is

17:55

more hard work, but both of them

17:57

are needed because you don't want to trigger this

17:59

business. logic if that user should not

18:01

even be allowed to ask for

18:03

that field. So you have

18:05

to have some combination of both. Hope

18:08

it makes sense. So you're

18:10

saying essentially what I understand is also like have

18:12

like various levels of check. So

18:15

like the first level cuts you off here and then

18:17

you go one level deeper, then you have another check

18:20

like the A-back kind of check, which is okay. Mistakes

18:24

always happen. Mistakes always

18:26

happen. Changes of fields always happen.

18:28

You can think of the schema as

18:30

a static thing. Developers

18:32

around the org will constantly want

18:35

to continue to change the schema,

18:37

add fields, reduce fields. And then

18:39

of the day, those vulnerabilities or

18:41

hacks or data leakage or data

18:44

manipulation happens because of a stake.

18:47

And so even, so the more guardrails

18:49

you can put even as part of

18:51

the development lifecycle in your CI CD

18:54

are crucial. And the more checkpoints

18:56

that you have, the more protection you will

18:58

have down the road because changes of the

19:00

scheme happens all the time, more than

19:02

you can even imagine, especially in large organizations.

19:05

Okay. So

19:07

the thing is that when you have

19:10

a lot of checks, can

19:12

you tell me a little bit of, do we

19:14

have to have some guardrails for the performance also?

19:16

Or is that suggested trade-offs? No, absolutely.

19:19

It's super important. It

19:24

could cause resource exhaustion or

19:26

DAS and depends. An attack

19:28

that we see, it's a DAS

19:30

attack basically. If you get to learn,

19:33

if you're an abuser or actually it

19:35

happens unintentionally, not as an abuse, intentionally

19:37

abusive call, it just happens. There

19:40

is a change in the backend

19:42

and some field used to cost

19:44

one millisecond, but now it costs

19:46

10 milliseconds because it computes

19:48

on the fly or whatever it is. And

19:51

then a BigQuery is

19:54

calling for this and suddenly there's

19:56

a change and that calls become

19:58

super long. And maybe the

20:00

parcel will fill, maybe the GraphQL servers, and

20:02

maybe the timeout will

20:05

happen and you can cause a DAS

20:07

or you just consuming so much resources

20:09

that is very expensive to your org

20:12

that goes back to that. That

20:15

blind spot, that lack of

20:18

what we start calling field level

20:20

analytics and sub graph visibility

20:23

is the ability to really to trace

20:25

in this

20:27

GraphQL journey. What

20:29

is slow, what is slowing you down

20:31

and be able to have those platform

20:34

teams really have, be

20:36

able to have a database

20:38

conversation with those sub graph

20:40

owners. We

20:43

see this all the time. So

20:45

I think it, so from what I'm saying

20:47

the observability piece is very important. So how you

20:49

set your, what fields you

20:51

query to provide the insights, right?

20:53

To your performance. Yes.

20:56

What fields your users are using or your customers

20:59

are using to query things. Because

21:01

if something costs, costs a lot of time and it

21:05

will be asked again and again and again, 10,000

21:08

times in one query and that query has been sent

21:10

a thousand times in a second. It's

21:13

not hard to predict what's going to happen. Yeah.

21:16

In fact, I think this was the one

21:18

that also was mentioned a lot in some

21:21

of the articles and blogs I read, they

21:23

talked about GraphQL being very

21:26

susceptible to these batch

21:28

attacks. And then people

21:31

are just like trying to brute force these

21:33

batch attacks and then, and then try to

21:35

bypass the rate limiting. So that's something cook

21:37

could you maybe give us an example? Like

21:40

if it's okay to talk about something, where

21:42

have you seen an example? I mean, you

21:44

don't have to mention companies, but maybe just

21:46

an example. It's

21:48

hard to admit, but this is where

21:50

your existing API gateway is failing you.

21:54

It's notion to, I'm

21:56

going to give two examples of a

21:58

rate limited for GraphQL. can

22:00

hurt you, then existing tools of

22:03

counting API calls, they don't, they

22:05

don't work for GraphQL. It

22:07

doesn't matter. For GraphQL, when you think

22:09

about rate limiting, you have to stop

22:12

counting how many calls that happen

22:14

versus you need to start counting

22:16

operations and mutations. And

22:19

I will break it into two things to have

22:21

in mind when it comes to

22:23

GraphQL is the first think about field level

22:25

rate limiting, which is the classic example of

22:27

brute force. One API that

22:29

will fly through all of your existing

22:32

security tools can have a thousand or

22:34

10,000 login attempts with

22:37

different passwords. So you

22:39

have a very easy brute force

22:41

attempt that goes undetected without the

22:44

proper monitoring and rate limiting place.

22:46

And you can do this the same with the example we

22:48

talked about before. If we

22:51

know that there is a very expensive field,

22:54

an abuser can just hammer this field in

22:56

one call or again and

22:58

again, again, repeatedly with multiple queries

23:00

or multiple aliases and just

23:02

hammer this field. So that

23:04

is thinking about field level rate limiting

23:06

and why it's important to dive deep

23:09

and understand the intent of the request

23:11

and put some, I guess,

23:13

tighten the knobs on those guardrails

23:16

if it's max aliases or max

23:18

root operations. There's many ways to

23:20

address this problem or rate limit,

23:23

how many times a login can

23:25

happen and if you tie it

23:27

back to what we spoke about before with

23:29

the roles, maybe anonymous users can only

23:31

do five of them in a minute and maybe an

23:33

admin could do a hundred of them. So how all

23:36

of them are starting to work together and

23:38

the other side of rate limiting when

23:40

it comes to GraphQL is start thinking

23:43

about cost-based rate limiting. And

23:45

that means you have to start processing

23:47

the response. Again, very unique to GraphQL.

23:50

Are you counting how many objects have been

23:52

returned and why is this important? It's

23:54

important because you want to protect from resource

23:56

exhaustion. We also want to protect from

23:59

data scraping. And we see

24:01

this all the time when you have maybe

24:03

a marketplace and you have

24:05

a competitor trying to figure out the pricing

24:07

that you have there just like hammering your

24:09

listing. So by

24:12

monitoring those heavy objects you

24:14

count how many objects have been returned

24:16

per user per role and if

24:18

you want to take this to the extreme. You

24:20

can also have a dynamically

24:23

assigned weight, meaning if

24:25

you realize that specific queries started

24:27

to be more expensive because field

24:30

again fields change all the time

24:32

databases change all the time. And

24:35

if you can have something fully managed that

24:38

you can detect, oh this field

24:40

is something more important, you give

24:42

more weight to that more credits

24:44

you can arguably say and then

24:46

you can constantly monitoring and keep

24:49

your health state of your

24:51

ability of GraphQL in a good shape.

24:55

Wow, that's really good.

24:57

That's very insightful. I think one of

24:59

the things to just take away from that is there's

25:01

also this. There's also this another attack sector

25:04

called broken object property

25:06

level authorization. So just

25:08

just one of the examples that

25:11

what I wanted to ask, I thought it'd be good to ask

25:13

with an example and then take you through it because

25:15

I think this is one way you know

25:18

you haven't suppose you have an example of

25:20

an online marketplace that offers like you have

25:22

two types of users like a host who's

25:25

used to rent out their apartments and

25:27

another type of guest who actually wants

25:29

to stay there. And some of the things

25:31

that there's usually like a call which

25:34

says like approve booking to the

25:36

person who's renting out their apartment and

25:38

then the payload would be like something

25:40

legitimate like approved is true comment

25:42

is check in after 3pm and

25:44

suddenly this is one thing which I saw in

25:46

some of the blogs which said that they

25:49

add another entire new field to

25:51

the JSON structure like a malicious

25:53

payload saying they modify the

25:55

price what was just supposed to be an

25:57

approval API now just has like an extra

25:59

field And then that suddenly

26:02

bad money is gone from this person,

26:04

right? So like these kind of things, can you

26:06

talk a little bit about also

26:08

this kind of property level authorization

26:10

that we need to have here? It's

26:13

a great example. And again, I

26:15

would assume it happened because of

26:18

efficiency, trying to move fast,

26:20

trying to empower, maybe there's an admin

26:22

function that they use, and suddenly it

26:24

was exposed. Suddenly the tree is exposed,

26:27

even if it's inspection is closed, there's

26:29

many ways like fuzzing and others to

26:32

know what's really a perfect option. Options

26:35

are with the mutations or with the query. The

26:39

way we think about this at Inigo,

26:41

it really ties, goes to the enforcement

26:43

of role-based access control. And role-based

26:45

access control is very, could be very,

26:48

very deep. It could go all

26:50

the way to a field level. Do I want

26:52

to expose an email? Do I want to expose

26:54

a name or a last name or an SSN

26:56

based on the role? It

26:59

can also be an attributes in

27:01

the mutation arguments, meaning

27:03

that in this example, when

27:07

someone's calling a mutation and trying

27:09

to enforce in the argument, the

27:11

variable, there's not supposed to be there.

27:13

First, that variable will be rejected. And

27:16

lastly, you can also, and that's

27:18

another common attack. We didn't talk about this,

27:20

which is exposed. You can also put injection

27:23

in any free form aspect of

27:25

GraphQL from operation name to alias

27:27

name to a variable information. So

27:30

how do you run validation against

27:32

any input field? It's

27:34

also critical to put. So we've

27:36

been talking like for 30 minutes

27:38

and we just exposed a lot

27:40

of different vulnerabilities of GraphQL. And

27:42

the more the conversation deepened, more

27:45

things surfaced. And

27:47

it's really challenging to chase them

27:49

because at the moment you thought

27:51

as the champion of GraphQL that

27:53

you're bringing new technology into your

27:55

org and suddenly you're deep into

27:58

a conversation about, hey. How

28:00

do we operate this at scale? How do we secure

28:02

it? And you might

28:04

not have that expertise in your org. And

28:07

we see, we've seen companies,

28:10

again, the very, very large scale

28:12

companies have dedicated GraphQL developer teams,

28:15

which is very, very expensive. You think about this,

28:18

but the reality is that the

28:20

first movers of GraphQL had to, the

28:23

first enterprise movers of GraphQL. We

28:25

can name Coinbase, we can name

28:27

Reddit, Wayfair, GitHub. Happily or not

28:30

happily, they had to invest a

28:32

lot in those building blocks and

28:34

created a lot of innovation, which is phenomenal to

28:37

see. To kind of take

28:40

it back to the community-led effort for

28:42

doing a lot of this innovation, can

28:44

you tell us any of the kind of good tools

28:47

that came out of these community-led

28:49

efforts to find out these GraphQL

28:51

issues? There's

28:53

a lot of post blogs, blog

28:56

posts, blog posts, a lot of blogs,

28:58

a lot of tools, there's a few

29:00

open source tools out there. Unfortunately,

29:03

sometimes those tools are attached

29:05

to the specific implementations or

29:07

the programming language they were

29:10

written at. There

29:12

are some commercial solutions out there. There's

29:14

some free solutions out there. We're

29:17

seeing, I think this is just very, very

29:19

new. In a year or two, we've

29:21

seen a few open source attempts

29:24

to create a layer that

29:26

does some sort of

29:29

gatekeeping around GraphQL queries.

29:33

Some of them do a good job, some

29:35

of them are still early, but that's great.

29:37

It just means there's more education about this.

29:39

And we're also seeing the communities around them,

29:41

around GraphQL implementations, starting to add a little

29:44

more rules about what is possible, what is

29:46

not, which

29:48

is, I think the phenomenal for those

29:50

who are getting started. Because off

29:52

the shelf, they can find something that can

29:54

help them. Questionable

29:57

if these are enterprise grade

29:59

solutions. So is

30:01

there any recommended scanners that developers can

30:03

use? I

30:06

will hesitate to answer this question. I don't want to

30:08

put scanners examples

30:10

out there for people to be abused.

30:13

I would say that you

30:17

can think about a scanner

30:19

that runs against your GraphQL

30:21

that find vulnerabilities. That's

30:23

a great option to include as part of your

30:25

CI CD. My

30:29

worry with those scanners is

30:31

that they need the counterpart.

30:34

They need the ones that actually also

30:36

run in your production that can force

30:39

real-time protection. And

30:41

that is the key of

30:44

how are we thinking about GraphQL security. A

30:47

real-time ability to

30:49

address, to protect, to monitor,

30:52

and alert. And

30:54

those scanners, they're great as

30:57

part of your development

30:59

life cycle. But

31:01

how do you get a slack alert when

31:03

your most critical mutation is failing again and

31:05

again and again? And I

31:07

think this is the

31:10

existing pain that

31:13

GraphQL owners at scale are

31:16

challenged with. How

31:18

do they know? They

31:21

don't. Unless they invest

31:23

heavily. But the investment,

31:26

do you have any examples where the investment is

31:28

worth the price? Is that what

31:30

is stopping the teams from investing? Because

31:32

I think you gave us some great examples, but they

31:35

seem to be like you really need to inspect

31:37

every field. And you need

31:39

to go through to find out a lot. Think

31:42

behind every field that you put in what are

31:44

the guardries. And sometimes that might kind of slow

31:46

you down. It does

31:48

slow you down. And it does

31:50

create some resistance. And it does

31:53

create frustration and roadmap slowdowns. As

31:55

engineer leaders are facing this responsibility of

31:58

a new stack. What

32:00

we all do is like hey what do

32:02

we already have that can work with graph

32:04

kill i have this. Apogee

32:08

or have this gateway

32:10

is like what can they do for me with

32:12

graph kill well very little and

32:15

then they think about performance monitoring

32:17

that we touched before everything about

32:19

observability is it just gonna put

32:21

my. Splunk or data

32:23

dog and just send everything to

32:26

everything to all the logs

32:28

to it super expensive and

32:30

again not everyone of your developer team

32:32

have access to it. And

32:35

it doesn't do a good job in providing

32:37

that that field level. And

32:39

then you start say as your organization

32:41

as your graph evolve your organization will

32:43

evolve with it start thinking about.

32:47

Composition and registry and

32:49

your platform teams will get super frustrated

32:51

with developers changing things is that I

32:54

start to enforce linting. First

32:56

start to enforce rules so how do you

32:58

get all of this as part of your

33:00

API management developer lifecycle see I see the

33:02

how do you get all this component and

33:05

suddenly you have to deal with a lot

33:07

of things. What's great to

33:09

see is companies coming up

33:11

from the graph kill space like an ego

33:13

to the trying to think about like an

33:15

elastic solution. That like hey let's

33:17

connect all the dots let's

33:19

sit very close to the graph kill server

33:22

and let's think about and this is this

33:25

is a new concept let's think about graphic

33:27

your management. What

33:30

does that mean what does that mean to your

33:32

work can we answer basic

33:34

questions about our graph kill API then you'll

33:36

be surprised to know that like when you

33:38

ask like how many graph kill API calls

33:40

do you have or how many unique graph

33:42

kill people struggle to answer this question it

33:45

shouldn't be a hard question to answer. So

33:51

when you think about recommendation or come to this

33:53

like really ask your existing tools or the vendors

33:55

you work with. What

34:00

can they do for you when it comes to GraphQL?

34:03

What we often see is

34:06

not too long after trying to enforce REST

34:09

tools through GraphQL, we see that it

34:11

doesn't work. And that caused a lot of

34:13

frustration. And now you have to ask

34:15

yourself, what do I do? So the

34:17

first years of GraphQL adoption, the

34:20

first enterprise movers of GraphQL went

34:23

home growth. Let's build this ourselves.

34:26

But you can learn from this, and you can learn from what you've

34:28

done. And what

34:30

can be productized, what can be generalized, and

34:33

can actually work for your organization. And you might

34:35

not need all of this. You might only need

34:37

some of it. But these are conversations

34:39

to have with your team. I

34:41

think one more thing I wanted to ask you before I

34:43

go into the GraphQL deployment

34:45

piece, was one of the

34:47

other attack, which was the denial of

34:50

service, which is also something we didn't

34:52

talk so much. I mean, I think you kind

34:54

of briefly talked about it in the introduction.

34:57

Is it really true that GraphQL

34:59

is most susceptible to denial of

35:01

service attacks? It

35:03

is very susceptible to attacks. More

35:07

probably, yes, because it exposed more.

35:10

There's more steps in the way

35:12

that could be attacked. The

35:15

parser itself can be attacked. The business

35:17

logic can be attacked. And then you

35:20

have the database connectivity that can cause

35:22

data leakage or expose, or data manipulation,

35:24

which in some cases is worse. GraphQL

35:28

responses could leak information,

35:31

even if there's errors, and some

35:33

implementation returns to stack, or

35:36

hence PII in the error response. You

35:39

have to think if introspection is

35:42

a risk or not. There's two

35:44

different schools for that. One

35:46

classic example that we like to give about

35:49

the spec attack, things

35:51

that don't exist in REST. Directive

35:54

attack. What happens if you

35:56

overload a parser with directives

35:58

that don't exist? And I mean, thousands

36:00

of them, I'm doing something that's trying to

36:02

be abusive. This could spin off the parser,

36:04

it can overload the system. And you have

36:06

a DOS attack, even before one line of

36:08

your own code was executed. So

36:13

directive attack is a very common and nice

36:15

attack that we like to share because it's

36:17

very easy to replicate. But

36:20

you have batching attacks we mentioned, alias

36:22

attack that we mentioned that can do

36:24

DOS, field duplication can cause DOS, directive

36:27

overloading, nested queries, things

36:30

people don't talk about a lot, these nested

36:32

fragments, super easy to do.

36:35

And the list goes on. And those are just

36:37

whole new set of challenges that exist just for

36:39

GraphQL. Wow, so then I

36:41

think we have to talk a little bit about the mitigation

36:43

strategies. So one of the things

36:45

I learned when I reading a lot of these

36:48

blogs on the mitigation strategy was to

36:50

limit the depth of the queries. What

36:52

is your take on that? Can you explain that? And

36:55

it's just the tip of the iceberg to limit

36:57

the, you should, you should limit it

37:00

unless you know someone is using it. So

37:02

it ties goes back with like, are people

37:04

using it? Do our front end developers actually

37:06

using it? If you harden

37:08

it too much, you're harming your own

37:10

developers from using it. So you

37:13

have to have a balance between knowing

37:15

how it's been used before limited. So throwing

37:18

a few that depth, height, yeah.

37:22

No, those, I call this knobs like handles.

37:24

You want to control how much people can

37:26

play with it. Alias is

37:28

directive. What characters are

37:31

allowed for injections and operation

37:33

name. Something we love to do

37:35

is to force operation name because

37:38

it kind of could hint the intent

37:40

of the sender. And this is not

37:43

for intentionally abusive calls, but an abusive

37:45

call happened by your own team. If

37:47

you have the intent, you know, who's

37:49

doing this. And max request size, max

37:51

request response or time, how

37:54

long it took. If you see

37:56

a specific query took five seconds, maybe next time you

37:58

want to allow it. to

38:00

also start relying on historical data

38:02

to make decision moving forward. You

38:05

want to maybe block GET

38:07

requests and only prove POST requests.

38:10

A lot of handles you want to make sure

38:13

they're all locked and tied. And you

38:15

might want to complete have a set

38:17

of rules between the roles. Cause you want to

38:19

allow your admins or the developers free

38:21

access, but in

38:24

production, you want to do more type.

38:27

That's really cool. That's, I think these

38:30

are all very valid mitigation strategies that

38:32

I'm saying. So just being very superficial and

38:34

saying just limiting the depth is not. Oh,

38:37

not at all. Yeah. But if

38:39

two years ago you would Google

38:42

GraphQL attacks, you only see three

38:44

things depth, height, and plus one. There's

38:47

much more. I would say

38:49

if we're talking about mitigations, the

38:51

way you can think

38:53

of optionally think about this is some

38:56

abstraction you have to

38:58

think about the Corey coming in, let's

39:00

call it Corey protection. Does it look right?

39:03

High depth directives. Does it

39:05

go through the standard of

39:07

Corey's they willing to accept.

39:10

The second thing is it accessing

39:12

the right fields. So think about access control.

39:15

Can it access the right fields based on

39:17

the role, based on the identity of the

39:19

sender. Then you

39:21

start thinking about rate limiting. And

39:24

say, okay, are we going to allow this

39:26

user who asks so many questions or

39:28

did to get more information or they're using

39:30

something we're not going to allow. We allow

39:33

only 10 login attempts and they're sending 20

39:35

login attempts in one call. And

39:37

then when processed, look at the response.

39:40

What's in there? Let's start counting how many objects

39:42

has been returned. So the next time they're reaching

39:44

out to us, we say, Hey, you already asked

39:47

us too much. Or

39:49

maybe it's time to evaluate the

39:51

internal dynamic cost of the, how

39:53

much actually cost us to response

39:57

to this query. And

39:59

if you go to the extreme. When

40:01

you're in a completely financially or governed

40:03

environment, maybe you should search for

40:05

PII in the response. Either a

40:07

specific field or in the air response, this

40:10

is a very expensive task to do in real time. So

40:13

again, I have to be

40:15

very mindful about what security rules

40:17

are put. Now, we

40:19

are talking about GraphQL in its open

40:21

form. This does not align

40:25

with everyone. If you

40:27

don't have to have a

40:29

completely open GraphQL introspection schema,

40:32

if you have a strict

40:34

client server situation, yeah,

40:36

those things should not be open. And

40:39

you should really find a very good

40:41

implementation of operation registry,

40:43

which is funny. It's like you're hardening your

40:46

REST, your GraphQL to look like REST, but

40:48

it makes a lot of sense in

40:50

a client server environment that you're only going

40:52

to allow specific pre-approved queries to come in.

40:55

But it doesn't make it true to

40:58

everyone. So having both of these options

41:00

to you are critical to be aware

41:02

of. So it

41:04

almost feels like maybe it's not,

41:07

I mean, you started off GraphQL to overcome

41:09

the REST challenges, but maybe there are some

41:11

good things from REST that you also need

41:13

to put into GraphQL. Yeah. Okay. Okay.

41:17

I think that the notion is during

41:19

development cycle, everyone should just move

41:21

as fast as they can. And

41:24

in production depends on

41:26

how you interact with your customers

41:29

or your developer, client server, app,

41:31

whatever, mobile, website. Then

41:34

you can enforce different rules or different

41:36

strategies or mitigations approaches.

41:39

And that's fairly depends on how your

41:42

org is leveraging GraphQL. Some

41:45

don't expose GraphQL outside at all and

41:47

use it as an internal data

41:50

hub so teams

41:52

can interact with. Yeah. In

41:54

fact, based on this, I had a question because I came across an

41:56

article which said GraphQL is not meant

41:58

to be exposed to. over the internet. So

42:01

what are your thoughts on that? It's

42:05

a fair argument. Like

42:09

if you want to strip down what it

42:11

does, it's basically SQL to the world. Anyone

42:14

can ask you any question and you

42:16

want to allow it or not. And

42:19

we're seeing so many different examples and

42:21

companies thinking about this. The example I

42:23

gave before, when GraphQL is an internal

42:25

hub of data and you have

42:27

multiple teams that get REST requests, but

42:30

everyone sends internally a GraphQL

42:32

request to figure out to

42:34

reply. That's all valid.

42:36

I don't think there's one way to go.

42:38

I question the people that say there's only

42:40

one way to go because that's

42:42

how great innovation, that's not how you move

42:44

fast. You have to move fast, you have

42:46

to make mistakes and learn from

42:49

them and learn from examples that

42:51

exist out there, tools out there. We

42:53

don't invent everything from

42:56

again and again and again, not to invent the wheel, but

42:59

you still have to try new stuff. So I'm

43:02

not saying GraphQL should be

43:04

exposed for some companies and for

43:06

some companies that shouldn't. It really

43:08

depends. On your particular use case,

43:10

your schema, what you're trying to expose and all of that

43:13

thing. No, and how mature

43:15

your engineering team is. Because

43:18

some companies are like super technical and want

43:20

to innovate and some companies move at a

43:22

different pace and they want to try things

43:24

out in a more safe place, they want

43:26

to make risk. We're seeing

43:28

even legacy companies that used to

43:30

use soap are moving, saying,

43:32

okay, it's time to replace our stack. And

43:35

now GraphQL is mainstream. It's

43:37

a very good alternative based on their use

43:39

case. But you still want

43:42

to move in phases, maybe not exposing

43:44

GraphQL to the world. It's part of

43:46

your adoption phases as your org is

43:48

shifting. And down

43:51

the road, you might be willing to

43:53

say, oh, we're mature enough. We're ready to expose it. It

43:56

really not only depends on the type of company

43:59

you are, but also... So where are you in

44:02

your journey of GraphQL adoption? And

44:05

we meet companies and all sorts

44:07

of adoption phases of

44:09

GraphQL. The way we map it

44:12

is you have the ones who explore. They're just

44:14

like, let's find our

44:17

first GraphQL project, our first server

44:19

implementation, let's connect this to all

44:21

these databases, and that's great. And

44:24

then you have the second wave of

44:26

phase of like, let's put some safeguards

44:28

for our developers, and let's

44:30

start talking about schema checks, and

44:32

maybe operation registry, and maybe linting.

44:35

And then you also have a phase of acceleration, when

44:38

you really want to like, advance

44:40

monitoring, think about performance,

44:42

maybe think about subgraph, and

44:45

think about how do we, how do we

44:47

make sense of all those errors that happen in our

44:49

system, and do we have some sense of health check?

44:53

From there, they might or might not

44:55

move to the intelligent phase. We're

44:57

like, is there any BI in all this

45:00

traffic? Can we have alerts? Can

45:02

we have anomaly detection? Can we

45:04

identify how the schema changed over time?

45:08

And the last one, you might find your

45:10

spot, that the adoption journey does not mean

45:12

you have to complete it. It's like where

45:14

you are at the stage of your company

45:16

might be fine. The last one is really

45:18

governance and compliance. Like this is

45:20

a free nature API. Do

45:22

we know who can access what? And

45:25

can we answer during an incident who

45:27

actually access what? This might

45:29

not be a problem for most organizations. So

45:33

five steps of adoption journey that

45:36

not everyone needs to go through, and not

45:38

necessarily the specific order. Okay,

45:41

there are some interesting takeaways there.

45:43

I do see this whole piece

45:45

on the observability piece, which you said it seems

45:47

to be like a big thing. Exactly

45:49

knowing who is using your GraphQL

45:52

API, how it's being used, which is

45:54

really starting out through a lot of

45:56

the advice you're giving. The next

45:58

question is, I wanted to ask about... of this GraphQL

46:00

deployments, can they be secured? Because

46:03

I think, I remember reading this

46:05

article from you which

46:07

says DevSecOps must turn the

46:10

tables on GraphQL API attackers.

46:13

So can you tell us a little bit about

46:15

this? I, let's go

46:17

back to that Kubernetes example that we

46:19

started with saying like it started with

46:22

developers, it brought to DevOps team and

46:24

then the security teams realized two minutes

46:26

later, hey, what is this?

46:28

How do we secure it? How do we have monitor it?

46:30

How do we gain control over it? What

46:32

is it exposing? And really a whole

46:35

ecosystem of Kubernetes security came around. So

46:38

we are at the phase of GraphQL

46:40

adoption that it does not need to be

46:42

an afterthought. You can

46:44

from day one, even if you don't have a federated

46:47

environment, even if you're just starting

46:50

from day one, you already

46:53

now can have the knowledge,

46:55

the educations, maybe the tools

46:57

from day one to set your team for success.

47:00

But the reality is that the CISOs don't

47:03

know much about GraphQL today. They're

47:06

like, what do I have a GraphQL server?

47:09

They're like in this discovery

47:11

inventory phase. And

47:15

when there will be a massive incident of

47:19

GraphQL down the road, people

47:22

will wake up. So

47:25

as you are representing your org, at what

47:27

stage you want your company to be when

47:29

they're gonna come for you, your

47:31

own DevSecOps or your own security use, how

47:34

is your GraphQL security posture looks

47:37

like? This is just

47:39

an internal, my goal here is to

47:41

encourage everyone here to have an internal

47:43

conversation internally with their own team.

47:46

What is our posture? And

47:48

that's it, just a conversation like this alone will

47:51

take you 80, 20, will take you far way

47:53

down the road than you are today. So

47:56

that is the goal of this like

47:58

pieces, this blog. post that

48:00

we're releasing, encourage education, encourage discussions,

48:02

because you already have a lot

48:04

of smart people. I'm sure of

48:07

it. Bring them to the table to

48:10

discuss this new technology

48:12

we all love to introduce to you.

48:15

Okay, so just to get back

48:17

on the deployment piece, so you're

48:19

saying that the maturity should be

48:21

the same way, like how the

48:24

Kubernetes, that whole ecosystem, how

48:26

that developed, is that what you're saying? Is

48:28

it like that? Is it at that stage

48:30

or are you saying that we need to

48:32

get better? Both, both,

48:35

I guess. I think

48:37

there are things everyone

48:40

can now include in their

48:42

CI, CD deployment model that

48:44

can harden in their deployment.

48:46

You could run a scanner

48:48

against your GraphQL. You could

48:50

write QA scripts that

48:52

try to access fields they're not

48:54

supposed to. You should ask

48:56

yourself is introspection open or not. You

48:59

should ask yourself about breaking anything. All

49:01

those rules, you should be able to

49:04

identify that the change in the schema

49:06

is not breaking production because

49:08

you removed the field or because

49:11

it used to cost one millisecond and

49:13

now it's 100 milliseconds and you realize

49:15

this part of your test development. So

49:17

this all needs to happen, ideally happen,

49:20

in a robust deployment model early

49:23

before it hits production because

49:25

of all the challenges we talked about. The

49:28

earlier you find it, like in anything else, the

49:31

better the posture is. Okay. I

49:34

want to ask the question, like I think just to kind

49:36

of try to marry in

49:39

a lot of the things that you said.

49:41

So do you have any top three recommendations

49:43

to prevent GraphQL attacks? Okay.

49:47

First one is observability, for

49:49

sure. You have to elevate

49:53

those field level analytics, elevate

49:56

sub-graph visibility, elevate

49:59

errors in your system. Do you even know

50:01

when subgraph are returning errors about authentication? Is

50:03

someone trying to access the field? You

50:06

notice. So first, remove

50:08

the blind covers and

50:10

get intimate with

50:12

your GraphQL traffic. That's

50:15

the first thing I would recommend. Second

50:17

thing I would recommend is the really bare

50:20

bone of query protections. Put

50:23

some knobs around how queries should

50:25

look like and what does it

50:27

do. And

50:29

the third will most likely be rate limiting.

50:34

Going back to the inbound

50:36

rate limiting, give rules

50:39

on how many specific fields can be asked in

50:41

the query. And that's

50:43

a good baseline to start. And

50:45

then you can have more advanced rate limiting once you have

50:47

this in mind. But just make sure

50:50

the classic brute force attempts are

50:52

prevented per query before

50:55

starting having a Redis

50:57

database that starts calculating rate limiting

50:59

across the Earth. These are more

51:02

advanced things. More advanced things.

51:04

But you have to start somewhere. So these are the

51:07

three things I would recommend. Know

51:09

what's going on, which is observability. Put

51:12

some controls of how a query should look like.

51:15

And top level rate limiting when it comes

51:18

to field level. Okay,

51:20

that's great. So I guess

51:22

the last question I want to ask you and

51:24

I want you to spend some time is to

51:26

tell us what exactly your company does in

51:29

this space in the GraphQL ecosystem

51:32

and how is it helping adopters

51:34

of GraphQL? When Inigo

51:36

started, kind of looked at the

51:38

GraphQL ecosystem and

51:41

we saw this like tremendous developer

51:43

and open source efforts to

51:46

get started, build a lot of

51:48

GraphQL servers, focus on database connectivity,

51:50

allow people to get started. At

51:54

the same time, we saw those enterprise

51:56

first GraphQL movers struggle

51:58

to put this in production. because a

52:00

lot of the topics we talked about

52:02

today, we talked about security, observability, maybe

52:04

schema management, what does it mean to

52:06

have schema checks and LinkedIn and

52:09

graphical playground, or

52:11

good implementations of operation registry.

52:15

So we wanted to innovate at that

52:18

space. We wanted to create a layer

52:20

that does all the management there

52:22

that is needed for going to

52:24

get organizations to feel confident with

52:26

GraphQL, that will work

52:29

with any implementation of GraphQL. So

52:31

think about it, so we built some

52:34

sort of a middleware integration that will

52:36

work with any open

52:38

source implementations of GraphQL from

52:41

JavaScript to yoga, to Ruby,

52:43

to Apollo server, it really

52:46

doesn't matter. And once

52:48

it's connected to it, it provides all

52:50

the building blocks you might need for

52:52

your platform teams, for your GraphQL adoption,

52:54

to really continue this motion of

52:57

journey, and

53:00

then give you that building blocks they're

53:02

needed, that will free you up, even if

53:04

down the road, you need to make changes,

53:07

meaning moving from Python to Ruby, you

53:09

still have a declarative management layer that

53:12

will carry on with you. And something

53:14

that is built up as an enterprise

53:16

grade solution that can

53:18

handle tens of billions

53:20

of monthly calls that have real

53:23

time protection, not an afterthought, that

53:25

gives you the composition and registry

53:27

that really empowers your organization to

53:29

move forward. And we love GraphQL,

53:32

that's what we do every day. This

53:34

is what the team is focused on every

53:36

day, our tools completely reading with GraphQL.

53:40

And we love the success stories, we love to see

53:42

people looking at their field

53:45

level analytics and say, oh, I

53:47

like this, or unique

53:49

notions of air impact. Like we have a

53:51

lot of errors in the system, everyone has

53:54

a lot of errors in their system. What's

53:56

important? How can we help them prioritize it?

53:59

So we'll go deep there. Yeah, I

54:01

think it's been very interesting for

54:03

me also to look at this amount

54:05

of analysis that you should do to

54:07

actually secure your GraphQL API. So I

54:10

think that it's been nice because

54:12

I think you've asked really the listeners

54:14

to dig deep with some great strategy

54:16

on observability, query protection and rate limiting.

54:18

I think those three things I'll sleep

54:20

with that tonight. Yeah, it's

54:22

great. The last thing I need to

54:24

ask you before I let you go

54:26

is where can listeners find you on

54:28

cyberspace? What is your preferred way

54:31

that people can reach you? Well,

54:33

Shahar at ennego.io. You can

54:35

always go to ennego.io. We

54:38

have an active Slack channel. You can

54:40

find me on LinkedIn, find me on Twitter. You

54:42

can email me. It's the best way. Very

54:44

responsive. We love hearing stories.

54:47

We love learning from others because

54:49

people went through a lot. Whatever

54:53

we can generalize, productize and

54:55

give, we have a

54:57

very generous free tier. So wherever we can

54:59

give back to those who are starting or

55:01

have a startup and growing, one

55:04

piece of mine when it comes to GraphQL,

55:07

we love those success stories. Great.

55:09

I'll make sure to add that on our

55:11

show notes. That is your LinkedIn profile as

55:14

well as the Ennego site that I already

55:16

have. This has been great.

55:18

Thanks for coming on the show, Shahar. It

55:21

was a pleasure Priyanka. Thank you for having me.

55:23

I really enjoyed the conversation. This

55:26

is Priyanka Raghavan for Software Engineering

55:29

Radio. Thanks for listening. See

55:55

you next time. S.E.

56:00

Radio is licensed under Creative Commons License 2.5.

56:04

Thanks for listening.