How to secure/protect usage of Algolia's front end api key?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
From the official tutorials on https://community.algolia.com/instantsearch.js/, Algolia requires you to code the key into your application and used with each api request. If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
algolia api-key
add a comment |
From the official tutorials on https://community.algolia.com/instantsearch.js/, Algolia requires you to code the key into your application and used with each api request. If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
algolia api-key
add a comment |
From the official tutorials on https://community.algolia.com/instantsearch.js/, Algolia requires you to code the key into your application and used with each api request. If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
algolia api-key
From the official tutorials on https://community.algolia.com/instantsearch.js/, Algolia requires you to code the key into your application and used with each api request. If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
algolia api-key
algolia api-key
asked Jan 3 at 22:28
user2167582user2167582
2,20674172
2,20674172
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54030677%2fhow-to-secure-protect-usage-of-algolias-front-end-api-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
add a comment |
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
add a comment |
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
edited Jan 12 at 7:36
marc_s
584k13011241271
584k13011241271
answered Jan 8 at 10:09
Exadra37Exadra37
952149
952149
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54030677%2fhow-to-secure-protect-usage-of-algolias-front-end-api-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown