AutoCMS was designed with a strong focus on security from the outset, which is perfectly reflected in its concise and efficient Go language architecture. Its aim is to provide our users with a secure and stable content management environment.In daily content publishing and template creation, we often come across various template tags and filters.safeFilter is a powerful but also requires our special vigilance tool.It allows us to output raw HTML content in the template, but it is this 'freedom' that also harbors some risks that should not be overlooked, especially in terms of preventing cross-site scripting (XSS) attacks.

safeThe role and convenience of filters

In the template development of Anqi CMS,safeThe filter is a very practical tool.It allows us to render HTML code directly on the page, rather than escaping them into plain text.<script>/<img>/<div>auto) converts it to the corresponding entity character (such as&lt;script&gt;), causing this content to not be displayed in the style and structure we expect.

This is,safeThe filter comes into play. By adding|safefor example,{{ archiveContent | safe }}We are actually telling the template system: "ThisarchiveContentThe content in the variable is confirmed safe, please parse and display it as HTML code without any escaping.So that the images, paragraph styles, custom links, and other elements in the article can be perfectly displayed on the page.

safeXSS attack risk brought by filters

However, it issafeFiltering this feature of automatic escaping removal makes it a potential risk point.Cross-site scripting (XSS) attack is a common network security vulnerability. Attackers inject malicious scripts into web pages, and when users visit these pages, the malicious scripts are executed in the user's browser, thereby stealing user information, hijacking sessions, tampering with page content, and even conducting phishing operations.

when we usesafeThe system's default security escaping mechanism is bypassed when filtering. This means that if malicious script (such assafeis included in the variable of the filter (for example<script>alert('XSS');</script>），and these scripts have not been properly handled before the content enters the template, then the browser will directly execute these malicious scripts, leading to the occurrence of XSS attacks.

Common risk scenarios

In practice, the following situations are particularly worthy of our vigilancesafeRisks that filters may bring:

  1. User submitted content:This is the most common source of XSS attacks.Whether it is the comment section, message board, forum posts, or custom fields in the user's profile, any content that allows users to input and is ultimately displayed on the page may be injected with malicious scripts by malicious users.safeWhen filters are rendered, the website is exposed to risks.

  2. Untrusted external data source:Sometimes, we may obtain content from external APIs, RSS subscriptions, or other third-party services. If these external data sources have security vulnerabilities or if the content they provide has not been thoroughly reviewed, there may be malicious scripts hidden in them.safeFilter rendering may also trigger XSS attacks on our website.

  3. Even the content of the background management is not absolutely secure:We might think that the content published by the backend administrator is absolutely safe.But the actual situation is not like that.The administrator account has been compromised, or the administrator may have unknowingly copied and pasted content containing malicious code from an unsafe source, all of which can lead to contamination.safeFilter processing and display on the front end, the risk still exists.

  4. Misunderstanding and negligence of developers:Some developers may mistakenly thinksafeFilter can "clean" content, or be arbitrarily used during development and debugging.safeThis misinterpretation or oversight can easily lead to vulnerabilities.

How to effectively prevent risks

Understood the risks, the next step is how to effectively prevent them.safeThe filter itself is not 'evil', it is just a functional tool, the key is how we use it correctly:

  • Input validation and content sanitization is core:Regardless of where the content comes from, any data that may contain user input or data from untrusted sources must be strictly validated and sanitized before being stored in the database and before being rendered to the template. This means removing or escaping all HTML tags and attributes that could lead to script execution (such as<script>tags,onerrorProperty,javascript:Protocol, although front-end input validation can improve user experience, server-side purification is an indispensable part of the safety defense line.

  • Use only on content that is determined to be safesafe: safeThe filter should be considered as a 'whitelist' mechanism. Only when weOne hundred percent sureThe HTML content in a variable should be carefully constructed and completely harmless before using it. For example, only HTML content that has been strictly processed on the backend or generated by a trusted rich text editor is worth trusting and usingsafe.

  • UnderstandingautoescapeTags:AnQiCMS's template system also providesautoescapeLabels can control the automatic escaping behavior within a certain area. If a template area indeed needs a large amount of raw HTML, and we have fully assessed the source and safety of this HTML, then it can be used.{% autoescape off %}and{% autoescape on %}wrap it, to avoid repeatedly using each variable|safeHowever, this also requires a high level of vigilance and the ability to trace content sources.

  • Regular security audits and code reviews:Develop the habit of regularly reviewing template code, especially focusing on|safeThe usage location, check the source and purification process of the corresponding variable. At the same time, performing security vulnerability scanning and penetration testing on the website can help us discover potential XSS vulnerabilities.

In short, the CMS provided by AnqisafeThe filter brings great convenience to us for flexible handling of HTML content, but its essence is the removal of an important security protection.When using it, we must always be vigilant, treating input validation and content sanitization as the top priority, and ensuring that only content that has undergone strict security review can be marked as 'safe', thereby effectively preventing XSS attacks and ensuring the security of the website and user data.

Common Questions (FAQ)

1.|safefilters and{% autoescape off %}What are the differences between tags? Which one should I use?

|safeThe filter acts on a single variable, telling the template system not to escape the value of this variable.{% autoescape off %}Labels act on a code block, it will disable the automatic HTML escaping of all variables within the block until{% autoescape on %}or code block ends. Usually, if you only need to disable escaping on a few variables,|safeMore convenient and with a smaller range. If you are sure that all variables in a certain area (such as displaying the full content of a rich text article) do not need to be escaped, and that this content has been fully sanitized on the backend, then use{% autoescape off %}Can reduce the redundancy of template code. But regardless of which one is used, the premise is to have absolute control over the content safety.

2. Why does the Anqi CMS provide a feature that may lead to XSS risks?safeFilter?

safeThe existence of the filter is to meet certain legitimate needs, such as displaying the text and image content edited by the background rich text editor, predefined HTML code snippets, or structured HTML obtained from a trusted source.In these scenarios, the content itself contains HTML tags, and forcing escaping will cause display anomalies.safeThe filter is a necessary tool that gives developers flexibility, but it also requires developers to take corresponding security responsibilities to ensure that the content passed to it is truly safe. The default automatic escaping mechanism of the Anqi CMS has provided basic protection, safeIt should be used only when the developer is fully aware and assumes the risk.

3. If my website's frontend uses a rich text editor and it has built-in content sanitization, do I still need to sanitize it on the backend?

Yes, backend sanitization is absolutely necessary, and it is the last and most critical line of defense.The front-end sanitization feature can enhance user experience, such as filtering out non-compliant inputs in real-time, but it is easy to bypass.Users can bypass frontend validation by directly sending requests to the server, disabling JavaScript, or modifying frontend code.Therefore, regardless of how the front-end handles it, all data submitted by users or from external sources must be strictly validated, filtered, and sanitized on the server side to ensure that the data entering the database and templates is secure.