Security implications of storing OAuth client ID in config.json?

[gpoole]

Hi there, thanks for the great plugin!

I'm wondering about whether there are any security implications to storing the client ID in config.json, since I believe this info is accessible to anyone including unauthenticated users via the js source. I know that it's not totally secret info, but I have seen some people saying it's something better kept private, for example on ouath.com they say:

Even though it’s public, it’s best that it isn’t guessable by third parties

I wonder if it's worth using something like sanity-studio-secrets to store the client ID in the data set instead?

I also see that while it isn't documented, the personalAccessToken option is supported in the config and I would have thought that's a security risk since that is secret.

[dorelljames]

Thanks for the kind remarks!

I've had great ideas when I started working on this plugin but the primary reason why it didn't push through is because of this very concern you're asking me right now. To be honest, I agree that it's better to keep the OAuth Client Id as a secret as possible and not publicly accessible say for example you can read its value from the config file of your Sanity repo when it's set to public. But even then if it's private and we're going to use sanity-studio-secrets as per your suggestion, you can actually be able to read the value of it given the right endpoint and api parameters via GROQ to query such value if your dataset is to public.

At the time when I created this, I didn't have much knowledge so why I opted the easiest path which is using the config json file. Knut also suggested the same thing to use sanity-studio-secrets but since we're not really specifically storing tokens, and only once you grant the plugin access to your account those tokens were created, figures it's not much of a security risk. But really that has to say that's just as far as I know. I'd be happy to make changes should I learn more about the implications of how the current implementation poses such security issue. I'd be happy to accept contributions to improve the current behavior. 😊

As for personalAccessToken, I never really pushed through implementing it! And I don't think I'll ever will for the reasons that if I'm not mistaken and as I explained earlier, in order to keep that token fully secure, you have to make sure both your git repo and Sanity dataset is set to private. Thinking about the odds it'll not be followed and tokens possibly leaked (which means full access to anyone's Netlify account), I don't think it's worth it. Better be safe than sorry!

[gpoole]

Thanks for the response @dorelljames. I agree it's probably not the highest priority issue. By itself I don't think there's any serious security issues with revealing this information alone, I think it's more that it could be one part of a more complex attack since it's an additional piece of information for an attacker. Unfortunately I don't have time to contribute a fix for it, I just wanted to raise the issue.

Just to quibble with one point:

you can actually be able to read the value of it given the right endpoint and api parameters via GROQ to query such value if your dataset is to public.

The secrets data in sanity-studio-secrets is stored under secrets.**, so it's not accessible via GROQ queries for unauthenticated users, even for a public data set. That's what would make it an improvement over including in config.json or env variables. It's still going to be accessible to all your CMS users (unless you use access control), but that's a more limited set of people.

[gpoole]

Actually just to add one extra point, I misread this part earlier but:

for example you can read its value from the config file of your Sanity repo when it's set to public

That is a risk, but the bigger issue is more that the value is included from config.json into the compiled Sanity Studio JS code (same issue as for environment variables), so it's possible for anyone who has access to your Sanity Studio's URL to get at it via the JS source, even without logging in first.