Cross-site

scripting

Cross-site scripting (XSS) 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, 11,253 site-
specific cross-site vulnerabilities were
documented by XSSed, 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.

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] 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.
Cookie security

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]

Http-only cookie

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]

SameSite cookie parameter

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]

See also

Web application security

Internet security
XML external entity
Browser security
Metasploit Project, an open-source
penetration testing tool that includes
tests for XSS
w3af, an open-source web application
security scanner
DOMPurify, a free and open source
code library by Cure53 to reduce
 susceptibility to XSS vulnerabilities in
websites.
Cross-document messaging
Samy (computer worm)
Parameter validation

References

1. "Symantec Internet Security Threat

Report: Trends for July–December 2007
(Executive Summary)" (https://techcrunc
h.com/wp-content/uploads/2009/08/b-w
hitepaper_exec_summary_internet_securit
y_threat_report_xiii_04-2008.en-us.pdf)
(PDF). Yahoo. April 2008. pp. 1–3.
Archived (https://web.archive.org/web/20
080625065121/https://eval.symantec.co
m/mktginfo/enterprise/white_papers/b-w
 hitepaper_exec_summary_internet_securit
y_threat_report_xiii_04-2008.en-us.pdf)
(PDF) from the original on June 25, 2008.
Retrieved January 1, 2024.
2. "Cross Site Scripting Prevention - OWASP
Cheat Sheet Series" (https://cheatsheetse
ries.owasp.org/cheatsheets/Cross_Site_S
cripting_Prevention_Cheat_Sheet.html) .
OWASP. Retrieved March 19, 2003.
3. "Same Origin Policy - Web Security.
W3.org" (http://www.w3.org/Security/wik
i/Same_Origin_Policy) . Retrieved
November 4, 2014.
4. "dross" on MSDN (December 15, 2009).
"Happy 10th birthday Cross-Site
Scripting!" (https://learn.microsoft.com/e
n-ca/archive/blogs/dross/happy-10th-birt
hday-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)" (htt
p://jeremiahgrossman.blogspot.com/200
6/07/origins-of-cross-site-scripting-xss.ht
ml) . Retrieved September 15, 2008.
6. Arthur, Charles (September 21, 2010).
"Twitter users including Sarah Brown hit
by malicious hacker attack" (https://www.
theguardian.com/technology/blog/2010/
sep/21/twitter-bug-malicious-exploit-xs
s) . The Guardian. Retrieved
September 21, 2010.
7. Leyden, John (May 23, 2008). "Facebook
poked by XSS flaw" (https://www.theregis
ter.co.uk/2008/05/23/facebook_xss_fla
w/) . The Register. Retrieved May 28,
2008.
8. Christey, Steve; Martin, Robert A. (May 22,
2007). "Vulnerability Type Distributions in
CVE (version 1.1)" (https://cwe.mitre.org/
documents/vuln-trends/index.html) .
MITRE Corporation. Retrieved June 7,
2008.
 9. Berinato, Scott (January 1, 2007).
