All EventsGraphQL API Security with Hasura
Webinar
Aug 19, 2021
9 AM PST- With great power comes great responsibility. GraphQL gives immense benefits to API consumers but that also means additional care must be taken to prevent any accidental or intentional misuse of the API. Especially if your application or API is public facing, then GraphQL security should be of utmost concern to you.
- In this webinar, we will walk you through the suite of security features available on Hasura Cloud including a set of new enhancements launched in the latest Cloud release v 2.0.3.
- These features help you secure your production application, and safeguard your app against injection attacks, DDoS attacks, excessive data exposure, and more, whether malicious or accidental.
- We’ll be covering the following features:
Depth limit- Node limit [new]
- Rate limiting
- Disabling Introspection [new]
- Allow Lists
VIEW RECORDING
Jesse
So today it's GraphQL API security with Hasura, and we're going to go through some, it's almost more like a feature walkthrough because Hasura actually makes this so much more straightforward and simple to implement that it's... We're going to talk a little bit about the problem that it's trying to solve and then how to solve them. We're going to not take a ton of time. It's going to be probably just about 30 minutes to go through all these different pieces. And then we're going to hopefully have a lot of Q&A at the end. So definitely hit that Q&A feature here on Zoom. And we'll be going over all that stuff in just a little bit. So before we do that, I only have just a very small handful of slides. We're going to go ahead and hit this off real quick. And that will allow us to have an idea of where we're going with this, this morning.
Jesse
So basically API security, it's not just hackers, if you are not aware already. So obviously API security, when we're talking about that internally here from Hasura, we're talking about both the threats that are going to be external. So people who are actually meaning to do ill and also the ones that are your users who are potentially just not misusing your API with good intentions, but potentially it is happening poorly. I do see somebody is attempting to raise their hand in chat. So I would just say if you have a question, why don't you pop it in that Q&A feature for Zoom, and I'll be able to get to that as quickly as possible. So definitely use the Q&A, or just write your question down in chat too if you can't find the Q&A function. So API security, it's all about actually protecting your APIs from all kinds of misuse, whether it be malicious or non-malicious in nature.
Jesse
And when we go through it today, we're going to be covering five specific function features of API security. We're going to be doing depth limits, which is a notorious issue with GraphQL-based APIs. We're going to talk about node limits. We're going to talk about rate limiting, disabling introspection, and using allow list for our APIs. Pretty straightforward features. I think you're going to be really happy to see how simple they are to implement, but what's not going to be included in today's talk is model-based permissions, role-based permissions, CRUD checks, and caching or logging. Those are actually included in the API security topic as a whole, like they actually belong to that conversation to some extent, but we're not covering those in this talk. I do want to make a little shout out to a talk that was given by my boss or CEO.
Jesse
So we do have a recent talk on model level authorization system for GraphQL with Hasura. Very great talk. It goes through a lot of the detailed portions on that model-based security. So if you haven't seen that one, I do highly recommend that you watch that when you have a chance, because that was already in the past, but it's very straightforward, very fast-paced, 30 minutes, and it will definitely get you rolling quick on that topic. So coming up next then, we're coming back to these five steps of securing our APIs. And they sort of fall into two primary buckets that we're trying to be concerned about in this case. And that is our API resilience against DDoS attacks of different types or DDoS like attacks, and then we're going to be talking about protecting against excessive data disclosure, which is a very tricky problem to solve, especially in GraphQL land or any kind of a graph type API. But this is something that we are trying to address very specifically.
Jesse
And to begin with that, what we actually need to discuss is observability where we have permissions and performance, which is kind of these two top level breakdowns for how we're going to approach the API security and hardening our API, where we need to be able to say, okay, what are the actual permissions what to watch when we're looking over all of these details, how do we make sure that all of our settings are correct? And then is this actually functioning the way that we would expect? And that leads us then to, yeah. That's the last slide.
Jesse
So that's basically how our approach is going to be. We're going to have a look at the actual console. Our entire time remaining here is going to be spent directly inside of the API. And we're going to just have a walkthrough together, have a look at what's in there and how do we address the five points that we had addressed earlier on. So without any further ado, we're going to go ahead and hop over into the console here. What I'm going to do is pull it off my slides from the side here, so I can make sure that I'm the getting all of our pieces. And you should now see the Hasura console. If anybody could confirm that in chat, that would be great.
Jesse
Great, great. Everything is still working as expected. So what do we have here this morning? If you can see the name of the actual project, this is a Hasura Cloud project. If you can see the name of my company, it's called Contrived Corp. That is basically saying that this is a complete minimalist reference for us to sort of look at how do we harden this API. So we're going to look at a model here that we've defined. We're going to go ahead and do a quick look at the actual tables here. So we've got fleets, we've got users, we've got journeys, we've got automobiles and trains, planes, trains and automobiles. So we've got this sort of a Uberesque kind of model here. Not super well like, thought out, this is simply helping us be able to have a look at how do we go ahead and harden down this API from abuse and make sure that our users are able to work well with this.
Jesse
Okay. So let's go ahead and have a look at a couple of requests here. So starting off, I'm going to go ahead and make this nested query thing here. So we're going to go ahead and first talk about depth limits on queries. So what we have here is, I'm sure I can make this a little bit taller here. There we go. Is that Zoom level okay? Or do you need that to be a little more zoomed in? See if anybody in chat's saying it's okay. Maybe if can go one more on it just to make it a little bit easier to read. Okay. So it seems like it's okay. Okay. All right. So what we have here now is we have this top level journeys and then those journeys have drivers and they also have passengers and the passengers have user details, including the journeys that they've been going on.
Jesse
And then you'll notice that we've got sort of this recursion loop now happening in our querying where we're saying, "Give me the journeys, the drivers, the passengers, their journeys, the journey details, the driver of those journeys." And we can just keep going and going and going. And this is one of the issues with GraphQL, right? So I can go ahead. I've defined this reflects a relationship between my models. I can actually just keep going. Okay, journey details, more passengers, more passengers journeys, and down and down and down it goes. This is not something that's necessarily always done maliciously. This could be somebody who's trying to avoid fancy state management in an application. But when we run this, we can see that it's going to run, but this is just not a very optimal way to be actually accessing our database and to be querying our content.
Jesse
So what we can do is we can enforce a restriction here to say that there's going to be a depth limit for how many levels a person is allowed to requests for this content. To do that, we're going to navigate to a newer tab. If you haven't seen it yet already, it's been in cloud for a little while. We're going to go to the security tab. And the security tab allows us to be able to see what permissions we have available. So I'm going to go ahead and actually set my global here, an actual depth limit where I'm going to go ahead and enable this. And I'm going to say that the total depth can actually only be two levels of nesting down. So I'm going to go ahead and turn this on. I want to save this setting. And so now we'll see, when I look at this sort of overview, this observability page, where I had this overview, that on that depth limit, I've already got a global now defined here.
Jesse
So if I head back over to my API, and if I go ahead and run this again without the admin secret turned on, I'm now remembering that I probably have failed to turn on my anonymous user role. I have. I have to go ahead and turn that on here real quick. So we're going to make a new user here for the tables. And I'm going to go ahead and say permissions. I will say, without any checks for the, insert, that would be a bad idea. We're going to go ahead and unselect here. Potentially for the sake of speed here, I may just go ahead and limit myself. Let me go ahead and see if I can actually just limit the admin secret here. That I haven't tried before, but I might save a, just a hair of time. So I can't do that.
Jesse
All right. So I need to just go ahead and enable these here real quick on the API. So we come back here to our anonymous user role, and we're going to go back out to the project here to go ahead and turn on the anonymous user. So if we go to the project that we've created. Go ahead and go to our settings on this. I'm going to go to the environment variables. We're going to go ahead and turn on our anonymous user as Hasura unauthorized role. And we're going to just call this anonymous. Now that's going to have to just reboot the console here for one quick second while we're enabling that. Now that that's enabled, we can head back over to the console and we'll just copy these permissions here across our tables. So permissions, we're just going to put select on there. And they can do that without any checks. And we'll toggle all on, and we're just going to clone that for planes.
Jesse
Actually, I was cloning the [inaudible 00:11:40]. So we're going to go ahead and say fine, anonymous. So I'll find save permission. I need checks. Toggle all. It should allow me to just save that. I'm missing something here. Let me have a quick moment to look. Are there any checks? Refresh the page here. That shouldn't be getting in my way here. That's my role there. Select. Got any checks. All columns. Okay. Something had gotten a little bit goof there, but all set. Now, we'll go to fleet and I had to just copy these all across because if I don't do that, we're going to have the same problems. So I clone the same from, oh, this is faster. Done any checks. Toggle all. So we're just going to copy the selects across this whole page here. And I'm trying to think through from the API that I'm actually hitting. So I'm hitting journeys, I'm hitting users and I'm hitting fleets and vehicles on here.
Jesse
I do need to copy most of those over here. Sorry for the little delay here, I'm just getting that caught up. If you watch that video from Tanmai, you'll definitely see all of this covered in depth, what all this does. So we're just turning on all these different features where we're saying, "Okay, this role is allowed to go ahead and select all of these different features." Make sure that I do that for fleet. And it's actually going to be helpful for us to see another security feature here. One of the OWASP regulations or recommendations for their top 10 is on permission settings. And what happens in a lot of cases is that you will have like a misconfigured, it's one of, either number three or number four on the OWASP security recommendations. Number four or something is the settings for your API, where it's just difficult to be able to see what's actually working and not working.
Jesse
So when I go ahead and turn all these on here, we're going to see that there's a really nice overview point for us to be able to actually view what the permissions are then across all of our roles. And that's a really helpful security feature as well. So I'm going to go ahead and say these permissions, we only got three more tables left here, almost there. So this is really engaging television here, watching me click a bunch of buttons. So we've got these set here. We've got the user journey. I'm going to go ahead and turn that on. And again, without any checks, toggle all, say permissions. Last one, we're going to go ahead and still turn that on as well. Not probably the thing you want to do for your users. We're going to go ahead and say, we're going to go ahead and get permissions here. I'm going to go ahead and turn this on.
Jesse
In this case for select, we could be, if we had things like email and stuff, we could turn off the individual columns, where we could say, don't show the actual email or something else for the unauthorized user, but maybe you could show a user ID or something, but we'll go ahead and just turn that on for now for unauthorized user role. So I've turned on all these features and if we wanted to kind of have a view of all of that, we can actually come out to our main table here and we can say view the permission summary. And you'll see if I hit on the select statement here that we have for the anonymous role, we have without any checks, all columns. And I have this really great observability feature where I can actually see all of the permissions that are defined for that role.
Jesse
And if I now switch to something like update permit or insert permissions, you'll see that my anonymous role doesn't have any of those. And if you have multiple roles and one of the features inside of Hasura has actually the ability to have combined roles, you can quickly see where that would become super powerful to have one level overview of all of these different features or all these different permissions across all the tables and all the columns just here in one glance. So that's one way to add to sort of a visual audit of your security settings. Let's head back to the API explorer, and we're going to go ahead and turn off that admin secret here now. We're going to go ahead and run this query. And you'll remember that I have enabled the limit. Let me make sure it took, because now that I've added that role officially, so anonymous is still set. So you can see on global here, you can see have the anonymous role now enabled.
Jesse
And if I now switch to something like update permit or insert permissions, you'll see that my anonymous role doesn't have any of those. And if you have multiple roles and one of the features inside of Hasura has actually the ability to have combined roles, you can quickly see where that would become super powerful to have one level overview of all of these different features or all these different permissions across all the tables and all the columns just here in one glance. So that's one way to add to sort of a visual audit of your security settings. Let's head back to the API explorer, and we're going to go ahead and turn off that admin secret here now. We're going to go ahead and run this query. And you'll remember that I have enabled the limit. Let me make sure it took, because now that I've added that role officially, so anonymous is still set. So you can see on global here, you can see have the anonymous role now enabled.
Jesse
And if I now switch to something like update permit or insert permissions, you'll see that my anonymous role doesn't have any of those. And if you have multiple roles and one of the features inside of Hasura has actually the ability to have combined roles, you can quickly see where that would become super powerful to have one level overview of all of these different features or all these different permissions across all the tables and all the columns just here in one glance. So that's one way to add to sort of a visual audit of your security settings. Let's head back to the API explorer, and we're going to go ahead and turn off that admin secret here now. We're going to go ahead and run this query. And you'll remember that I have enabled the limit. Let me make sure it took, because now that I've added that role officially, so anonymous is still set. So you can see on global here, you can see have the anonymous role now enabled.
Jesse
And if I now switch to something like update permit or insert permissions, you'll see that my anonymous role doesn't have any of those. And if you have multiple roles and one of the features inside of Hasura has actually the ability to have combined roles, you can quickly see where that would become super powerful to have one level overview of all of these different features or all these different permissions across all the tables and all the columns just here in one glance. So that's one way to add to sort of a visual audit of your security settings. Let's head back to the API explorer, and we're going to go ahead and turn off that admin secret here now. We're going to go ahead and run this query. And you'll remember that I have enabled the limit. Let me make sure it took, because now that I've added that role officially, so anonymous is still set. So you can see on global here, you can see have the anonymous role now enabled.
Jesse
And if I now switch to something like update permit or insert permissions, you'll see that my anonymous role doesn't have any of those. And if you have multiple roles and one of the features inside of Hasura has actually the ability to have combined roles, you can quickly see where that would become super powerful to have one level overview of all of these different features or all these different permissions across all the tables and all the columns just here in one glance. So that's one way to add to sort of a visual audit of your security settings. Let's head back to the API explorer, and we're going to go ahead and turn off that admin secret here now. We're going to go ahead and run this query. And you'll remember that I have enabled the limit. Let me make sure it took, because now that I've added that role officially, so anonymous is still set. So you can see on global here, you can see have the anonymous role now enabled.
Jesse
So by default, it will inherit the global permissions. Otherwise, it'll take the specific one for the role. So let's go ahead and actually just remove this one or remove that setting for global. And I'm going to simply apply it on the actual anonymous role here. And so I'm going to go ahead and say... Oh, I have to set one for the global first. Okay. So we'll set global, we'll say that generally speaking, the global is allowed to have a depth limit of five, but the depth limit on our anonymous role, we're going to limit down to just two. Okay, go ahead and save that setting.
Jesse
So we can see that typically speaking, all of my roles would be getting a depth of five and then my anonymous would be getting a depth of two. Back to the actual query here. I now come inside here, and I say that my role, and that would also be getting the default here because it's the default environment variable we've defined. I run that query. We'll see that my depth limit has exceeded and I'm not able to query beyond that. There's not some sort of a filtering where I'm making the query against the database and that comes back and I actually filter out the results. This is simply saying, "No, it doesn't work." Non, there is a typo.
Jesse
There we go. But again, I don't even need that because the environment variable is defined that if I'm not authenticated, that role is applied automatically. So I can just run that. Yeah. So we have the depth limit here defined. So in some of our settings, we're able to say, don't allow this level of recursion, where we have the top level API, the next level API, or the next top level model, and then the related model and the related model. And then just creating a loop back in my query structure. That would be a really bad practice that we don't want to enable and or allow. And so in this case, we can go ahead and simply say restrict that.
Jesse
So quicker than it looked, what we had is the ability, we could come in here, if we could simply say on the rule that I want to apply this to, go ahead and apply a specific depth limit. So very helpful feature there. Let's go ahead and look at the actual number of nodes themselves. So a little fun feature inside of GraphQL is for example, something like alias. And what we can do here is we can start to get kind of fancy with how we're querying things. So I'm going to go ahead and make a new query here, and I'm going to go ahead and just call this the multi node query.
Jesse
And I'm going to go ahead and make an aliased query here. So we're going to call this journeys one,. And we're going to go ahead and query journeys query on that. We're going to just get the driver and the driver's name as an example, nothing breaking the bank here on creativity. Now what happens inside of GraphQL, which is kind of fancy, this is just one case where it might arise. You may want to be sort of getting fancy with the shapes of your queries. And if I do things like this, I'm going to go ahead and just define a number of different top level...
Jesse
My mouse is fighting me just a little bit here. I do this. What I now have is I've added a whole bunch of different top level fields now to this query. So I've got every single top level and every single nested field is also a node. So this is now a lot of nodes inside of this one query. Now some cases doing something kind of like this is helpful with aliases, you have the ability to maybe filter down. You can say all east west journeys, all north south journeys, that might be helpful in some context, but it can also be a situation where somebody's trying to get around having the API, do all the heavy lifting for the shape of their data they're trying to request. And potentially if somebody's not even paying for a lot of larger amount of service from your API, you might be just really getting hammered with a lot of excessive work on your server side.
Jesse
So what we want to do is we want to avoid the ability for somebody to do this kind of excessive nodes. And it could be, and this is really contrived here with using as aliases. You could imagine, and going back even to the previous example of all those different fields, if I'm querying the vehicle details and I'm getting all the way down to the VIN number and like the kind of vehicles, the axle and everything, like just really going crazy on the amount of data that I'm pulling from my server, that would be another case where you'd be like, most context of what you're trying to display on the page here doesn't need to have that much detail. So another way that we could kind of restrict this is we're going to go ahead and go back to our security setting, and we're going to actually limit the amount of nodes that are allowed to come back.
Jesse
So doing the same thing here, where we need to actually add a top level node limit for our global settings. I want to put 20. If I go now down to the actual node limit for my anonymous role, I'm going to go ahead and say that I'm going to put a node limit of five. And then I go now to my querying and I run this query, we'll see that I get that node limit exceeded. Now, if I go ahead and remove a whole bunch of these excessive queries now, these aliases here, I think this should be, so one, two, so I should be within my no limit. And I can see that that works just fine. So what I've done here again, is I've, before I've done any kind of performance hit on my server, before I've done any kind of fetching from the database, I've been able to enable a check and say, Hey, you're asking for too many things, and I can go ahead and stop that right when it occurs.
Jesse
These are areas where if somebody's doing at a super in depth query against your API, and in a lot of them, a lot of cases, like all over the place, this will really slow down your server, because you're trying to make your database just do a whole bunch of look up and a whole bunch of connections and joints. And these are two areas where you're going to be able to really protect yourself from both well-intentioned or poorly intentioned users of your API that are going to be really hitting your server in a really rough way. So that's covering depth limit and node limits. The other one that's a very obvious example where we would see a case of somebody potentially abusing this service is if we have somebody who's just querying too often, right? So we're going to go ahead and talk about straight up rate limiting for our service. We're going to call this the excessive query.
Jesse
And if I just go ahead and I run this a number of times here, we're going to go ahead and just fire that off, like a really annoying person here. Now I'm definitely stress testing my own project here, but like, I mean, this is Hasura Cloud, so we handle this pretty well for you. Let's go ahead and look at our monitoring tab and see what's happening here under the hoods. We're going to go to our operations. Look at that nice little spike there on our bar graph. If you go to the operations, I'm going to go ahead and reload this, and we'll see like, oh my goodness, we have somebody who's just really slamming our server, like Tracy, with the same query over and over and over again. We can go in there and see, okay, what's actually happening here. Get some details. We can see, okay. It just seems like there's nothing particularly fancy. Like, this is just somebody who's hammering our API.
Jesse
So what we want to do is we want to protect ourselves against this and limit the ability of this happening again. And again, like I said, we're not talking about caching here. It's pretty many trivial to implement in Hasura Cloud, but we're not going to be talking about caching right now. We're talking specifically about this functionality for API limits. I go back to security now, and my global setting. I'm going to go ahead and enable the rate limits. So request per minute. We're going to go ahead and say, typically we allow one per second. I can go ahead and save that setting. But on this anonymous role, we're going to get ourselves real stingy. We're going to go ahead and say, on the request rate limit, we're going to go ahead and say that we're only going to allow five requests per minute, which might bite me on the next demo.
Jesse
So I'm going to go ahead and increase this to 30, it should put us down to one every two seconds. And I can add on some additional filters here. So I can say when this request is coming from a specific parameter, like a geofield or an IP address block, I can do these kind of limitations here in the settings and say, in these cases apply this rate limiting, which is a very helpful feature to help weed out some of the malicious behaviors against the API. So now we've got a rate limit here, which is going to go ahead and say that every two seconds I should be getting through. Otherwise, I get blocked. If I go back over to the API explorer now. Fire one, that's fine. Give a couple of seconds and I'm going to try again. Fine.
Jesse
See if we've already gotten through there. No, we're still in the same minute. So that's another area where we can really get through. We can lock down our service in a really helpful way. So between these three, depth limit, node limit and rate limiting, those are just by themselves, putting in reasonable defaults are going to save a huge amount of headache in terms of the API resilience against DDoS attacks, also the features of just trying to control who's using your database and how, but there's another area we want to talk about very specifically. And that's on data disclosure. And the model model roles that we actually did a little view on earlier, how we had that grid, we could see each individual role, what their permissions were across these tables. When we did that, that's a huge portion of solving the data disclosure conversation, because we can see exactly what permissions each role has.
Jesse
So if I look for the... I'm trying to, like looking around here in the API, I can see that there's this thing called the interplanetary transportation. That's top secret. So like, I'm adding spaceships now to my Uber offerings. And if you've got a public company that's underneath one specific vertical Coca-Cola for example, and then all of a sudden you see an API endpoint for something that's just like totally out of their wheelhouse, like MP3 players, that's going to be something that would potentially have actual consequences in the markets. And so this sort of exposing all of the endpoints, it's helpful for tooling, but it does fall into the excessive data disclosure category. So this is a case where in a lot of cases you may want to actually turn this feature off when it comes to general access to your API.
Jesse
And we can do that in Hasura. So all we have to do is we come inside to the schema inspection now. And on this anonymous role, we're just going to simply turn that off. It's one click here, or two clicks, by the time we hit save settings, and we've turned off the ability to introspect the schema. If We go API explorer, everything's going to be kind of like a little funky looking because we can't see anything. And that's exactly how we want it. We don't want to have our unauthorized roles being able to view any information about our API. So that's, I mean, there's not a lot more to say about that specific feature, but it is something that is part of sort of a best practice in terms of exposing an API to the public and making sure that you're not getting information about your company outside of the window.
Jesse
There's one other piece there that actually sort of fits in the same space. And to do that, we're going to look at what's called allow list. And I have to turn this on. So I go to allow list here. I'm going to, I think I've already turned this on. Are only enable to be set Hasura. Okay. So yeah, I need to turn this on. So it's the Hasura GraphQL enable allow list. So I come back out to my console here, which I believe I can do just by going to the same projects. We're going to go ahead and open this tab. We're going to just come back out to our project settings. I promise we're just about to the Q&A here.
Jesse
If we go ahead and go to our settings and underneath the environment variables, we're going to go ahead and turn on allow list. And I want to say, in this case, I'm just going to search for the allow keyword here. Enable allow list. We're going to turn this on. And what allow list let us do is they're going to allow us to save a specific query that will actually only be on the approved list of things to query. So if I come in here now and I say on my API explorer, I'm going to go and turn on my introspection now, because it's getting in my way for what I want. I'm going to go ahead and say... Let's turn this back on.
Jesse
If I look at my metrics here and these operations that I've been executing. So I have this excessive query and I have a couple of other ones as well that I've worked with. I ran a lot of those excessive query tests. Let me go to the API explorer and throw a couple other named queries at it. I'm going to go to my history browser. And we're going to show the multi node query here. We'll go ahead and run that one, which I've got my API limits in place. So that's good to see that's working. Let's go ahead and just limit this back down to something that's allowed.
Jesse
Let's see how we get this enabled here. Query is not allowed. The validation failed. Let me just refresh that real quick after I'd saved that changed. Query is not allowed. Did I turn that back on? I thought I had. I have turned it back on, so that's fine. And I go back to my API limits, [inaudible 00:34:42]. So it's complaining still about the introspection query, which is funny. So that might be a little bit of something I need to report, because that actually should be showing up just fine. So I'm going to go ahead and fake around this for now just to show off the allow list features and see what's happening there.
Jesse
But when I go to the history here and I'm going to go ahead and fire off a couple of these additional queries here. So we've got the multi query node, we've got the nested queries. I've fired off just a couple of operations here. What I can do is if I've been building my application and building and for a long time, getting everything put together, I come over to the actual monitoring tab. And when I see the operations that are actually being used, make sure that I get all my examples here, when I see all the ones that are being used, I can go ahead and take this. And I'm going to say that I want to actually make this be one of my allowed queries. So I'm going to go ahead and come into my allow lists. And I want to say from allow... There are no operations in the allow list. I'm going to go ahead and say from my Contrived Corp. Here we go.
Jesse
So from showing the operations from this current project, I'm going to say that I want to allow the nested query and the, in this case I will allow the introspection query as well, but I'm going to go ahead these two, but not the excessive query. I want to say add to allow list. Oh, so that wasn't a bug that I was experiencing. That's really funny. Because I did not actually enable the introspection query after I enabled allow list, it was working immediately after enabling that environment variable. So when I enabled allow list, what it does is it will block any query that comes into the server that's not on the allow list.
Jesse
So introspection query, regardless if I have told it to be turned on or not, will not come through if that is not an improved query. And so now that I go back here, we can go ahead and actually turn this off again. We'll see that it is an allowed query. So we enabled the nested query. So we can go ahead and run, well, we can't run that because it's following a foul of other features. We'll turn on off the excessive... We'll turn this back on. So we'll see that we can do the nested query, but if I try to do the excessive query or even the multi node query, that will not let us go through because that's not been added to the allow list, except for that with Hasura admin secret, it's going to let me do whatever I want. So we'll go ahead and turn off... Right now we're we're violating our query. Here, so we'll just turn this off, but this is not an approved query here. So this will not go through though. We can see that query is not allowed.
Jesse
So in this case we've said, okay, we've done a bunch of testing, we've done a bunch of production. We can see exactly which queries are coming through from our production application. We've identified those. We said, okay, we're going to save just those and allow those to be on our allow list and nothing else. And that is the ultimate lockdown where you're able to say, okay, only the ones that are actually being used and defined in my application are the ones that I allow to even leave the server at all. And that's a really great way to make sure that you're having a secure API by saying, "Okay, looking at my actual real world usage, I'm limiting this down and there's nothing else that's going to come through." And that's a really great way to lock down the API here as well.
Jesse
Okay. There was a little bit of the application working better than I was expecting and having to fix a couple of things there the last minute. Before I opened this up to Q&A for the last just few minutes here, I wanted to point out just a couple of areas where you can sort of get more information on all of this. If we go to the GraphQL API security, you'll see this blog post that goes through a lot of these topics as well. Explain some of the features in detail and the why. And so that's worth having a look at. That's GraphQL API security with Hasura Cloud. If you have a look at the talk that I was talking about from Tanmai that goes through the model level authorization, that's going to definitely give you some more information to have a look at.
Jesse
In general, we also have the ongoing evergreen resource of the production checklist. This goes through a lot of different topics about what's actually good best practices in general, for API security, whether using cloud or not using cloud. And it'll walk you through a how to set up, all of those different features for creating secure applications. All right. That was a lot of talking and a lot of showing. Are there any questions that we can address here before we wrap this up? So I'm going to open the floor now to all of you. So if you have any questions, hit me up. Is the security tab only available in cloud? Security tab is only available in cloud. Yes. And it's because that's, again, part of where the GraphQL security becomes tricky, right? Is node limits and rate limiting, things that have to happen on the server. And those are features that Hasura Cloud just makes really straight forward to just turn on and enable. Otherwise, that's a role your own-
Jesse
Yes, you can get the recording for today's and the other. If you do look at the resource, I think it's, the tab's closed now. Any event, if you go to, I believe it is simply Hasura, we'll just do a search for Hasura events here on Google. If you go to the events page, it's event triggers, here we go. Just the events page, any previous event, you can find the actual recording. So this one, no exception, you'll be able to see it. When you click on here, you'll be able to see the recording. If I go to the one from the model level authorization, you'll see that you just put in your email there and hit view recording, and you'll get that recording brought right up.
Jesse
And if you registered for both of those events or this one, for example, you'll be sent an email. Good question. That I would assume because the metadata controls everything about the console. I would assume that is available through the metadata. And sorry, the question is, all these configurations can be made through the API. Is this metadata? And is it saved when you export it? I do believe so. That I would have to gat back to you, Juan. So I would say reach out to me on Discord or one of our other services or you can email me at [email protected] and I will get that answer for you, because that's actually a good question that I'm not positive on the answer on. I'm not sure if anybody from the Hasura team is on here. They might be able to answer that as well.
Jesse
There is a Q&A question. Is there a way to check existing queries in prod by role? How can we make sure we don't break anything while strengthening security? That is a great question. So there is a couple of paths there. So if we go to the explorer here, so one thing you can do is if you go to the regression tests, what you can do is you would say, see your nodes, tests that you found on this project. We'd have to go ahead and create a test suite. Getting a little bit out of the scope here, what you save one of the operations. So for your production project, you save the operations that are going to be indicative of not breaking or breaking your project to your test suite. Any changes you make to the project will run against that regression test. And we'll check to see if you've made a security setting that actually breaks your product.
Jesse
And so that would be a really great way. Again, allow lists are a pretty good way to sort of... It's kind of like, kind of doing the same thing, where you'd be able to say, "Here's my demo application fully running. Now I'm going to go ahead and save all of those as my allow list." And you're basically viewing all the actual queries that you're working with. So is there a way to check existing queries in prod by role? If we go to the operations here, I do believe we can see the role that was request with. So if I go here to the multi-node query, I'm trying to recall if I executed those with the admin secret or not. But if we come in here, we can see that it's using the anonymous role here when I inspect that specific query. So whatever gets passed in, you'll see all the session variables right there. Does that answer your question, [inaudible 00:44:23]?
Jesse
It's really a great way to make sure that any settings, changes that you would make, you'd be able to not break your project because nobody wants to do that. Really appreciate you all coming out and watching those webinar today. I think that you're going to find that, especially in Hasura Cloud, turning on API security settings is just ridiculously fast. And I hope that you'll be able to use those features and make more resilient and strong APIs in the future. So, catch you at the next webinar. If you have any questions, we'll see you on the community chats.
End of transcript
Build apps and APIs 10x faster
