---
url: /v6.2/en-us/security-audit-faq.md
---
# 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`:

```bash
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](security-policy.md)
* [System Log](audit-log.md)
* [App Settings](app-setup.md)