"Software Vulnerability Disclosure: The
Chilling Effect" (https://web.archive.org/w
eb/20080418072230/http://www.csoonli
ne.com/article/221113) . CSO. CXO
Media. p. 7. Archived from the original (htt
p://www.csoonline.com/article/221113)
on April 18, 2008. Retrieved June 7, 2008.
10. Paco, Hope; Walther, Ben (2008). Web
Security Testing Cookbook (https://archiv
e.org/details/websecuritytesti00hope/pa
ge/128) . Sebastopol, CA: O'Reilly Media,
Inc. p. 128 (https://archive.org/details/we
bsecuritytesti00hope/page/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" (https://linkin
ghub.elsevier.com/retrieve/pii/S0950584
914001700) . Information and Software
Technology. 58: 170–186.
doi:10.1016/j.infsof.2014.07.010 (https://
doi.org/10.1016%2Fj.infsof.2014.07.01
0) .
12. "Cross-site Scripting" (http://projects.web
appsec.org/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) (https://b
ooks.google.com/books?id=dPhqDe0WH
Z8C) . 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" (https://web.archive.org/
web/20080516055612/http://www.bindsh
ell.net/papers/xssv/) . BindShell.net.
Archived from the original (http://www.bin
dshell.net/papers/xssv) 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" (https://www.helpnetsecurity.co
m/2006/05/04/cross-site-scripting-worm
s-and-viruses-the-impending-threat-and-th
e-best-defense/) . WhiteHat Security.
p. 20. Retrieved June 6, 2008.
15. "DOM based XSS" (https://www.owasp.or
g/index.php/DOM_Based_XSS) . OWASP.
16. "JQuery bug #9521" (http://bugs.jquery.co
m/ticket/9521) . 2011.
17. "DOM based XSS prevention cheat sheet"
(https://www.owasp.org/index.php/DOM_
based_XSS_Prevention_Cheat_Sheet) .
OWASP.
18. "Strict Contextual Escaping" (http://docs.a
ngularjs.org/api/ng.%24sce) . Angular.js.
19. "Self-XSS Facebook scam attempts to
trick users into hacking themselves" (htt
p://www.majorgeeks.com/news/story/sel
f_xss_facebook_scam_attempts_to_trick_
users_into_hacking_themselves.html) .
www.majorgeeks.com. July 29, 2014.
Retrieved September 20, 2016.
20. Williams, Jeff (January 19, 2009). "XSS
(Cross Site Scripting) Prevention Cheat
Sheet" (https://web.archive.org/web/2017
0318125710/https://www.owasp.org/inde
x.php/XSS_(Cross_Site_Scripting)_Preven
tion_Cheat_Sheet) . OWASP. Archived
from the original (https://www.owasp.org/
index.php/XSS_%28Cross_Site_Scripting%
29_Prevention_Cheat_Sheet) on March
18, 2017. Retrieved February 4, 2010.
21. "template - The Go Programming
Language" (https://golang.org/pkg/html/t
emplate/#hdr-Introduction) . golang.org.
Retrieved May 1, 2019.
22. "Google Developers" (https://developers.g
oogle.com/closure/templates/docs/secur
ity) . Google Developers. Retrieved May 1,
2019.
23. "pug-plugin-trusted-types" (https://www.n
pmjs.com/package/pug-plugin-trusted-ty
pes) . npm. Retrieved May 1, 2019.
24. Sharma, Anand (February 3, 2004).
"Prevent a cross-site scripting attack" (htt
p://www.ibm.com/developerworks/ibm/li
brary/wa-secxss/) . IBM. Retrieved
May 29, 2008.
25. "ModSecurity: Features: PDF Universal
XSS Protection" (https://web.archive.org/
web/20080323040609/http://www.mods
ecurity.org/projects/modsecurity/apache/
feature_universal_pdf_xss.html) . Breach
Security. Archived from the original (htt
p://www.modsecurity.org/projects/modse
curity/apache/feature_universal_pdf_xss.
html) on March 23, 2008. Retrieved
June 6, 2008.
26. "Ajax and Mashup Security" (https://web.a
rchive.org/web/20080403234132/http://
www.openajax.org/whitepapers/Ajax%20
and%20Mashup%20Security.php) .
OpenAjax Alliance. Archived from the
original (http://www.openajax.org/whitep
apers/Ajax%20and%20Mashup%20Securi
ty.php) on April 3, 2008. Retrieved
June 9, 2008.
27. O'Reilly, Tim (September 30, 2005). "What
Is Web 2.0" (http://oreilly.com/web2/archi
ve/what-is-web-20.html) . 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 (https://ww
w.amazon.com/gp/reader/159059816
4/) . Apress. p. 36. ISBN 978-1-59059-
816-0. Retrieved June 4, 2008.
29. "How to use security zones in Internet
Explorer" (http://support.microsoft.com/k
b/174360/en-us) . Microsoft. December
18, 2007. Retrieved June 4, 2008.
30. Lie, Håkon Wium (February 7, 2006).
"Opera 9 Technology Preview 2" (https://w
eb.archive.org/web/20080517034438/htt
p://labs.opera.com/news/2006/02/07-
2/) . Opera Software. Archived from the
original (http://labs.opera.com/news/200
6/02/07-2/) on May 17, 2008. Retrieved
June 4, 2008.
31. "NoScript" (https://addons.mozilla.org/en-
US/firefox/addon/noscript/) . Mozilla.
May 30, 2008. Retrieved June 4, 2008.
and Mogull, Rich (March 18, 2008).
"Should Mac Users Run Antivirus
Software?" (http://db.tidbits.com/article/9
511) . TidBITS. TidBITS Publishing.
Retrieved June 4, 2008.
32. " "Using client-side events" in DataWindow
Programmer's Guide" (https://web.archiv
e.org/web/20080618005734/http://www
1.elsevier.com/homepage/saa/trac/prog
meth.htm) . Sybase. March 2003.
Archived from the original (http://www.els
evier.com/homepage/saa/trac/progmeth.
htm) on June 18, 2008. Retrieved June 4,
2008.
33. 73% of sites relied on JavaScript in late
2006, in " 'Most websites' failing disabled"
(http://news.bbc.co.uk/2/hi/technology/6
210068.stm) . BBC News. December 6,
2006. Retrieved June 4, 2008.
34. "NoScript Features" (https://noscript.net/f
eatures) . Retrieved March 7, 2009.
35. "Content Security Policy Level 3" (https://
www.w3.org/TR/CSP3/Overview.html) .
www.w3.org. Retrieved May 1, 2019.
36. "Can I use... Support tables for HTML5,
CSS3, etc" (https://caniuse.com/#feat=co
ntentsecuritypolicy2) . caniuse.com.
Retrieved May 1, 2019.
37. "Strict CSP - Content Security Policy" (http
s://csp.withgoogle.com/docs/strict-csp.h
tml) . csp.withgoogle.com. Retrieved
May 1, 2019.
38. "How Google Is Using Content Security
Policy to Mitigate Web Flaws" (https://ww
w.eweek.com/security/how-google-is-usi
ng-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" (https://
dropbox.tech/security/on-csp-reporting-a
nd-filtering) . Dropbox. Retrieved
January 1, 2024.
40. "Trusted Types Spec WIP" (https://wicg.gi
thub.io/trusted-types/dist/spec/) .
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" (https://tools.ietf.or
g/html/draft-west-first-party-cookies-07) .
tools.ietf.org. Retrieved May 4, 2018.
43. "Can I use... Support tables for HTML5,
CSS3, etc" (https://caniuse.com/#feat=sa
me-site-cookie-attribute) . caniuse.com.
Retrieved May 4, 2018.

