Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Certainly I'm not the first one to think of this problem. However, the fact that I couldn't find any articles on this issue (let alone any solutions) fosters my suspicions that there is no canonical solution to this problem:
Let's say I have a trusted web-server that serves a web page using HTTPS and the web page loads some third-party libraries from a third-party web-server (such as a CDN, or similar). Now, in principle, there is nothing that stops the CDN from serving some malicious javascript. This is a problem, except, of course, if I could verify the authenticity of JavaScript-Files served from the third-party servers using cryptographic signatures.
Given that I can dynamically load js-files and there exist crypto-libraries nowadays this should be possible. Or am I overseeing something? Are there existing javascript-Libraries that tackle this problem?
Potentially, yes, you can create the signatures yourself at certain point of time, store them on your server, and when your web page is loaded, you can stream the JS files, calculate their signatures, validate them and then ask the browser to use the JS files, if they are valid.
The problem is that if the third-party author updates the library, then your scheme will stop working until you validate the new code and update the signatures on your server.
Also the necessity to load crypto library from your site will often negate the benefit of using CDNs for other scripts.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm developing web solution from a while and I've the feeling that most developers uses CDN links for sources rather than host JavaScript libraries or CSS styles files besides their pages.
Is it just a reason of space or are there any other reasons such as speed or anything else?
If CDNs are faster, how can it be possible that calling through an external link is faster than a local file on the same hosting?
I'd like to receive evidences of the pros and cons of CDNs, I am not asking for not opinion answers or preferences.
The reason for hosting files like that on a CDN is exactly the same as why you'd host any file on a CDN. A CDN has many nodes placed around the world that are likely to be much closer to an end user than your one web server. If somebody in Australia requests your website that's hosted in London you're going to have to send everything to them.
Alternatively you can host only the files you own, and leave the rest to a CDN. The CDN files are retrieved from a node closer to the user and your server only has to deal with your files. This reduces latency to your site and increases the chance that, if you're using a widely used library, a user might already have it cached.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm quite a newbie in everything related to web development, but I had this project in my mind that I really wanted to realize.
At the moment I am struggling with a method to send a request to the server hosting the website. The idea is that from the site you can enter keywords, and those keywords should be run in a script (python or java(script)) on the server after which it returns an output to the webpage. In theory this script could be executed in the website itself as javascript, but I would like to use the computing power and internet access from the server.
I have researched on using Json and javascript for the job, but I think there has to be a better way for this purpose. Is there anyone that can direct me where to look?
You should build your form in HTML. (More info: https://www.w3schools.com/html/html_forms.asp)
In client-side JavaScript (the code that website users have executing in their browser), you should use the jQuery library to scoop the data out of your form. Take a look at the .submit() and .val() functions to get started. Then you can use jQuery's AJAX function to submit requests to the server-side API in a JSON format.
On the server, in addition to creating a way of serving up the webpages (with their client-side JavaScript), you will then need to create an API to receive and respond to these requests. One way to do this is by running Node.js with Express, which will allow you to write your API in JavaScript. The downside to this is you will have to pay to get a full-fledged virtualized cloud server through AWS, Rackspace, or another host. The other option is for you to write your API in PHP, which is supported by free webhosts like x10hosting.com.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How do services which have JavaScript client libraries secure those libraries and the APIs they call? Specifically:
Ensure library is only loaded on valid sites.
Ensure a user doesn't just open up the console and start making calls.
Any other major considerations to be made?
Ensure library is only loaded on valid sites.
You can't and you don't. Security in client-side JS is futile. If you're talking server-side JS, you're pretty much pwned if arbitrary code is able to execute server-side.
Ensure a user doesn't just open up the console and start making calls.
Most services require some form of API key/token, a value that needs to go with your API requests so that the service can check its validity. This value is usually only obtainable by being a registered user of the service. That means an API key is tied to an account. If the service finds out that you're breaking ToS, they can simply block your API key or account altogether.
For public APIs, there's a combination of rate limiting, tracking and blocking (i.e. IP or a fingerprint of some sort), referrer checks (ensure something is only loaded by a certain page, not somewhere else), UA checks (ensure a browser is downloading, not a bot, app or something), and more. Individually, these checks are easily spoofed, but combined, can be a deterrent.
Well, since your js basically lives client side then the only thing you could really do there is make users authenticate before they can really get your libraries. Anything past that would really just be a tiny roadbump to anyone who really wants to manipulate your js.
Where you do have and can maintain control is securing your API calls. The most popular forms are with basic auth, OAuth, and IP whitelisting.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am using javascript and Reactjs. We have a very complicated server set up, and it would be quicker if it was possible to use the .env file to store our API keys and access them directly from the client.
I'm sure you can, but you should not. Especially when it comes to security concerns.
Everything the browser reads, writes, or otherwise interacts with is also available to all users to be used as they see fit.
it would be quicker if it was possible to use the .env file to store our API keys and access them directly from the client, [...] there is a way to load .env variable on the code, so its hidden, your just refering to the env file
This would effectively give those API keys to users for them to use as they see fit. There is no way to hide something that is sent to the browser. Nothing is stopping a user from modifying (or completely rewriting) the client-side application for themselves and displaying -- or worse, modifying -- any data present in there.
This is one of the reasons your server should treat every single request and response as a potential attack. Keeping that in mind, including API keys in the response is everything but secure, as a potential attack will pretty much effortlessly harvest your API keys.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I want to insert a piece of javascript in the clients websites to track various statistics (like crazyegg, intercom.io), but traffic related.
I was thinking of using IronMQ but I don't know how to call it from Javascript directly and I am affraid that making a request to my server (3Gb Ram) from sites that have tens of thousands of visitors / days can cripple the server when making too many javascript requests in the same time.
You can call the IronMQ thru the HTTPS API.
See IronMQ REST/HTTPS API for more information.
Of course, you will need to provide Project ID and Token to JavaScript code. I suggest to encrypt Token before you place it into JS/HTML and decrypt on page load or before using the API.
Welcome Iron.io Live Chat even you will need more information.
Upd: For now it seems does not work. Because of Cross-Origin restrictions. But we're working on it, so, stay in touch.
You'll need to optimise as you go. If you find CPU is a problem, optimise for that. If you find memory is a problem, optimise for that, if bandwidth, etc etc etc. It all depends on
your requirements
your resources.
Optimisation is almost always the last step in the development process.
You might just have people include a 1x1 pixel image, you might have them include an iframe, or you might have them include a javascript file running off your server. Or you might have them include a javascript file on their server. More questions you need to ask yourself might be what information you want, what security issues are there, etc. If it's information for their purposes, then you don't need to worry about them forging it. Otherwise, you do.