I was thinking about Sitecore JSS GraphQL impersonation tokens recently, as one does. I really wanted an API token that was just limited to the particular site I was working on instead of being granted read access to whatever extranet\anonymous has read access to.

This post will explore the Sitecore permissions required to limit an GraphQL API token to one specific site so we can turn a query that looks like this into something that is restricted a little more:

For this, we'll create a new user and we'll limit the API token to my cfworker test site. This project originates from some of the Cloudflare Workers work I've done recently which you can read more about here. Sorry for the shameless plug.

So since API keys respect Sitecore security, we'll create a new user. We'll name it extranet\cfworkeranonymous and configure it with an email address and a secure password.

Use a better password

After this account is created, if you open the Access Viewer and select this user, you'll see it's configured as read only across the entire tree.

Let's walk back some of those read permissions though. Let's first remove all the read permissions to the entire tree, besides for the actual site.

Deny All

The basic idea here is that we'll just deny the whole tree and just grant access to the parts that we actually need. This means we will not be able to query /sitecore or /sitecore/content, but maybe that doesn't matter? That's up to you. Go ahead and create an API key following the JSS documentation, but use our newly created user instead of extranet\anonymous.

At this point, you should be able to query your Sitecore JSS site, but nothing else.

And that is really it.

via GIPHY

You should still have all of your same template types available in your schema and you should be able to navigate to the docs panel and view them in the way as before:

But now when you try to query outside of the scope of your site, you'll just get null.

Hopefully this helps you limit the amount of data that can be queried with your GraphQL endpoint. This should really just be a starting place and your needs should dictate the security policy you ultimately end up using on your project. I feel like this approach more closely aligns with the permission structure you would have on a non-Sitecore JSS site.

Did I miss something here and really need to give something else permissions as well? Let me know!