Cross-site scripting

Last updated

Cross-site scripting (XSS) [lower-alpha 1] is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. During the second half of 2007, XSSed documented 11,253 site-specific cross-site vulnerabilities, compared to 2,134 "traditional" vulnerabilities documented by Symantec. [1] XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.

Contents

OWASP considers the term cross-site scripting to be a misnomer. It initially was an attack that was used for breaching data across sites, but gradually started to include other forms of data injection attacks. [2]

Background

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme (e.g. ftp, http, or https), (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately. [3]

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term "cross-site scripting" in January 2000. [4] [ non-primary source needed ] The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security. [5]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter [6] and Facebook. [7] Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, [8] with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks. [9]

Types

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent (reflected)

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability. [10] These holes show up when the data provided by a web client, [11] most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content. [12]

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. [10] [12] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue. [13]

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent (or stored)

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read. [12]

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users' browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal), but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory's profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob's real name and email directly from his own machine.

Persistent XSS vulnerabilities can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm. [14]

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.

Server-side versus DOM-based vulnerabilities

XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side. [15]

An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of jQuery plugins. [16] Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input validation and escaping). [17] Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example AngularJS. [18]

Self-XSS

Self-XSS is a form of XSS vulnerability that relies on social engineering in order to trick the victim into executing malicious JavaScript code in their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed. [19]

Mutated XSS (mXSS)

Mutated XSS happens when the attacker injects something that is seemingly safe but is rewritten and modified by the browser while parsing the markup. This makes it extremely hard to detect or sanitize within the website's application logic. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.

Preventive measures

Contextual output encoding/escaping of string input

There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding. [20] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

Performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks, security encoding libraries are usually easier to use. [20]

Some web template systems understand the structure of the HTML they produce and automatically pick an appropriate encoder. [21] [22] [23]

Safely validating untrusted HTML input

Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.

Many validations rely on parsing out (blacklisting) specific "at risk" HTML tags such as the iframe tag, link and the script tag.

There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS

Another popular method is to strip user input of " and ' however this can also be bypassed as the payload can be concealed with obfuscation.

Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. [24] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, then only permit that IP to use that cookie. [25] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP. [25]

Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser. [26]

Disabling scripts

While Web 2.0 and Ajax developers require the use of JavaScript, [27] some web applications are written to allow operation without the need for any client-side scripts. [28] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called "Security Zones", [29] and in Opera (since version 9) using its "Site Specific Preferences". [30] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some XSS protection even when scripts are enabled. [31]

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded). [32] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities. [33] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed. [34]

Selectively disabling scripts

Content Security Policy

Content Security Policy (CSP) allows HTML documents to opt in to disabling some scripts while leaving others enabled. [35] The browser checks each script against a policy before deciding whether to run it. As long as the policy only allows trustworthy scripts and disallows dynamic code loading, the browser will not run programs from untrusted authors regardless of the HTML document's structure.

Modern CSP policies allow using nonces to mark scripts in the HTML document as safe to run instead of keeping the policy entirely separate from the page content. [36] [37] As long as trusted nonces only appear on trustworthy scripts, the browser will not run programs from untrusted authors. Some large application providers report having successfully deployed nonce-based policies. [38] [39]

Emerging defensive technologies

Trusted types [40] changes Web APIs to check that values have been trademarked as trusted.  As long as programs only trademark trustworthy values, an attacker who controls a JavaScript string value cannot cause XSS.  Trusted types are designed to be auditable by blue teams.

Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping. [41]

When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-"safe" cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics). [42] The feature is implemented in Google Chrome since version 63 and Firefox since version 60. [43]

Notable Incidents

See also

Footnotes

  1. ↑ The abbreviation 'XSS' is commonly used to avoid confusion with cascading style sheets.

Related Research Articles

<span class="mw-page-title-main">JavaScript</span> High-level programming language

JavaScript, often abbreviated as JS, is a programming language and core technology of the Web, alongside HTML and CSS. 99% of websites use JavaScript on the client side for webpage behavior.

<span class="mw-page-title-main">World Wide Web</span> Linked hypertext system on the Internet

The World Wide Web is an information system that enables content sharing over the Internet through user-friendly ways meant to appeal to users beyond IT specialists and hobbyists. It allows documents and other web resources to be accessed over the Internet according to specific rules of the Hypertext Transfer Protocol (HTTP).

Web development is the work involved in developing a website for the Internet or an intranet. Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.

URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org.

Code injections are a class of computer security exploits in which a vulnerable computer program misinterprets external data as part of its programming. An attacker utilizing this method thereby "injects" code into the program while it is running, changing the course of its execution. The result of successful code injection can have major consequences, such as allowing computer viruses to propagate.

In computing-mobile, the same-origin policy (SOP) is a concept in the web-app application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's (DOM).

