XSS prevention requires three aspects: input filtering, output encoding and CSP. 1. Input filtering: HTML escapes the user input content, use the whitelist mechanism to process rich text, prohibit dangerous tags, and check them simultaneously on the front and back ends; 2. Output encoding: Process according to the difference in output location, HTML content is escaped with entity, attribute restricts type, JS strings are escaped accordingly, and URL parameters are handled with encodeURIComponent; 3. CSP settings: Restrict script sources through HTTP response header Content-Security-Policy, disable inline scripts, and use event listeners instead as the last line of security defense.

XSS (Cross-Site Scripting) is one of the most common and overlooked security issues in front-end development. As the core language of the front-end, many security vulnerabilities are directly related to how they are used. To truly prevent XSS, we cannot rely solely on the default protection of the framework, but also start with coding habits and overall architecture.

Input filtering: Don't let malicious content come in

The essence of XSS is that an attacker injects malicious scripts into the page and executes it. The most direct way is to do filtering during the user input stage.

• HTML escapes all user input content, such as <script></script> becoming <script></script>
• Use the whitelist mechanism to handle rich text content, and do not easily allow dangerous tags such as <script></script> and on* attributes.
• The same check should be done on the server side, and the front and back ends should not be lazy.

For example, if you use innerHTML to directly insert the data entered by the user, it basically opens the backdoor for the attacker. TextContent or React's {} interpolation method should be used first, which will automatically escape special characters.

Output encoding: Different contexts should be treated differently

Different output positions and different defense methods. You cannot use the same set of rules to process data placed in HTML tags, attributes, or JS strings.

• HTML content : escaped with HTML entities
• HTML attributes : In addition to escape, it is best to limit the attribute types, such as input's value, which is safer.
• JS string : JS string escape must be performed before splicing into script tags
• URL parameters : Use encodeURIComponent to handle

For example, if you are writing a dynamically generated <a href="..."></a> link, if the URL parameters come from user input, you must encode first, otherwise it may become a jump to the entrance of a malicious website.

CSP (Content Security Policy): The Last Line of Defense

Even if you don’t do it well in the front, CSP can help you with the bottom line. It can limit the page to only load scripts from the specified source, and can also prohibit inline script execution.

• Setting up HTTP response header Content-Security-Policy
• Forbid 'unsafe-inline' , that is, code like <script>...</script> is not allowed to run
• If you want to use an inline event handler (such as onclick), it is recommended to migrate to addEventListener

CSP is not omnipotent, but it is the last line of defense for your application security. Especially in large projects, it is difficult to ensure that every place can be escaped and filtered correctly, and CSP becomes particularly important at this time.

Basically that's it. Prevent XSS from being uncomplicated, but it is easy to ignore details. As long as you develop good coding habits and cooperate with the right tools and strategies, most common XSS attacks can be avoided.

The above is the detailed content of A crucial JS roundup on preventing common security vulnerabilities like XSS. For more information, please follow other related articles on the PHP Chinese website!