XSS prevention | CSP
Last updated
Last updated
βΆβ Inputs & Outputs
βͺβ« Whitelisting vs blacklisting
π‘ X-XSS-Protection
β Content Security Policy (CSP) Respose Header
π Referance
In general Cross-site scripting prevention can generally be achieved via two layers of defense for parameters:
1. Encode data on output
2. Validate input on arrival
In an HTML context, you should convert non-whitelisted values into HTML entities:
In a JavaScript string context, non-alphanumeric values should be Unicode-escaped:
Input validation should generally employ whitelists rather than blacklists. For example, instead of trying to make a list of all harmful protocols (javascript, data, etc.), simply make a list of safe protocols (HTTP, HTTPS) and disallow anything not on the list.
The HTTP X-XSS-Protection response Header is a feature of Internet Explorer, Chrome, and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').
Syntax:
0 Disables XSS filtering.
1 Enables XSS filtering:
(usually, default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
1; mode=block Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
1; report= (Chromium only) Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
Content security policy (CSP) is the last line of defense against cross-site scripting.
If your XSS prevention fails, you can use CSP to mitigate XSS by restricting what an attacker can do.
The HTTP Content-Security-Policy response header allows website administrators to control the resources the user agent is allowed to load for a given page.
With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site_scripting).
Implemented via response header:
Implemented via a meta tag:
Defining resources CSP works by restricting the origins that active and passive content can be loaded from. It can additionally restrict certain aspects of active content such as the execution of inline javascript, and the use of eval()
script-src: This directive specifies allowed sources for JavaScript. This includes not only URLs loaded directly into elements but also things like inline script event handlers (on click) and XSLT stylesheets which can trigger script execution.
default-src: This directive defines the policy for fetching resources by default. When fetch directives are absent in CSP header the browser follows this directive by default.
Child-src: This directive defines allowed resources for web workers and embedded frame contents.
connect-src: This directive restricts URLs to load using interfaces like fetch, Websocket, and XMLHttpRequest
frame-src: This directive restricts URLs to which frames can be called out.
frame-ancestors: This directive specifies the sources that can embed the current page. This directive applies to, and tags. This directive canβt be used in tags and applies only to non-HTML resources.
img-src: It defines allowed sources to load images on the web page.
font-src: directive specifies valid sources for fonts loaded using @font-face.
manifest-src: This directive defines allowed sources of application manifest files.
media-src: It defines allowed sources from where media objects like, and can be loaded.
object-src: It defines allowed sources for the and <applet> elements.
base-uri: It defines allowed URLs that can be loaded using an element.
form-action: This directive lists valid endpoints for submission from tags.
plugin-types: It defines limits the kinds of mime types a page may invoke.
upgrade-insecure-requests: This directive instructs browsers to rewrite URL schemes, changing HTTP to HTTPS. This directive can be useful for websites with large numbers of old URLs that need to be rewritten.
sandbox: sandbox directive enables a sandbox for the requested resource similar to the sandbox attribute. It applies restrictions to a pageβs actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy.
*: This allows any URL except data: blob: filesystem: schemes
self: This source defines that loading of resources on the page is allowed from the same domain.
data: This source allows loading resources via the data scheme (eg Base64 encoded images)
none: This directive allows nothing to be loaded from any source.
unsafe-eval: This allows the use of eval() and similar methods for creating code from strings. This is not a safe practice to include this source in any directive. For the same reason, it is named as unsafe.
unsafe-hashes: This allows to enable specific inline event handlers.
unsafe-inline: This allows the use of inline resources, such as inline elements, javascript: URLs, inline event handlers, and inline elements. Again this is not recommended for security reasons.
nonce: A whitelist for specific inline scripts using a cryptographic nonce (number used once). The server must generate a unique nonce value each time it transmits a policy. sha256-: Whitelist scripts with a specific sha256 hash
unsafe-inline
Working payload:
"/><script>alert(1);</script>
unsafe-eval
Working payload:
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