In computer security, a drive-by download is the unintended download of software, typically malicious software. The term "drive-by download" usually refers to a download which was authorized by a user without understanding what is being downloaded, such as in the case of a Trojan horse. In other cases, the term may simply refer to a download which occurs without a user's knowledge. Common types of files distributed in drive-by download attacks include computer viruses, spyware, or crimeware.

NoScript is a free and open-source extension for Firefox- and Chromium-based web browsers, written and maintained by Giorgio Maone, a software developer and member of the Mozilla Security Group.

<span class="mw-page-title-main">HTTP cookie</span> Small pieces of data stored by a web browser while on a website

HTTP cookies are small blocks of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session.

JSONP, or JSON-P, is a historical JavaScript technique for requesting data by loading a <script> element, which is an element intended to load ordinary JavaScript. It was proposed by Bob Ippolito in 2005. JSONP enables sharing of data bypassing same-origin policy, which disallows running JavaScript code to read media DOM elements or XMLHttpRequest data fetched from outside the page's originating site. The originating site is indicated by a combination of URI scheme, hostname, and port number.

A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of loading entire new pages. The goal is faster transitions that make the website feel more like a native app.

<span class="mw-page-title-main">Clickjacking</span> Malicious technique of tricking a Web user

Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.

In data sanitization, HTML sanitization is the process of examining an HTML document and producing a new HTML document that preserves only whatever tags and attributes are designated "safe" and desired. HTML sanitization can be used to protect against attacks such as cross-site scripting (XSS) by sanitizing any HTML code submitted by a user.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

<span class="mw-page-title-main">Opa (programming language)</span>

Opa is an open-source programming language for developing scalable web applications.

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. It is a Candidate Recommendation of the W3C working group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features.

Browser security is the application of Internet security to web browsers in order to protect networked data and computer systems from breaches of privacy or malware. Security exploits of browsers often use JavaScript, sometimes with cross-site scripting (XSS) with a secondary payload using Adobe Flash. Security exploits can also take advantage of vulnerabilities that are commonly exploited in all browsers.

A web application firewall (WAF) is a specific form of application firewall that filters, monitors, and blocks HTTP traffic to and from a web service. By inspecting HTTP traffic, it can prevent attacks exploiting a web application's known vulnerabilities, such as SQL injection, cross-site scripting (XSS), file inclusion, and improper system configuration. Most of the major financial institutions utilize WAFs to help in the mitigation of web application 'zero-day' vulnerabilities, as well as hard to patch bugs or weaknesses through custom attack signature strings.

Self-XSS is a type of security vulnerability used to gain control of victims' web accounts. In a Self-XSS attack, the victim of the attack runs malicious code in their own web browser, thus exposing personal information to the attacker.

In internet security, DOM clobbering is a type of injection attack that revolves around the attacker being able to insert benign non-script HTML code that can be used to influence the execution of JavaScript code. This enables a skilled attacker to perform a variety of unwanted behaviours, including the ability to escalate to arbitrary code execution on the website.

