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 6 years ago.
Improve this question
Doesn't using Google CDN for jquery break the rule of not using cross domain requests on the webpage. Do we trust Google enough to do this?
The use of script tags from a foreign website are allowed within the browser itself. Because it is presumed that you intend to load this functionality. The scripts loaded are not able to communicate directly with the foreign domain though (XHR same-origin, except with CORS). Now, this is precisely why you don't want to allow for un-checked user input that could load a script from a foreign site. It is possible for a foreign script to do things you don't want, but if it is from a trusted source, it should be fine.
If google was caught to be using an injection via their CDN, there would be severe backlash, and I doubt it would ever happen, and if it did, would be corrected far more quickly than you would even notice the issue.
No, it doesn't break the rules of cross domain requests. When you include jQuery from Google's CDN, you are simply including a resource into your page (much like linking to an image). This does not fall into the Same Origin Policy security concept to which I assume you refer, which mostly encompasses XHR (ajax) requests.
Related
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 2 years ago.
Improve this question
I want to detect using vanilla javascript if the end-user has any webextensions enabled at all. Is there a way to query for a list of browser enabled webextensions? Hopefully there is another way besides checking for injected scripts, css and image tags that the page was never intended to load.
This question was shut down for not entering enough security reasons. I can understand why that's a concern but it is not a reason to burn a technical question. Regardless, here are security reasons to want to eliminate web-extensions from a website:
web-extensions allow people to break CSP
https://chrome.google.com/webstore/detail/disable-content-security/ieelmcmcagommplceebfedjlakkhpden
scrape your business data, install key loggers to harvest passwords and other information, install image tracking beacons to track private and sensitive end-user information - all unbeknownst to your average end-user.
In addition, deliberate or self-made web-extensions can automate scraping your business data, attempt to spoof captcha logins and other malicious purposes.
some way is
you can check number of script tag that document has (also css)
then if there were more than your resource
user use extension
... some extension does not add script or css
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 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.
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 9 years ago.
Improve this question
Is it possible to do Ajax Deep Linking without hash sign (#) in the url. Knowing that my urls don't point to any controller/action on the server.
For example How does Stackoverflow or Soundcloud to manage the url?
Any help would be appreciated
You could use a query string, but the # is better since it doesn't give the appearance of different resources on the server.
Stackoverflow doesn't use Ajax (afaik) to load pages (if they did, they would use the technique below). I've no idea what Soundcloud does as I don't use them.
Twitter and Github use the history api (pushState and friends) but populate the initial page load server side (i.e. they don't load a default page and then overwrite it using JavaScript).
Doing it server side in this fashion is the preferred approach. It loads the requested content faster (and without the flash of homepage problem), continues to work if JavaScript fails, and is search engine friendly.
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 8 years ago.
Improve this question
Compared to scripts within a page, what extra powers do addons/extensions have? They are essentially scripts, then what makes them so special? Beside being static, have buttons on the toolbar, and be able to see the locations of other tabs, what extra functionalities do they provide over scripts on a page?
Scripts on a website are generally sandboxed and are limited in what they can do (for security). In contrast, extensions can live outside of the sandbox and interact more with the browser and system. For example, some extensions can manipulate browser history, browser preferences, intercept and modify pages, access your clipboard, or even execute arbitrary code on the system. Taking a look at the Chrome extensions permissions warnings can give you a pretty good idea of what Chrome extensions can do (and which most scripts can't). Also check out the chrome.* APIs which extensions have access to.
It depends on the browser.
For example, in Firefox an extension can open a file on your filesystem, write arbitrary bytes to it, then run the file as an executable. Or put another way, it can do anything Firefox itself (or more generally, any program run by the user running Firefox) can do.
An extension is always around and theoretically works on every site (or on no site at all), while a script within a page only exists within that page. So unless you're talking about a VERY specific function/script only for a specific site, addons are more "available".