> For the complete documentation index, see [llms.txt](https://0xkourama.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xkourama.gitbook.io/blog/vulnerabilities-and-techniques/web-vulnerabilities/xss-prevention-or-csp.md).
# XSS prevention | CSP
| Content |
| ---------------------------------------------- |
| βΆβ Inputs & Outputs |
| βͺβ« Whitelisting vs blacklisting |
| π‘ X-XSS-Protection |
| β Content Security Policy (CSP) Respose Header |
| π Referance |
### βΆβ Inputs & Outputs
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:
```
< converts to: <
> converts to: >
```
In a **JavaScript** string context, non-alphanumeric values should be Unicode-escaped:
```RUBY
< converts to: \u003c
> converts to: \u003e
```
### βͺβ« Whitelisting vs blacklisting
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.
***
### π‘ X-XSS-Protection
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:
```http
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=
```
**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) Response Header
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()
#### Directives:
**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 \
