This is the risk rating from OWASP:
|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|Consider anonymous external attackers as well as users with their own accounts that may attempt to compromise the system. Also consider insiders wanting to disguise their actions.||Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system.||Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.||Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.||The system could be completely compromised without you knowing it. All your data could be stolen or modified slowly over time.
Recovery costs could be expensive.
Security vulnerabilites are discovered and fixed from time to time. This even happens in mature libraries like jQuery, but more often in plugins from less security focused developers. Whatever frameworks and libraries you decide to use, you need to make sure you review and maintain them over time.
Some libraries use signatures to allow the server to validate that it was the origin of a given set of data. If the library comes with a default encryption key, it's of course highly insecure to use this value as it's available to everyone else as well. Default password yields similar problems.
A few years ago Adobe made it possible for a flash/flex application to read data from other websites given the websites. So a flash coming from website A canread data B. The prerequisite is that site B has a configuration file called crossdomain.xml. This file contains a list over domains which B trusts to read its data. Unfortunately this was very often misunderstood. And loads of sites deployed a crossdomain.xml file which was completely open, allowing a flash on a rogue site, to read authenticated data from a trusted site using the user's credentials. This was the topic of many blog posts, including some from yours truly.
example.com can read authenticated data from
anothersite.com returns the following headers:
X-Access-Controll-Allow-Origin: http://example.com X-Accss-Control-Allow-Credentials: trueThe first headers tell the browser that if the current site is
example.comis allowed to include credentials like cookies, basic authentication headers or other credentials in the request.
Unfortunately several sites have already started using this in an insecure way. They use the following headers:
example.comwhich has these insecure headers, and I'm somehow tricked into visiting site
evil.com(by visiting a shortened URL or similar),
evil.comwould now read data from
example.comusing my authenticated session. Not good. Fortunately for the sites having this config,
Access-Control-Allow-Credentials: truecannot be combined with
*. The browser's will simply refuse to comply with this combination.
Similar things happen when using the new
postMessage API. When using this API it's important to specify both the intended receiver and origin of the message being transmitted.