Parameterized binding and sensitive word filtering block two types of problems, don't treat them as the same defense line.

Parameterized binding and sensitive word filtering are two types of issues: the former deals with 'external input being executed as a statement by the database', that is, risks such as SQL injection; the latter deals with 'text content that is not suitable for appearance on the site', that is, offensive words, marketing words, and inappropriate expressions. The criteria for judgment are different, and the consequences of failure are also different - if parameterized binding fails, it may result in data loss or even loss of server control; if sensitive word filtering fails, it brings content compliance and audit pressure. Treating them as the same defense line usually leads to two types of misjudgments: thinking that enabling filtering strengthens injection, or thinking that using ORM does not require an audit process.

Trigger points for each type of issue

The injection trigger point is in the query construction phase: request parameters, form fields, and sorting and filtering values in the URL. If they are directly拼进 SQL statements, the attacker can change the statement structure. It concerns how data is interpreted.

Trigger points for content risks are in the display and retrieval phases: comments, product descriptions, collected text, and user-uploaded fields containing words that should not appear. It concerns what data is said.

how far to parameterized binding

The core of parameterized binding is to separate the 'statement structure' and 'data': the SQL template is first defined, and the values provided by the user are only passed in as parameters, and the driver will no longer parse their grammatical meanings. To do it well requires three conditions: all queries go through the same data access layer, it is not allowed to concatenate raw SQL fragments in business code, and for positions that cannot be parameterized (such as sorting field names), use whitelist verification instead of escaping and passing them through.

AnQiCMS is developed based on GoLang, the technology stack is GoLang plus Iris framework and GORM, data access is unifiedly handed over to ORM processing, query construction does not fall into the template or business script; authentication side uses JWT,配合内置的防 SQL 注入与 XSS 防护，配合 built-in anti SQL injection and XSS protection, to converge common risks of input and output at the framework level. The value of this kind of ability lies in 'default like this', rather than requiring each secondary developer to remember to write it correctly.

Which part of filtering and review supplementation is missing

The content side is another process. AnQiCMS's content security settings include sensitive word filtering, keyword replacement, and content review: filtering intercepts according to the word library, replacement replaces the matched words with placeholders or permissible expressions, and review determines whether the content can enter the formal state. The three have different tasks - filtering and replacement are automatic actions, suitable for execution when saving; review is a manual node, suitable for checking before publishing.

Collection content and AI-generated content will increase this workload because the source is uncontrollable. In practice, common configurations are: filter upon entry, enter the review queue upon hit, and only allow release after passing, to avoid dirty content going online first and then making repairs.

Common misconception: treating filtering as reinforcement.

There are two types of typical configurations that seem safe but actually do not have a closed loop. One is 'Adding sensitive word filtering to the comment box, so you don't have to worry about interface parameters' - filtering does not change the query structure, and the injection surface is still there. The other is 'Using ORM means input safety' - ORM only covers its own queries, and manual statements and sorting fields bypassing ORM still need to be checked separately.

There is also a misunderstanding in reverse: thinking that the framework layer has strengthened injection, the content can be exempt from review. The framework does not judge the meaning, and the identification of违规 words depends on the word library and the review process.

Two sets of checks before going online

Check the three aspects of injection: Confirm whether the list and search interface filtering parameters go through the unified data access layer; confirm whether the sorting and pagination fields have a whitelist; confirm whether the error information will expose the statement fragment to the visitor.

Check the three aspects of content: Confirm whether the vocabulary covers the disabled expressions of the current business and has an update responsible person; confirm whether the keyword replacement rules will affect the normal content; confirm whether the content review status machine is traceable, and draft and formal content are separated with traces.

Common questions

What problems will there be if only one is uploaded?Only parameterized binding is applied, but content that violates the rules can still be published; only sensitive word filtering is applied, and the injection surface has not been affected at all, and the two types of risks exist independently.

Can keyword replacement replace manual review?No. Replace the expression of the hit words, review the context and compliance boundaries, and the content outside the hit still needs to be supervised by people.

Which rule is most easily broken during the second development?Bypassing the hand-written query of the unified data access layer. This failure will not report an error, but will only be exposed when detected, and such writing should be listed separately during code review.