Hide sw-access-key from store API requests?

[BrocksiNet]

For security reasons, the core team removed the sw-access-key from any request in the storefront.

See this note (from the 6.5 updates):
https://github.com/shopware/platform/blob/trunk/UPGRADE-6.5.md#removal-of-the--_proxystore-api-api-route

In the end, this means that the sw-access-key will not be in the header of any storefront request anymore.

The main question is: Do we want to adapt this for security reasons?

Questions/Thoughts about this:

• How will we do this and where?
• Only for the demo store? With NUXT middleware/proxy?
• Is this topic also related to the new API client?
• We need to write about this in the documentation?

I am open to a discussion about this here. 🤗

[patzick]

I love it, sw-access-key doesn;t make much sense since most of the requests are coming from the client side (or all of them if the page is fully static).
So The sw-access-key is more like a relict from the past, when there was a proxy on the storefront which could "hide" requests.

If there won't be any breaking change with that (no error, just ignoring this header) the plan would be:

1. Deprecate accessToken in api-client with note it's no longer required for >6.5
2. Deprecate shopwareAccessToken from nuxt module options with the same info
3. add documentation for people using <6.5 versions that this field is still mandatory for them

This way we can support all versions, as header will still be passed the old way.

In the new API client we generate code for specific API version, so in this case we wouldn't have accessToken config at all as it's no longer required. That wouldn't be breaking at all.

[patzick]

This is no longer valid - I thought that the core team removed the sw-access-key, but this is about the storefront team :)

[niklaswolf]

Hold on, how can Shopware then detect in which sales-channel context the API requests occur?
We have for example one Shopware Backend, let's call it https://backend.example.com. The backend hosts multiple sales-channels, so the API-Endpoint for the different sales-channels/shops is the same.
I thought, that the sw-access-token header solves exactly that, so that Shopware can detect in which sales-channel context a specific API call is made.

[BrocksiNet]

Some more context:
The change I mention here is only for the storefront in the 6.5 release and not for the store API in general.
We rely on the store API and we still need to send the sw-access-token (there is no change about this).

The main question is:
Whether it is possible and/or worthwhile to hide (currently visible in the network tab, under the hood we still need to send it) the sw-access-token so that it cannot be used by someone with bad intentions ❔

Note:
For me, it would be also okay if we say this is a hosting topic we should not solve in our application.

[niklaswolf]

Maybe that's a dumb question, but how do you hide a header but still send it? 🤔

[BrocksiNet]

You need something like a middleware that is adding the header internally (forwarding the request) and return the result.
In PHP they did it with some wrapper aka custom controller that is using the store API internally.

[niklaswolf]

ah ok you mean like a proxy. Then I can imagine how this works, I was just stunned because it sounded like you can do something similar directly on client side, which made no sense for me :D

[meeshoogendoorn]

If I understand correctly, the sw-access-key is only used to identify the correct sales channel, right? What security risks are associated with this?

[BrocksiNet]

If you have bad intentions you can create a lot of load and maybe you can also bring down the store with some special store API calls. The main problem, when I understand the core team correctly, is that this is an API key that should not be public because you as a merchant/store owner want to control who is able to use your API. Not really a security risk more a hosting problem I would say because the data is publicly available anyway.

You as a merchant/store owner have multiple options to solve this:

• Only allow calls to your API from a whitelist (with your hosting partner)
• Block calls to your API (blacklist, with your hosting partner)
• Create rate limits to your API (with your hosting partner)
• Use server routes that internally call the store API (I wrote a blog post about this)
• Create some proxy that hides the sw-access-key and use it
• Others I do not have in mind at the moment ...

I want this discussion to have more opinions and also to use this thread maybe in the future to talk with the core team.

[meeshoogendoorn]

As I see it, you already have a few great solutions, I would suggest documenting them and creating very simple and basic examples for the solutions that affect Shopware Frontends Code, Shopware Frontends is a toolbox so everyone should be able to choose their own solution that fits their architecture and possibilities right? Maybe even make use of the community modules section to create a optional module for some solutions.