Security and Audit

These issues often get mixed together: some are intentional security-policy blocks, some are third-party whitelist misconfiguration, some are data-export control, and some are after-the-fact auditing. If you do not separate those layers first, they are often misread as "the system is broken."

Why can a normal query still be flagged as SQL-injection interception?

Do not assume it is a false positive first.

If security interception is enabled and the request body contains content that triggers risk rules, the request may be treated as a SQL-injection risk.

For known cases like this, the customer-service guidance is to enable the following in conf/hengshi-sense-env.sh:

export ENABLE_BODY_ENCODE=true

The purpose of this configuration is to reduce the chance that raw request-body content triggers interception directly.
If the现场 symptom is "certain query parameters trigger interception while others do not," check this first before rewriting business SQL.

When should I suspect security interception instead of a feature defect?

Common signals:

• the same feature fails only with certain parameter values or content
• a different value works normally
• the message looks more like rejection, interception, or risk control than a normal query error
• proxy, gateway, or security devices also show corresponding interception traces

The key is not retrying blindly, but confirming whether the interception happened in the application itself, the proxy layer, or an external security device.

If I do not want users to freely take data out, what capability should I start with?

Start with export control in security policy, not with process-only restrictions.

The system supports:

• global control over whether data export is allowed
• finer control over which users may export and which may not
• export row limits

This is the right fit for "users may view data, but must not export large volumes."

What is the real purpose of export row limits?

It is not mainly about performance. It is about limiting data-exfiltration scale.

Typical use:

• allow users to export small sample data for checking
• prevent one-shot bulk export of large detail datasets

So when users ask "why can't I export everything," first confirm whether security policy is intentionally limiting it.

What does watermark protection really cover?

Watermarks affect not only pages, but also exported artifacts.

After enabling it:

• system pages can display watermarks
• exported PDF / PPT / PNG files also carry watermarks

This is especially useful for outward sharing, executive reporting, and external collaboration where screenshot forwarding and secondary distribution must be discouraged.

Why can't an app disable watermarks on its own?

Check whether the system-level global setting has allowed that control to be delegated.

Watermark behavior is global-first:

• if global watermark is off, apps cannot turn it on by themselves
• if global watermark is on but "allow app-level watermark disable" is not enabled, app admins still cannot disable it

So this is usually not an app-owner-permission issue. It is a platform-governance boundary.

Why protect public-link filters with HMAC signatures?

Because if filter conditions in a public link can be modified freely, others may probe and query data they should not see.

HMAC signature protection ensures that filter conditions embedded in a public link cannot simply be changed and reused.
If you send public links externally and those links contain filters, this capability is important.

Why does an embedded page in WeCom show Writable Error Page and look like a system failure?

In many cases this is not a broken HENGSHI page. It is a missing IP whitelist on the WeCom side.

The customer-service handling pattern is: configure the IP whitelist in WeCom admin and add the public IP of the HENGSHI SENSE server.

So when this happens, do not look only at the app frontend. Check third-party access restrictions in parallel.

If I need to know who exported data and how much they exported, where should I look?

Use system operation records / audit logs.

System administrators can filter by:

• time
• operator
• IP
• action
• result
• category

and more.

To audit data-export behavior specifically, filter by Export Data and inspect who exported what and how much.

What is the first thing to separate when troubleshooting security and audit issues?

Separate which layer the issue belongs to:

1. platform-native security policy (export control, watermark, HMAC, etc.)
2. interception triggered by request-body or query content
3. third-party integration restrictions (such as WeCom IP whitelist)
4. after-the-fact audit investigation (system operation records)

Once these four layers are separated, many "security issues" stop being treated as one undifferentiated problem.

Further reading:

• Security Policy
• System Log
• App Settings