I have a site on Squarespace and I'd like to show some data from other places (E.G. the One Call API from OpenWeatherMap). It is a free API.
As far as I know, there is no way to completely secure API keys on Squarespace (unless you are using some of their listed commerce APIs. If I put the API key in any file on the site, it will be exposed, since Squarespace is frontend by definition, and frontend is not safe for API key storage.
Assuming I am only going to use an API key to a free API plan, what are the risks associated with publishing a free API key such as the OpenWeatherMap API key on a Squarespace file?
Rate limits
Given your example, I would think a risk is that OpenWeatherMap might receive too many requests with your API key and shut down your access.
Typically, free API keys are provided with rate and/or total request limits. If one or more people used your key to make requests of their own, especially using scripts at a high rate or volume, the provider might consider it abuse of their service.
Terms of use
The other thing to consider is that you might have agreed not to share the key, and to make reasonable efforts to keep it private, when you requested the key. If so, posting it where anyone could get it would be a violation of your agreement.
Likely, the only risk for you is getting temporarily or permanently blocked from using the service, but that is probably the practical extent of it.
Related
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
I am using the standard paypal developer API (NVP) to get current inventory levels:
https://api-3t.paypal.com/nvp?METHOD=BMGetInventory&VERSION=95.0&USER=____&PWD=____&SIGNATURE=____&HOSTEDBUTTONID=_____
But, I have a concern... If the api is enabled and the key is compromised somehow, what is the worst case scenario? For example: it looks like it is possible to send payments using the API. Is there a second tier of verification of payments that happens outside the API?
I have spent around 30 minutes researching the topic without any clarity in terms of what kind of financial damage could be done if an api information is compromised.
If your PayPal API credentials are compromised then someone can make API calls on your behalf. This includes sending and/or withdrawing money from your account.
There are some ways to limit the permissions of a PayPal API credential on the pages where you set the credential up, so you might be able to create a key that is somewhat less dangerous. It has changed over time so I can't offer details; google and/or log in to your account and look.
And yes, PayPal has lots of fraud detection that it runs internally on payments, but they have no legal responsibility to figure out that your API has has been stolen and I would strongly recommend not relying on them to save your bacon in such a case.
Protect your keys, especially ones with access to your money.
I am new to Google Site Search and Google Custom Search and need to implement it on a large number of websites. My concern, however, is that I will be paying $100+ a year, but my API key will be exposed in the JavaScript. What prevents someone from just using my key or otherwise running up query hits and exhausting my quota?
I am getting this error whenever I try to follow someone on Instagram via API no matter how many follows have been done before:
{"meta":{"error_type":"APIError","code":400,"error_message":"Client request limit reached"}}
My app allows authenticated users to follow interesting people. I know that there is a 5000 call/hour limit per authenticated user, but it fails even with new users.
Do my app is reaching some kind of client level limit?
APIs like follow, unfollow, comment are limited to 350 requests per hour. However sending requests from client side will fix this problem to some extent but it allows the users to see your API token.
In this case it looks like it would be beneficial to get some more data from your users. You could use Google analytics to track the "follow" action
https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide
This would give you a timestamp and information about user behavior.
Even with an advertised rate of X requests per hour, one user hammering the service with your API key can cause everyone to get throttled. (Not guaranteed, but pretty common practice for companies to keep their services alive)
It might be a good idea to reset your API, its possible (though unlikely) that someone has acquired your key and is using it.
We're building a multi-tenant SAAS web-application. Our tenants want the option to accept credit card payments for the various products that we allow them to market through our application. To support this we will require that the tenant has their own Braintree account. The tenant provides us with their Braintree API keys through our app. We then use those API keys to interact with their Braintree account on their behalf (card storage, card verification and basic transactions).
This model is the same as the model used by the existing Braintree customers WooThemes, Goodsie, TutorTrove and many more.
We need to record the tenant's API info (merchant ID, public API key and private API key) for this all to work.
My questions are:
Can we simply store this information in our application database?
Does storing this information affect the PCI/DSS scope of us or our tenants?
If we can't store the information in raw form, what is an appropriate storage form?
Note: we have contacted Braintree directly with this same question, but we didn't think it would hurt to get other opinions as well :).
Cheers,
Sam
IMHO, Please note that you will be [if not, should be] having tenant based crypt keys [each tenant can configure their own crytographic algorithm and the keys => SAAS Cusomization], Please do encrypt the AuthorizationId using the tenant specific keys and then persist in the database. These kind of sensitive data should be secured and you should have a note stating that you are maintaining these keys in the database so that the tenant's can opt out if not required and manually enter the key whenever required. This will ensure safety. By the way is your application using SSL.
Please do share your thoughts on this suggestion
So Braintree responded to this question with:
So long as your system is PCI compliant, and your merchants are aware
that their API keys are stored on your server, then you should be
fine. How you store the integration API keys is completely up to you,
and [we] don’t really have any best practices to offer.
So, it doesn't seem like this case affects the PCI/DSS scope of our product, and it seems we are free to choose an appropriate way to store the private API keys that we obtain (saravanan's suggestion is one possible option).