IP access control and WAF

The platform provides two layers of source security: API-level IP black/whitelists can be configured precisely per environment and per API; the built-in gateway WAF applies unified detection for SQL injection, XSS, and path traversal attacks to all open APIs. Both are independent of authentication and rate limiting.

Layer 1: IP access control

Entry

Security Management → Flow control rules → IP access control.

List fields

Column	Description
Rule ID	IP rule ID
Rule name	A recognizable name
Rule type	Blacklist / whitelist
IP address	IPs or IP ranges included in the rule
Bound APIs	Number of APIs bound to the rule
Modified time	Most recent update time

The list supports filtering by rule name and environment.

Create an IP rule

1. Click "New";
2. Select the environment (cannot be changed after creation);
3. Enter a rule name;
4. Select the control type:
   • Blacklist: IPs in the list are denied and all others are allowed;
   • Whitelist: only IPs in the list are allowed and all others are denied;
5. Enter IP addresses separated by commas; the range syntax startIP~endIP is supported;
6. Save and bind APIs.

Each entry in the IP list is validated as IPv4, and both ends of a range must be valid IPv4 addresses.

Execution logic

• The gateway reads the API's IP rules after authentication;
• If no IP rule is configured for the API, the request is allowed directly;
• An empty rule type or white is treated as a whitelist, and black as a blacklist;
• When a deny condition is matched, the gateway returns HTTP 200 with business code 40012 and the message "The IP address is not in the valid range, {client IP}";
• The client IP is resolved by the gateway from request headers and connection information; in proxied deployments, make sure the gateway can obtain the real source IP;
• When MCP tools/call resolves to the target API, API-level IP validation is skipped, because app-level IP whitelisting has already been validated at the MCP entry, so the same request is not blocked twice.

Difference from credential IP whitelists

Dimension	API-level IP rule	App credential IP whitelist
Configuration location	Security Management → IP access control	Account Center → App credentials
Scope	A specific API in a specific environment	The entire app credential
Error code	40012	40018
Applicable authentication	All authentication methods	Requests that use the credential

The two checks are independent and can be configured at the same time. The credential dimension also validates app status, the MCP switch, and other conditions; see app credentials and authorization for details.

Layer 2: WAF protection

The WAF runs inside the gateway and performs unified attack signature detection on open API traffic. It currently has no standalone management page; the switch is controlled by deployment configuration.

Switch and defaults

Configuration item	Default	Description
apigo.waf.enabled	true	Master WAF switch; when disabled, all requests pass through directly
Maximum request body size	10 MB	Larger requests are blocked directly without reading the body content
Admin backend traffic	Skipped	Admin backend routes do not pass through the WAF

Detection scope

Target	Rule type	Description
Path	Path traversal	Match ../ and ..\ after normalization
All query parameters	SQL injection, XSS, path traversal	Each parameter value is checked individually
High-risk request headers	SQL injection, XSS	Only User-Agent, Referer, X-Forwarded-For, X-Real-IP, and X-Requested-With are checked
Request body	Size check only	Content is not read, avoiding memory overhead for large files and binary requests

Signature or encoding headers such as Cookie, Authorization, and X-Sign are not scanned by the WAF, to avoid false positives.

Rule signatures

SQL injection: union queries, tautologies (or 1=1, and '1'='1'), into outfile, xp_cmdshell, information_schema, time-delay functions, benchmark(, and similar patterns.

XSS: <script>, javascript:, event handlers (onload=, onerror=, etc.), <iframe>, <svg>, eval(, document.cookie.

Path traversal: ../ or ..\ after decoding.

Normalization

To reduce the risk of encoding-based bypasses, text is processed as follows before detection:

1. Repeated URL decoding, up to 5 times;
2. Strip /* */ block comments and -- line comments;
3. Remove control characters and collapse whitespace;
4. Convert everything to lowercase.

As a result, multiple rounds of URL encoding on parameters cannot bypass detection.

Blocking response

When the WAF matches, it returns HTTP 400 with business code 40017 and the message "The request contains illegal characters and has been blocked by the WAF", sets Api-Response-Type=error, and records the call as failed in the call log.

Handling false positives

The WAF is signature-based, so legitimate business parameters containing the following content may be misclassified:

• Text containing strings such as javascript:, <script, or onclick=;
• Free text containing similar expressions such as 1 or 1=1;
• Parameter values containing '; or ../.

Suggested handling:

1. Adjust business parameters to avoid passing script fragments or SQL fragments directly;
2. Put rich text, code snippets, and similar content into the request body (the WAF does not scan body content);
3. If the business genuinely requires it, assess the impact of disabling the global WAF before adjusting the deployment configuration;
4. Use the traceId and source IP in the call log to locate the specific request that matched.

Position in the governance chain

The WAF runs before authentication, so unauthenticated malicious requests are also blocked; IP rules run after authentication, so a request must pass authentication before reaching API-level IP checks.

Limitations and notes

• IP rules support IPv4 only; CIDR ranges are not supported, so use startIP~endIP for ranges;
• When multiple IP rules match the same API, the final result depends on the rules currently bound to the API; avoid configuring contradictory blacklists and whitelists for the same API;
• The WAF does not scan request bodies and cannot replace API input validation and parameterized queries;
• Disabling the WAF is a global action that affects all open APIs;
• All blocked requests are recorded in the call log; combine this with the analytics dashboard to observe attack trends.