Further reading

MacKenzie, Thomas.
"ScriptAlert1.com – Concise Cross-
Site Scripting Explanation in Multiple
Languages" (http://www.scriptalert1.c
om) . Retrieved October 24, 2015.
"Preventing XSS in ASP.NET Made
Easy" (http://lockmedown.com/preven
ting-xss-in-asp-net-made-easy/) . Lock
Me Down | Security for the Everyday
Developer. February 6, 2015. Retrieved
October 24, 2015.
 "Cross Site Scripting" (http://projects.
webappsec.org/Cross-Site-Scripting) .
The Web Application Security
Consortium. October 13, 2005.
Retrieved October 24, 2015.

External links

OWASP: XSS (https://owasp.org/www-

community/attacks/xss/) , Testing for
XSS (http://www.owasp.org/index.ph
p/Testing_for_Cross_site_scripting) ,
Reviewing Code for XSS (http://www.o
wasp.org/index.php/Reviewing_Code_f
or_Cross-site_scripting)
XSSed: Database of Websites
Vulnerable to Cross-Site Scripting
 Attacks (http://www.xssed.com/)

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Cross-site_scripting&oldid=1193062348"

This page was last edited on 1 January 2024,

at 21:32 (UTC). •
Content is available under CC BY-SA 4.0
unless otherwise noted.