Application Real-Time Monitoring Service:Application Security FAQ

Does Application Security affect application performance?

The overhead is negligible. Benchmark tests show the following impact:

Two built-in safeguards prevent interference with your application:

• Observation mode -- Detects threats without blocking requests, so you can verify stability before enabling active protection.

• Soft fuse escape mechanism -- Minimizes interference to your application by providing an automatic escape mechanism.

Which languages are supported?

Application Security supports Java applications only. The following table lists the minimum agent versions required:

No code changes are required.

How do I enable Application Security for an application?

1. Enable Application Security in the ARMS console.

2. Restart all instances that run your application.

No application code changes are needed. For detailed steps, see Access application security.

How does protection work after I enable it?

Application Security defaults to Monitor mode, which detects and records attacks without blocking them.

After the application runs stably in Monitor mode, switch to Monitor and Block to actively block attacks.

How this differs from a traditional firewall:

A firewall matches traffic against known patterns and flags requests that _look_ malicious -- even if they pose no real threat. For example, a PHP exploit targeting a Java application triggers a firewall alert but cannot actually harm the application. Application Security takes a different approach: it only records real attacks, resulting in a significantly lower false positive rate. When Application Security does report an attack, treat it as a high-priority security event because it means an attacker has broken through the outer defense and can enter the internal environment of the application.

Why is the Attack Statistics page empty?

Check these causes in order:

1. Instances not restarted. After you click Add in the ARMS console, restart _all_ instances for the application. Restarting only some instances leaves the others unprotected.

2. Java agent version too old. Application Security requires Java agent v2.7.1.2 or later for automatic upgrades (container and EDAS applications), or v2.7.1.3 or later for manual upgrades.

3. No real attacks have occurred. Unlike a traditional firewall that reports attacks when it detects malicious characteristics in packets, Application Security only records real attacks. For example, attack requests that exploit PHP vulnerabilities are ineffective in the Java environment. An application may not have a large number of real attacks. However, when an attack does appear, treat it as high-priority -- it means an attacker has broken through the outer defense and can enter the internal environment of the application and perform risky actions. You must intercept attacks or fix security vulnerabilities in a timely manner.

How do I handle vulnerabilities on the Risky Component Detection page?

Vulnerabilities listed on this page are common vulnerabilities. Even if not actively exploited today, they may be exploited in the future after attackers modify application code.

Immediate mitigation: Switch the protection mode to Monitor and Block. This defends against exploitation of known vulnerabilities.

Permanent fix: Upgrade or patch the affected components:

1. In the ARMS console, go to Application Security > Risky Component Detection.

2. Find the vulnerability and click View in the Details column.

3. On the Details tab, check the Fix Reference section for official upgrade instructions or patches.

4. If no fix is listed, search for the CVE ID of the vulnerability in a search engine to find community-provided remediation guidance.