Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API key exposed in app head in script tag #167

Open
joe-dematteo opened this issue Sep 1, 2023 · 6 comments
Open

API key exposed in app head in script tag #167

joe-dematteo opened this issue Sep 1, 2023 · 6 comments
Labels
question Further information is requested

Comments

@joe-dematteo
Copy link

Is it known that the apiKey is exposed in the head tag?

If so is there a recommended way to avoid having this apiKey seen publicly?

@joe-dematteo joe-dematteo added the question Further information is requested label Sep 1, 2023
@Baroshem
Copy link
Collaborator

Baroshem commented Sep 5, 2023

Hey,

Good question!

When setting required configuration for the module, you need to pass both apiKey and application Id. These two variables are then added to public runtime config because they are needed for the algoliasearch library to work correctly on both client and server side.

Because of that, both these variables are exposed and easily accessible on the browser.

Normally I would say that these kind of variables should be hidden somewhere on the server side as env variables but when I was looking at the official Algolia docs, I realised that in almost all examples they use the algoliasearch library, it is using very similar approach.

For example, if you inspect the request that is being sent from your browser to fetch search results, it will contain headers that are populated with the variables that I mentioned above.

I also looked at the Algolia dashboard and it seems that adminApiKey should be hidden while normal apiKey can be easily used.

@joe-dematteo
Copy link
Author

Hey,

Good question!

When setting required configuration for the module, you need to pass both apiKey and application Id. These two variables are then added to public runtime config because they are needed for the algoliasearch library to work correctly on both client and server side.

Because of that, both these variables are exposed and easily accessible on the browser.

Normally I would say that these kind of variables should be hidden somewhere on the server side as env variables but when I was looking at the official Algolia docs, I realised that in almost all examples they use the algoliasearch library, it is using very similar approach.

For example, if you inspect the request that is being sent from your browser to fetch search results, it will contain headers that are populated with the variables that I mentioned above.

I also looked at the Algolia dashboard and it seems that adminApiKey should be hidden while normal apiKey can be easily used.

Interesting. So I'm assuming a path to take is using SSR with Vueinstantsearch as described here?
https://algolia.nuxtjs.org/advanced/vue-instantsearch#using-vue-instantsearch-with-ssr

@Baroshem
Copy link
Collaborator

Generally yes, but recently users have issues with setting this up.

#173

You can also use useAsyncAlgoliaSearch composable as it will request the data on SSR and return it to you as pure html.

However, the case for apiKey could be reviewed as maybe there is a way to add the keys as private runtime config.

Maybe we could create a new configuration option named for example 'hideKeys' or 'usePrivateConfig' that when enabled would disable adding keys to public runtime config so that they can only be used in useAsyncAlgoliaSearch and SSR for VueInstantsearch and they are not exposed to head?

What do you think about this idea?

@joe-dematteo
Copy link
Author

I think that allowing the config option to keep the keys in the private runtime config would be a good option for sure.

@Baroshem
Copy link
Collaborator

Baroshem commented Oct 4, 2023

Ok sounds good to me as well.

Would you be interested in contributing that feature? I can provide all the help needed :)

@joe-dematteo
Copy link
Author

Yes, I can look into integrating this feature. I'll come back if I need help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants