An API key has to be entered as a GET parameter and these are easily seen in the URL. I could try using ajax to call a page, which in turn uses jQuery.get(); to fetch me the things I need, but is it possible for someone with more knowledge of a browser's inspector to find their way to the js variables of a page called via ajax?
If yes, then how do I protect the API key? The tutorials only explain how to use the API itself, as if the rest is common knowledge.
Anything in the browser space is essentially public.
So either you restrict the info available with the key to information you don't mid being seen, or you put an intermediary in the process - i.e. a server that does the look ups on the protected routes and passes back public info
Some notes on GET requests:
GET requests can be cached.
GET requests remain in the browser history.
GET requests can be bookmarked.
GET requests should never be used when dealing with sensitive data.
GET requests have length restrictions.
GET requests should be used only to retrieve data.
Source W3Schools
Related
I am calling a Azure API app from JavaScript. I need to send a parameter to backend via API based on the domain that application executes under (mydonain.org parameter1, for mydomain.com parameter2). However I need to hide this parameter from the users (when users right click and view JavaScript code, they will not be able to see the parameter).
How can I send this parameters from JavaScript to backend via API app and make in invisible for users?
$.getJSON("api/searchItems/" + myparam,
function (Data) {
...
});
myParam has different values based on where the application executes. if it executes on mydomain.com it is 1 and if it executes on mydomain.org it is 2 etc.
but this code is not approved because you can find out what the parameter is and call the api directly.
This request breaks the golden rule: if it's located at the client then no matter how much you try the client will be able to find it, period.
You do have a couple options and this is subjective since not a lot of detail has been given.
First you can hash the domains though clients will still be able to easily inject their own JavaScript code and determine what domain you're hashing.
Secondly are you validating the client data at the server? Do you have way to associate a domain with something such as a session (which is not effectively a 100% guarantee itself) and reject spoofed domain requests?
I'm not sure offhand what, if any, security concerns there may be with passing a domain name as a string. I presume this is not in conjunction with a form (perhaps viewing data on a specific domain out of a list).
Lastly whatever server side programming language you're using should have a method of allowing you to know what the domain name is, presuming you're not requesting information for domain A from domain B.
I am currently working on a JavaScript chrome extension and would like to be able to send all the redirects for a given link that matches a certain criteria. I would like to do this client side invisibly and send the data back to an endpoint. There are several ways to do this in other server-side languages (I would like to basically have the functionality of the following python script)
import requests
response = requests.get(domain)
redirects = list()
for r in response.history:
redirects.append(r.url)
Is there anyway to extract this sort of information invisibly on the client-side, preferably using JavaScript/some JS library?
Thanks in advance for your time!
This is not possible from the client side using JavaScript. You can send a HTTP request to a certain URL using XMLHttpRequest, but it will automatically follow redirects down to the final destination. There is not way to retrieve the redirection history. Also, browsers prevent sending requests to different origins as per the Same-origin policy.
I try to wrap my head around how to really secure ajax calls of any kind that are publicly available.
Let’s say the JavaScript on a public page (so no user authentication of any kind) contains an AJAX call to a PHP script (REST API or just a script, it doesn’t matter) that does a lot of heavy lifting. So any user can just look into the source code, find the AJAX call, rebuild and execute it, and execute it again a million times in a second and DDoS your site that way - not so great. At first I thought a HTTP_REFERER check could be helpful, but as any header field, also this is manipulable (just use a curl request) so the gain of security wouldn’t be too high.
The next approach was about a combination of using session ids, cookies, etc. to build some kind of access key for every page viewer and when someone exceeds the limit the AJAX call would run into an error. Sounds great so far, but just by cleaning the cookies, etc. everything will be reseted. So also no real solution. But, of course! Use the IP! Great idea! Users in public networks, that use only one IP for internet access will be totally happy, if one miscreant will block the service for all of them by abusing the call... not. So, also no great solution.
So, I’m really stuck here and can’t think of any great answer for my problem.
I also thought about API keys, or something alike. But that is an information that is also extractable from the JavaScript source. So how to prevent other servers using your service in a proxy kind of manner serving your data to their users? (e.g. you implemented the GMaps API in your website (or any other API) and someone uses your script accessing the API with your key)
tl;dr
Is there any good way to really secure your publicly viewable AJAX calls from abusing them for DDoSing your site, presenting your data on other sites, etc.
I think you're overthinking what AJAX is. When your site makes an ajax request, server side, it's the same as any other page request (even if some scripts are more process intensive). You need to protect your entire site, and not just specific scripts. If your server does not have any DDoS protection, it can be attacked through any page. Look into services like CloudFare
As #Sage Mentioned it is similar to normal http request. You can use normal authentication as the http headers/cookie information will be passed on to the server every time you make ajax call. For clear view you can look into developer console on browser. Its the same as exposing you website root url. Just make sure you have authentications checks for ajax calls too.
I am using some global variables on a web application, built on Html/Javascript. I am using these variables across pages (or portions of them), and sometimes they are used as post data for ajax calls. My question is: how secure is this? surely i can set different values for these variables (using a console for example) and then, the calls that rely on this var are made. Imagine the user sets some Id that corresponds to something that he even doesn't have access to..
How should this be done?
Thanks in advance
There is nothing different about this from any web application, from a point of view of security.
Anything sent from the browser must be treated as untrusted by the server. This includes URL parameters, form post data, cookies, http headers and anything controlled by javascript. All these items can be manipulated by an attacker.
Essentially, it doesn't matter what the values are in the client, you only need to worry about them when they hit your server in the form of a new HTTP request (this includes XHR). Until that point, variables with bad values can't do any damage.
Ensure your server can correctly authenticate the current user and only allow them access to data and actions that they are authorised to perform. Ensure that all data received from the browser is checked to be correct (if known) or of the correct datatype and within expected limits, rejecting the data and aborting the action if it is not.
if you use jquery, you can use
$.data()
With this, you can associate the data with an element, thus a unauthorized user will not be able to access it
Javascript has runtime type identification (everything is a var like visual basic), its a loosely typed language.
Javascript has its own security model though
User cannot access files (r/write)
It cannot access or look at user location, files, open windows without demand etc
It is not possible to protect the source of your javascript file either or even pwd protecting it as this is better done server side.
Even encryption or decryption doesnt work because somehow you need to tell your users the key
Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed.
There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.
I'm building an API and want Ajax to be able to interact with it. The API needs to allow inserting, updating, and deletion of data. Is it a good idea to allow any of these operations via GET?
For example: http://api.domain.com/insert_person/?name=joe
My original plan way to use GET for my "getting" methods (basically, just a simple DB query) and POST for add, edit, and delete. Problem is JS same-origin policy which would make it hard for Ajax to interact with my API. There is a jQuery workaround for GET (via JSONP).
Suggestions?
In a word: NO
GET should always be used only for retrieving information and should never have side effects, ever.
This is a best practice across just about every web api out there and has to do with both the intent of the verb as well as how existing software expects things to behave.
If you're trying to get around the same origin policy, GET via JSONP is the only possible front-end solution. If you've got control of the back end you can setup a proxy service that is on the same domain as the page, but relays to and from the API service.
If you're going to go down the JSONP GET path, make sure you read up on XSS and CSRF.
Add another layer of to handle your code and interact with your database (different domain).
You would still use POST and you can make a request to your db in the server side, using what ever language your are working with, example php will use curl.(to make request to a different domain)
If you allow to interact with your db using get, then anyone can simply type the url with the commands they want, so yes avoid it .
As others have pointed out, GET should not be used for actions with side effects like inserting, updating and deleting.
To allow cross-origin use of your API, look into Cross-Origin Resource Sharing, although it's currently only partially supported by browsers.