First of all, the content of this chapter is about WEB security, due to my knowledge limited this article may be wrong, if you have any questions can contact Uncle Wen (darrel.hsu@gmail.com ). Thank you very much for @ Sogl and @ Jianxin ~ The prevalence of WEB makes the network society richer, followed by security issues. If he is safe to accept user input and correctly display it, it is the pursuit of a vast number of WEB programs. One of them is to prevent XSS. (If you do not know XSS, you can look at the http://baike.baidu.com/view/50325.htm here) In general, the main harm of XSS is: first, the page may be customized by malicious or other reasons, second, it may cause intra-site data leakage.XSS page CustomizationModern WEB content is mostly produced by manufacturers and users. The following example shows the data generated by the manufacturers and users: <div class = "profile"> <dl> <dt> $ title </dt> <dd> $ description </dd> </dl> </div> where $ title and $ description represent two variables, output a title and content generated by the user. Take $ title as an example. If the content in $ title is: <script> alert (1) </script>, the content output to the browser is: <div class = "profile"> <dl> <dt> <script> alert (1) </script> </dt> <dd> description </dd> </dl> </div>: as you can see, this script is not expected by developers. We can understand this page as being customized. Maybe when you get a URL that the HOST can trust, but unfortunately this URL has been customized by malicious disseminators through XSS, the user may trust the content output on this page. The results can be imagined. To prevent this situation. Generally, WEB developers use the escape safe charactor method (change <to & lt ). However, this kind of prevention only keeps the output and display consistent with the input through escaping. This is just a way to solve HTML injection. From the security perspective, https://i.xiaomi.com Only display from https://i.xiaomi.com . The same https;: // I .xiaomi.com is only allowed https://land.xiaomi.net Process resources under the domain name https://i.xiaom.com . Based on the above security restrictions, the existing mechanism cannot meet the requirements. Fortunately, W3C published a draft CSP based on this security limitation. The draft is still in progress, which means it may be replaced by other norms or drafts at any time, and of course it may be abandoned. However, IE10 and Webkit have already implemented the draft. With support from browser vendors, this is reliable.What is CSP?CSP is composed of the first word of the word "Content Security Policy". This draft aims to reduce the number (Note that the number here is reduced rather than eliminated ~) A type of content injection, such as cross-site scripting (which may be attacks ~ Dear user !). CSP is a security policy statement defined by developers. The previous sentence is too confusing, simply put, the CSP is used to specify a trusted content source (the content here can refer to scripts, images, iframe, fton, style, and other possible remote resources ). Through the CSP protocol, the WEB is in a secure operating environment.How to ApplyCSP can be specified in two ways: HTTP Header and HTML. HTTP is specified by adding a Header in HTTP, while the HTML level is specified by the Meta tag. CSP has two types: Content-Security-Policy and Content-Security-Policy-Report-Only. (Case-insensitive) HTTP header: "Content-Security-Policy:" Policy "Content-Security-Policy-Report-Only: "The Policy HTTP Content-Security-Policy header can specify that one or more resources are secure, while Content-Security-Policy-Report-Only allows server checks (unforced) A policy. Policy definitions with multiple headers are first defined by priority. (Currently, Firefox uses x-Content-Security-Policy, and WebKit uses X-WebKit-CSP. Maybe the draft will be unified soon after it is finalized ?)HTML Meta:<Meta http-equiv = "content-security-policy" content = "policy"> <meta http-equiv = "content-security-policy-report-only" content = "policy "> meta tags are consistent with HTTP headers only in line. Like HTTP headers, the first defined policy is preferred. If both the HTTP header and META definition exist, the HTTP definition is preferred. If your browser has executed a CSP policy for the current document, the definition of META will be skipped. If the META tag lacks the content attribute, It is skipped. In the developer draft, a special note is: In order to use the policy to take effect, the meta element header should be placed at the beginning to prevent the improvement of human CSP policy injection. Of course, the CSP draft is still being improved, and the draft also raises some special questions. For example, a META mechanism should be set up to ensure that the document will not be injected with malicious CSP rules.CSP syntaxCSP policy content is separated by a number of CSP commands (the leading and trailing spaces of each CSP command are ignored): policy = [directive * (";" [directive])] each CSP consists of a command name and an optional command value. direve VE = * WSP [directive-name [WSP directive-value] directive-name = 1 * (ALPHA/DIGIT /" -") directive-value = * (WSP/<VCHAR success t ";" and ","> the CSP policy can be a specified URL or protocol (optional) + HOST + POST (optional) + path (optional) command. This command indicates that the resource is safe or not safe.Example:1. Only the Content-Security-Policy: default-src 'self 'resources of this site are allowed. 2. The resources of this site, images in any location, and scripts under trustedscripts.example.com are allowed. & Nbsp; Content-Security-Policy: default-src 'self '; img-src *; script-src trustedscripts.example.com