References

  1. ↑ "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). Yahoo. April 2008. pp. 1–3. Archived (PDF) from the original on June 25, 2008. Retrieved January 1, 2024.
  2. ↑ "Cross Site Scripting Prevention - OWASP Cheat Sheet Series". OWASP . Retrieved March 19, 2003.
  3. ↑ "Same Origin Policy - Web Security. W3.org" . Retrieved November 4, 2014.
  4. ↑ "dross" on MSDN (December 15, 2009). "Happy 10th birthday Cross-Site Scripting!" . Retrieved February 9, 2023. On the 16th of January, 2000, the following names were suggested and bounced around among a small group of Microsoft security engineers: [...] The next day there was consensus – Cross Site Scripting.
  5. ↑ Grossman, Jeremiah (July 30, 2006). "The origins of Cross-Site Scripting (XSS)" . Retrieved September 15, 2008.
  6. ↑ Arthur, Charles (September 21, 2010). "Twitter users including Sarah Brown hit by malicious hacker attack". The Guardian. Retrieved September 21, 2010.
  7. ↑ Leyden, John (May 23, 2008). "Facebook poked by XSS flaw". The Register. Retrieved May 28, 2008.
  8. ↑ Christey, Steve; Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. Retrieved June 7, 2008.
  9. ↑ Berinato, Scott (January 1, 2007). "Software Vulnerability Disclosure: The Chilling Effect". CSO. CXO Media. p. 7. Archived from the original on April 18, 2008. Retrieved June 7, 2008.
  10. 1 2 Paco, Hope; Walther, Ben (2008). Web Security Testing Cookbook . Sebastopol, CA: O'Reilly Media, Inc. p.  128. ISBN   978-0-596-51483-9.
  11. ↑ Hydara, Isatou; Sultan, Abu Bakar Md.; Zulzalil, Hazura; Admodisastro, Novia (February 1, 2015). "Current state of research on cross-site scripting (XSS) – A systematic literature review". Information and Software Technology. 58: 170–186. doi:10.1016/j.infsof.2014.07.010.
  12. 1 2 3 "Cross-site Scripting". Web Application Security Consortium. 2005. Retrieved May 28, 2008.
  13. ↑ Grossman, Jeremiah; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (2007). XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract). Syngress. pp. 70, 156. ISBN   978-1-59749-154-9 . Retrieved May 28, 2008.
  14. ↑ Viruses and worms in Alcorn, Wade (September 27, 2005). "The Cross-site Scripting Virus". BindShell.net. Archived from the original on May 16, 2008. Retrieved May 27, 2008. and Grossman, Jeremiah (November 2020). "Cross-Site Scripting Worms and Viruses: The Impending Threat and the Best Defense". WhiteHat Security. p. 20. Retrieved June 6, 2008.[ permanent dead link ]
  15. ↑ "DOM based XSS". OWASP.
  16. ↑ "JQuery bug #9521". 2011.
  17. ↑ "DOM based XSS prevention cheat sheet". OWASP.
  18. ↑ "Strict Contextual Escaping". Angular.js.
  19. ↑ "Self-XSS Facebook scam attempts to trick users into hacking themselves". www.majorgeeks.com. July 29, 2014. Retrieved September 20, 2016.
  20. 1 2 Williams, Jeff (January 19, 2009). "XSS (Cross Site Scripting) Prevention Cheat Sheet". OWASP. Archived from the original on March 18, 2017. Retrieved February 4, 2010.
  21. ↑ "template - The Go Programming Language". golang.org. Retrieved May 1, 2019.
  22. ↑ "Google Developers". Google Developers. Retrieved May 1, 2019.
  23. ↑ "pug-plugin-trusted-types". npm. Retrieved May 1, 2019.
  24. ↑ Sharma, Anand (February 3, 2004). "Prevent a cross-site scripting attack". IBM. Retrieved May 29, 2008.
  25. 1 2 "ModSecurity: Features: PDF Universal XSS Protection". Breach Security. Archived from the original on March 23, 2008. Retrieved June 6, 2008.
  26. ↑ "Ajax and Mashup Security". OpenAjax Alliance. Archived from the original on April 3, 2008. Retrieved June 9, 2008.
  27. ↑ O'Reilly, Tim (September 30, 2005). "What Is Web 2.0". O'Reilly Media. pp. 4–5. Retrieved June 4, 2008.
  28. ↑ "A page should work, even if in a degraded form, without JavaScript." in Zammetti, Frank (April 16, 2007). Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader. Apress. p. 36. ISBN   978-1-59059-816-0 . Retrieved June 4, 2008.
  29. ↑ "How to use security zones in Internet Explorer". Microsoft. December 18, 2007. Retrieved June 4, 2008.
  30. ↑ Lie, Håkon Wium (February 7, 2006). "Opera 9 Technology Preview 2". Opera Software. Archived from the original on May 17, 2008. Retrieved June 4, 2008.
  31. ↑ "NoScript". Mozilla. May 30, 2008. Retrieved June 4, 2008. and Mogull, Rich (March 18, 2008). "Should Mac Users Run Antivirus Software?". TidBITS. TidBITS Publishing. Retrieved June 4, 2008.
  32. ↑ ""Using client-side events" in DataWindow Programmer's Guide". Sybase. March 2003. Archived from the original on June 18, 2008. Retrieved June 4, 2008.
  33. ↑ 73% of sites relied on JavaScript in late 2006, in "'Most websites' failing disabled". BBC News. December 6, 2006. Retrieved June 4, 2008.
  34. ↑ "NoScript Features" . Retrieved March 7, 2009.
  35. ↑ "Content Security Policy Level 3". www.w3.org. Retrieved May 1, 2019.
  36. ↑ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved May 1, 2019.
  37. ↑ "Strict CSP - Content Security Policy". csp.withgoogle.com. Retrieved May 1, 2019.
  38. ↑ "How Google Is Using Content Security Policy to Mitigate Web Flaws". eWEEK. April 22, 2019. Retrieved May 1, 2019.
  39. ↑ Akhawe, Devdatta (September 21, 2015). "[CSP] On Reporting and Filtering". Dropbox . Retrieved January 1, 2024.
  40. ↑ "Trusted Types Spec WIP". wicg.github.io. Retrieved May 1, 2019.
  41. ↑ L. K. Shar and H. B. K. Tan, "Automated removal of cross site scripting vulnerabilities in web applications," Information and Software Technology, vol. 54, (5), pp. 467-478, 2012.
  42. ↑ Mark, Goodwin; Mike, West (April 6, 2016). "Same-site Cookies". tools.ietf.org. Retrieved May 4, 2018.
  43. ↑ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved May 4, 2018.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.