Whenever you call api from angularjs,its shows basic details of api on browser console like (endpoints,parameters,response), so is there any way to hide or secure this details? Or how to encrypt my parameters and responses?
so is there any way to hide or secure this details?
endpoints
Nope. The client must be able to use them. If your JS can see them, so can the user.
parameters, response
Nope. Theoretically, you could encrypt them, but this is ultimately a meaningless activity, as the client must possess the keys needed to decrypt everything, and the user will have them too.
Related
I want to encrypt my API data so that the user can't see it in the network tab or as plaintext in something like the window.__nuxt__ object.
The way I'm doing this now:
encrypt data in back-end with a secret string (like a password)
send encrypted data to front-end
decrypt it on client-side (using the same password as in the back-end)
Here is the problem: The function that decrypts my data can be found by looking through the bundled JavaScript files in the Browser.
Although the function is obfuscated, it is possible the reverse engineer it. And since the password is stored within the function (it has to be, right? Since I don't have the process.env variables on the client-side) everyone can(theoretically) scrape my data.
What is the best way to prevent this?
I know that the data is visible eventually in the browser. I just don't want it the be visible in plaintext.
I'm using express in the back-end and NuxtJS in the front-end by the way.
There's no way to prevent this. All you can do is make it more difficult.
Ultimately, if the data is visible to the user in the browser, you can just get it from the DOM in memory. All the code to transform the encrypted data into the original information must be supplied if you need the user to see the data.
You can obfuscate the code, but your attacker doesn't even need to reverse engineer it to get the data, they just need to run it.
I have a restaurant locater web application that mashes up the location of restaurants to a Google Maps.
I use JQuery sliders to limit the amount of restaurant to show on the map by having Search filter such as: price, type of food, locale.
These JQuery sliders call back via AJAX to an API I created to update the map without the web page having to refresh.
JQuery calls a RESTFUL API like so:
http://example.com/search/?city=NYC&max-price:50&cuisine=french
This returns a JSON string of restaurants which match this criteria so that my web application can display on the map all the restaurants which match the search.
What I don't want to have happen is for someone to come along and figure out my API and dumps out ALL of my restaurant listings.
Is there a way that I can limit who call the above HTTP API, so that only my web server calls the URL and not spamer/hackers looking to dump my database?
Thanks
First, declare your intentions in robots.txt.
Then, send a Set-Cookie header with a nonce or some kind of unique ID on the main page, but not on your API responses. If the cookie is never sent to your API endpoint, return a 401 Bad Request response, because it's a bot, a very broken browser, or somebody is rejecting your cookies. The Referer header can also be used as an additional check, but it's trivial to fake. Keep track of how many API calls have been made by that ID. You may also want to match IDs to IP addresses. If it goes above your threshold, spit back a 403 Forbidden response. Make your threshold high enough that legitimate users don't get caught by it.
Keep good logs, and highlight 401 and 403 responses.
Realistically, if someone is determined enough, they WILL be able to dump this information. Your goal shouldn't be to make this impossible, because you will never succeed. (See all the usual adages about achieving perfect security.) Instead, you want to make it abundantly clear that:
This behavior violates the terms of service.
You are actively trying to prevent this.
You know that the offender exists and roughly who they are.
Scary lawyers might start getting involved if this continues.
(You do have a lawyer, right?)
To achieve this, be sure the body of your 403 Forbidden response conveys a scary sounding message along the lines of "This request exceeds the maximum allowed usage of the API. Your IP address has been logged. Please refer to the terms of service and obey the directives in robots.txt."
IANAL, but I believe the DMCA can be made to apply in this situation if you claim copyright on your database. This essentially means that if you can track illegal usage of your API to an IP address, you can send a nastygram to their ISP. This should always be a last resort of course.
I don't encourage the use of assigned API keys/tokens because they turn out to be a barrier to adoption and kind of a pain in the neck to manage. As a counter-point to #womp's answer, Google is slowly moving away from their use. Also, I don't think they actually apply in this case, because it sounds like your "API" is more like a JSON call that's used mainly on your own site.
All the big REST API's tend to use tokenized authentication - basically before you do a REST request, you have to send some other request to the token service to fetch a token to include with your data request. Bing Maps does this, Amazon does this, Flickr does this... etc.
I don't know too much about it other than having worked with Bing Maps. You'll need to read up on tokenized authentication with REST. Here's a blog post to get you started: http://www.naildrivin5.com/daveblog5000/?p=35
How to hash/encrypt string value in JavaScript? I need a mechanism to do so for hiding some data in localStorage/cookie?
It is something related to security concern but I want some protection for my data.
There are lots of encryption libraries for javascript. Here's the first one that came up on Google: http://crypto.stanford.edu/sjcl/
Your user can always gain access to the key, so this won't protect data from your user. If you want to hide things from the user, you'll have to encrypt it on the server and never send the key to the client.
So assume I'm using some external API, where I'm required to send it an ID and passkey such as http://whatever.com/api?id=asdfg&key=_hjkl&request=whatever
I'm going to need to have that ID/key stored somewhere and I could get away with not exposing it to the user by putting it in a database or something, but whenever the request is actually shot off is there no way to hide it?
No, there isn't.
If you want the client to authenticate against a service, then the client has to have the authentication credentials. Anything you give to the client, you also give to the user of the client.
If you want to add some kind of protection, then proxy it though your own server or use a time limited token - but keep in mind that anybody can still hit the appropriate end points to get access.
If you are giving data to the client, then you are running a public API and it is best to think of it in those terms.
If the api provides a POST method, you can use that, without having to show the parameters.
Using POST method to hide URL parameters
Is there any way that i can (securely, base64 ruled out) encrypt data in javascript without using encryption keys. I know its unlikely, because my encryption engine would be available, but does anyone know of any method that can be used
EDIT:
Upon request, i am trying to hide data that a user entered into a textbox before it gets submitted. The data is completely random and the user will never be asked to write it again. Its not a password, its essentially like a post
No.
You need keys for encryption to be secure.
If you don't have keys then either nobody can unlock it or everybody can.
I think it would be more helpful if you explained what you were trying to accomplish. What are you trying to protect? Who are you trying to protect it from? Where are you sending the data?
If you are trying to hide something from the client, encrypting it on the clients machine means you would never be truly secure.
If you are trying to have the client send encrypted data to a server of yours, why not just use SSL? This is far easier.
Why not HTTPS?
What's the source of the data and where is it going? What's the difficulty of using keys? Again, why not HTTPS?
NEVER trust client-side data! ALWAYS presume can be deleted anytime and user can access and edit it anytime.