In the Anqi CMS,archiveListTags are a powerful tool that allows us to flexibly display website content, whether it be conventional lists, related documents, or pagination lists. When we need to implement a search function,qThe parameter plays a crucial role, allowing us to dynamically filter and display content based on the user's input keywords. For example, in a list of articles, we can use{% archiveList archives with type="page" q="搜索关键词" %}This way to use it, or more commonly,archiveListAutomatically read the URL query parametersq=关键词and use it for search.

However, any feature involving user input requires careful consideration of secure coding.Users' input in the search box is not always harmless plain text; they may contain malicious code. If these inputs are not properly processed, they may pose potential security risks to the website.

Understandingqpotential risks of parameters

When the user enters content in the search box, this content will be passed asqthe value of the parameter to the server and used in the templatearchiveListLabel reading and usage.If these keywords are displayed directly on the page without processing, or participate in page rendering in an unsafe manner, it may lead to some security issues.The most common and direct threat is cross-site scripting (XSS).<script>alert('XSS');</script>Such code, and the page directly outputs this unescaped string, then the browser will execute this script, thus stealing user session information, tampering with page content, and even redirecting users to malicious websites.

The built-in security mechanism of the AnQi CMS template engine

Fortunately, the template engine of AnQi CMS (which is based on Django-like syntax, and engines of this kind usually have an automatic escaping mechanism) has considered this point in its design.This means that when we output the value of a variable directly in the template, the template engine usually defaults to escaping HTML special characters.<will be escaped as&lt;,>will be escaped as&gt;,&will be escaped as&amp;,"will be escaped as&quot;,'will be escaped as&#39;This automatic escaping is an important defense against XSS attacks.

This means that if we simply display the user's search keywords on the search results page, for example, by retaining the user's input in the search box,qwe can usually use them directly.{{ urlParams.q }}(AssumingurlParams.qIs to obtain the URL parameter value in the wayq)，without the need to add additional escape filters, because the template engine will complete this task for us.

Explicitly output encoding andsafeuse cases of filters

Although the template engine provides default auto-escaping, but the safe CMS also provides explicit output encoding filters, such asescape(or its abbreviation)e) andsafeto deal with specific scenarios.

  • escape/eFilter：Their role is to explicitly indicate that the template engine should escape the output content as HTML.Although this may be redundant in most cases (because it is already escaped by default), in certain specific situations, such as when you turn off the global auto-escape feature, or when you want to ensure that a certain variable is always escaped regardless, you can use them explicitly.{{ urlParams.q|escape }}.

  • safeFilterThis is a filter that should be used with caution. Its function isDisabledThe automatic HTML escaping function of the template engine, tells the template engine: "This content is safe HTML code, please output it directly and do not escape the special characters in it."}]It is typically used to display content that is indeed provided by administrators or other trusted sources, including valid HTML tags, on a webpage (for example, content generated by a rich text editor).qparameter value,strongly not recommendedUsesafeFilter, unless you have ensured that this string has undergone strict server-side cleaning and validation and does not contain any malicious HTML or JavaScript code. If it is not fully validated,qParameter usagesafeIt equals opening the door to XSS attacks.

Summary and **Practice

EnsurearchiveListtagsqParameter security encoding, the core lies in understanding and utilizing the default security mechanism of the security CMS template engine, and supplemented with appropriate practice:.

  1. Depends on default escapingIn most cases where user input needs to be displayedqThe parameter's context (for example, echoing keywords in the search box of the search results page), you can directly output the variable, because the Aiqi CMS template engine will default to HTML escaping, effectively preventing XSS attacks.
  2. Use with cautionsafe：Only use when the output content indeed contains valid HTML code that needs to be parsed by the browser, and you are completely trusting its source (such as rich text content edited by backend administrators, with content filtering mechanisms in place)safeFilter. Never apply to user input that has not been strictly verified.
  3. Multi-layered protection mindset

With these practices, we can use the Safe CMS with confidence.archiveListofqBuild powerful search functionality while ensuring the display of website content is safe and reliable.

Common Questions (FAQ)

Q1: AnQiCMS template engine does it default to escaping all variable outputs as HTML? A1:Yes, AnQiCMS's template engine usually defaults to escaping all variable outputs as HTML special characters to prevent cross-site scripting attacks (XSS). This means that unless you explicitly usesafeFilter, otherwise like<script>Such labels will be escaped when output as&lt;script&gt;.

Q2: When should we usesafeFilter? ForqWhether the parameters are applicable? A2: safeThe filter should only be used for HTML content that you fully trust and are certain does not contain any malicious code. For example, when you edit a piece of content with specific formatting (such as bold, italic) in a rich text editor in the background, and you want the front-end to display these formats, you can usesafe. But forqsuch parameters that come directly from the user's input search keywords,strongly not recommendedUsesafethe filter, because it bypasses the default safe escaping of the template engine, thereby creating an opportunity for XSS attacks.

Q3: Besides secure coding at the template level, are there any other security aspects that need to be considered when usingqparameters? A3:Of course. In addition to the output encoding at the template level, **it also includes processing user input on the server side,rigorous validation and cleaning. AlthougharchiveListThe underlying implementation of labels (Go language and its ORM) usually can effectively prevent SQL injection, but validating inputs (such as length limits, allowing only specific characters, etc.) can further enhance security and ensure that the input conforms to business logic.This is a multi-layered defense strategy that can protect your website more comprehensively.