@nitrogen/auth

[clough-sram]

Hey @rylanharper, thanks for making this available. We have been playing around with the starter and hoping to make the jump to a production environment on Vercel with a Shopify Plus store. Do you think there are any concerns with the accessToken being on the client side?

Does Pinia have any measures to mitigate the risk of that token being accessible in the browser? Does this even matter for a Shopify store?

Appreciate any insight or direction you may have.

[rylanharper]

@clough-sram I've used this in production for a few storefronts this year and for one personal store, and before that always worked headless with Shopify and Vue. The short answer, is no. I have never seen a case where the Storefront access token causes any risks when being available on client-side. This is mainly do to the fact you can't really do anything with the access token besides fetch content that is already on the store. In fact, most headless storefronts expose this token and it can be found within the file sources in dev tools if a developer really knows where to look.

With the Admin API access token, you are technically able to edit products, collections, and customer account data. The Admin access token is also set client-side in this template, but honestly I also have never seen a case where exposing this causes any risks either because you are able to limit scopes within the Admin API setup. The only use-case I've ever used the Admin access token for is for creating wishlist functionality or unique customer accounts that allow customers to cancel subscriptions, so pretty much only customer-scoped features.

Above all else, its important to know that both the Storefront and Admin API access tokens are encrypted. For this template, I host with Cloudflare Workers via Nuxt Hub, which allows the option to encrypt environment variables such as the access tokens (I just encrypt all my API-based environment variables normally). I scanned through the raw output files in the browser a few months ago and indeed the token values cannot be found anywhere. I think this feature is also available within Vercel. I always go with Cloudflare when it comes to ecom due to the potential price difference, which can be substantial if you are working with a popular store.

Hope this helps!

[clough-sram]

Thanks @rylanharper , appreciate the quick response.

Just wanted to clarify that I was referring to the accessToken for customer authentication. Found within the auth store @nitrogen/auth. Sorry, I wasn't more clear.

My understanding is that if this were captured from the client, you could technically log in as the customer. This could expose order history, addresses. Does Pinia have any measures to prevent this? Do you think it matters?

[rylanharper]

Ohh got it! You're right to point this out. To be honest, I haven't done much to address this just because the chance of an XSS attack when using a headless storefront via Shopify is extremely low. But yes, it could possibly happen if a nefarious actor gets the token and sends a GraphQL request via a CURL command or something.

I can think of two options to address this issue:

1. The first to use Shopify built-in account system (Settings → Customer Accounts → URL) instead of the legacy account system via the Storefront API (like is shown in this template), which a lot of headless stores are now doing. Yes, there are definitely tradeoffs.. Mainly the UI is completely different and you may have to connect a specific account sub-domain to this if you are headless - like accounts.my-storefront.com, etc. This is safer then exposing the token client-side.

2. The second would to simply just not persist the customer data, or at least add a maxAge option to the pinia-persist options (which are the same as Nuxt's useCookie). This a bit safer, as the token would likely clear relatively soon after a user's session or a page refresh (although you may have to rewrite the deleteAddress fuction since it uses reloadNuxtApp(). There may also be some way for a custom store function/action to check if the cookie is still available after a time period, and if not, the access token is cleared from the state.

Thats pretty much my two-cents on it.. I honestly think the chances of an attack with this token are extremely rare, like to the point where it most likely will never happen. However, it is possible. I guess this is an oversight on my end in this project. I'm open to any suggestions you have, or a PR that can make this project a bit more secure.

[rylanharper]

Hey @clough-sram, I am working on some updates for this project this week.. What you you think of this approach specifically?

persist: {
  pick: ['accessToken', 'customer'],
  storage: piniaPluginPersistedstate.cookies({
    sameSite: 'strict',
    secure: !import.meta.dev,
    maxAge: 60 * 60 * 24, // 24 hours
  }),
},

I have yet to test this out fully, but it seems like a much more viable option. This projects against the following:

✅ CSRF attacks (can't trick user into making requests)
✅ Network sniffing (HTTPS only in production)
✅ Long-term token exposure (expires in 24h)

However, it does not fully prevent a possible XSS attack, which again, would be exceptionally rare and likely may never happen in the average storefront's lifecycle. If you need this, I would recommend using Shopify's built-in account system.

[clough-sram]

Hey @rylanharper, sorry for the slow reply. I agree that an XSS attack is pretty unlikely, but Shopify does seem pretty adamant about not including the user access token or cart key client-side. We are going to use nuxt-auth-utils so these values are not available in the client. When the work is done we could likely open a PR to the project.

[rylanharper]

@clough-sram Sounds good! A PR for that would be amazing!