I am creating an API server which serves a card number validation and transaction insert.
Sample API URL = http://mydomain.com/api.json?cardnumber=2342343244&api_key=jhj67asd234tgbh123
Existing system:
I am providing an api key to client systems (say ebay.com). I am providing a discount if the user have a valid card. So my client will provide a form field to his end users to enter a valid card number.
Problem:
My client is writing ajax request to my domain to process the validation. The problem is the api key is visible in console and anyone can do the request outside of the client system (security loss).
Propose system: Please propose a system where my api key is hidden, so that the request will be processed securely. The solution may be any other way of writing an API.
I have less knowledge about API. Any help will be appreciated.
In my experience there isn't an easy way of doing this.
The only method I know about is providing the client with a one-time key. As soon as its used, it expires and the client will need a new one.
In this manner it doesn't matter that the key is visible in the console as its only ever going to be valid for a single request.
I hope that helps but I'd love to hear about any suggestions anyone else has.
Related
A partner company is creating an RESTful Endpoint which we want to consume.
Instead some proper way of authentication they want to give use the JWT signature key so that we can create a JWT clientside and send the JWT as JSON body to the API endpoint. They could then check if the signature is valid as they also own the signature key.
While this actually seems to get the job done it feels like abusing JWT's.
Is this a valid workflow for JWT's?
if not what are argruments against it?
I can't think of any valid argument against it (beside that it feels wrong).
The biggest problem I see with this workflow is that the server has to trust the information that the client includes in the JWT payload. Additionally, if the server sends the same signature key to all users, the server will have a lot of trouble confirming if a user is who they say they are. Now, if the server is sending a different signature key to each user, the best the server can do is to store records in a database to control the expiration of the signature keys, but this makes JWTs no longer stateless (since they depend on "states" stored in the server), and the advantages of this feature are lost.
By far the best way to do this is to
use asymmetric encryption
generate a private/public key pair
Send the other party a public key
Generate JWTs using our private key.
Every time there's more than 1 party involved with JWT, and they individually generate/validate tokens and asymmetric encryption/signing is not used you should feel this is a red flag.
I'm using the url as below to request the Google Maps API, and getting Developer purpose only in output. https://www.google.com/jsapi?sensor=true&libraries=places&key=**********&client=*******
Can anyone help me what is wrong with the request format. Should I use url like this: https://maps.googleapis.com/maps/api/js?sensor=true&libraries=places&key=***********&client=*********
Tried both the urls in the request but getting development purpose only watermark on maps.
Map in the web application without any watermark.
The problem here is you are both using the "key" parameter for API key and "client" parameter for client ID. You should only choose one type of authentication. Using both will lead to an error, just like what you are experiencing right now.
This is the correct way to load Javascript API key:
You can learn more here.
If you have a Premium Plan license and wish to use your client instead:
This Detailed guide for Premium Plan customers will be a big help to you.
Also, you don't need to the "sensor" parameter anymore.
Hope my answer helps!
So I have an API using Express in NodeJS and I want to secure it so only I or known clients can use it. I found about JSON Web Tokens but not sure how to keep the key secure if I'm making AJAX requests to the API from a web client using JQuery for example. People will be able to get the key and make request themselves right?
How do I prevent this? Or have I misunderstood the concept of JSON Web Tokens.
Other smaller question, I found the jsonwebtoken npm package which seems popular and you can sign a web token and verify one. How does the verification work? I know you pass a secret but the same secret is used for multiple signed keys right? I originaly thought I store the key in a database or something and verify if the provided key in the request is in my database but that does not seem to be the case as the you do not store the key.
We are running analytics service for web. Each application created inside the service is provided with the script and API key to collect the metrics. Users have to copy the script into their HTML to monitor the site. The API key is public and anyone can see it from HTML code. So anyone can use the API key to send fake data into account.
We heard that JSON Web token(JWT) is a better way to replace session cookies. Will JWT can solve this issue?
By definition, such a code snippet must be inside the HTML code. In that sense it makes no difference whether you use an API key or a JWT token. Both can be read and used.
But you can embed an expiration time in the JWT token. This way, a copy/pasted JWT token out of the html page is only usable for a relatively short time.
It won't stop determined people from inserting fake data, as they can write a script to read a "fresh" JWT token by regularly downloading the html page.
So: it helps only a little bit.
I have a website where you can request data using ajax from our servers as json (only to be used on our site). Now i found that people start using our requests to get data from our system. Is there a way to block users from using our public json API. Ideas that i have been thinking about is:
Some kind of checksum.
A session unique javascript value on the page that have to match server-side
Some kind of rolling password with 1000 different valid values.
All these are not 100% safe but makes it harder to use our data. Any other ideas or solutions would be great.
(The requests that you can do is lookup and translations of zip codes, phone numbers, ssn and so on)
You could use the same API-key authentication method Google uses to limit access to its APIs.
Make it compulsory for every user to have a valid API key, to request data.
Generate API key and store it in your database, when a user requests one.
Link: Relevant Question
This way, you can monitor usage of your API, and impose usage limits on it.
As #c69 pointed out, you could also bind the API keys you generate to the API-user's domain . You can then check the Referer URL ($_SERVER['HTTP_REFERER'] in PHP), and reject request, if it is not being made from the API-user's domain.