foreign welcome back everyone to the second video where we discuss access control rules in the previous video we saw how we could secure our API with access control rules not just on the API level but also on the resource level but we also saw there that there was a hole in our API because the table Access Control rule wasn't guarded wasn't actually being used by the script so at the moment we've still got a big hole in our API and we desperately need to fix it if you recall from our previous video we saw that our vehicle table here had two read access control rules one for the user role and one for the admin role and we also saw in spite of that that if we went to do some testing and try to retrieve a vehicle using that API using their integration user that does not have either of those roles if we click on send here we get a response back so we've got access to the API we've granted access to this user to this role in the last video but once we're in we can go shopping we've got access to everything we can view records create records delete records the table access control rules are not being evaluated at all so what should we do about this situation what do you think what ideas do you have if you're thinking access control rules you're partly correct we absolutely need to do that there is no way around modifying an existing Access Control rule creating a new one or else assigning another role to this user so that user will have access to the table we need to do that but we could create all the access control rules in the world at the moment none of them are being evaluated so we need to fix that we need to actually tell the script to look at the table access control rules and see if the user is authorized to access that data to perform that operation in servicenow by default all server side scripts will not evaluate access control rules on the table level so if you're running business rules or some other kind of server-side script those access control rules will not be evaluated the script will actually run as a system user and that's exactly what's happening here with our web service so what we need to do is actually tell the script to evaluate that and to do that it's real easily the first thing that we could do is go ahead and create a new Access Control rule so in studio if I come here and then select Access Control this time it's just going to be a standard Access Control rule for records in a table so not a rest endpoint ACL so we'll selected record here and the operation whatever you like create delete Etc and then we'll just go ahead and select the table and then pop in the integration user here and we could just repeat that step for all the other current operations at the integration user should have permission for but in our case I think I'll just keep it simple and we'll go to the group for that user the vehicles integration group and then just assign the admin role because we know already that the admin role can perform all current operations including delete so it's probably just quicker for us to do it that way but you'll just have to see in your particular situation if that is a solution or if you need to create a new access control or modify an existing one so we'll go ahead and save that and then the second thing we'll have to do is come to our scripts so I've already gone ahead in our API and created a third version of it if you don't know how to version your apis I created a separate video in this series a little bit earlier so go ahead and have a look at that so here I've got my existing version ones and twos but down the bottom I've got my version three resources so this is going to be our new and improved and much more secure API so I'll just modify one of the resources here the get vehicle one and come to our script now the only thing we need to do here is to modify the API that we're using for querying the table at the moment we're using Glide record but there is another one called Glide record secure and the difference is is that Glide record secure will evaluate access control rules Glide record will not so your business rules your server-side scripts like your scheduled jobs will be run as a system user by default unless you're using Glide record secure or the Glide query with ACLS method there's actually another one that you can use as well there's a link to the documentation for that so all we need to do here literally is add the word secure after Glide record now for some reason the name doesn't resolve like it usually does if you're using visual studio it will resolve the system will recognize it if you're using the servicenow extension in Visual Studio but for some reason it doesn't work here but that is correct so we'll go ahead and save that and now we can go ahead and test our version two so that should just work fine like it did before because we're still using the Glide record method there or the Glide record query method rather if we come to the version three here okay and send that request that should also work now because this user now has the necessary Access Control Rule and we've modified the script as well to say we're going to evaluate acos this time so if I execute that that works just fine now what we could go ahead and do is come to our group here and then take away that admin role from the group and what do you think the response will be now what do you think the result will be so if I go ahead and test this for version three oh it worked again hmm do you know why that may be something to do with cookies so what you can do in Postman is actually clear those cookies if you come down here click on it you can see the cookies that the system is currently storing for this session so just remove all those session cookies so the usual have to authenticate again a new and then we will send the request once more and we find we get exactly what we want but in this case we've just produced a message saying no vehicle found but you can generate whatever message that you want you know it may make sense to have a message like this rather than you know the user is not authorized or authenticated to perform this operation do you want to give out that information or do you just want to say nothing or something simple that is actually not really the cause of the issue so you don't give away any clues to any potential hackers so before we wrap up let's just do one more test this time using the table API so in a previous video we tested this using Postman as well so if we open up our save get vehicle request here we're actually using a different user we're not using the integration user we're just using the user user and this user actually has the permission to look at records inside this table so if we send that request here we'll see we get the record back okay and that's what we expect but now if we were to change this to the vehicle integration user with the respective password and try that in the table API this time not our custom scripted API but the table API provided by servicenow we get user not authorized okay a slightly different message but the result is the same we do not have access we do not have read access there so in this case even though we don't have read access to the API itself we can't actually see what the API is doing we can see however that that table API is looking at the access control rules for the table so if the integration user that is connecting to the API wants to perform an operation the system will check in this case whether that is permissible or not so to sum up whenever you're creating scripted rest apis in servicenow do not use the Glide record API use Glide record secure or Glide query with ACLs because if you don't do that you're just opening up your API to attacks and actually you wouldn't even classify it as an attack because the API itself permits that you are allowing this to happen Okay so don't all right so that is the moral of the story here use Glide record secure or Glide query with ACLs and your API will be a lot more secure now in the next video we are going to take a look at authentication so up until this point we've authenticated using account credentials a username and password that is also inherently insecure there is a better way to do it as using oauth and access tokens so stay tuned for that one foreign