False Positive Analysis for Mobile Traffic


  • This article provides guidance for how to confirm that Shape Defense for Mobile is working as expected after it has been enabled for real users. You will need to confirm that legitimate traffic is not marked as automation before mitigation is enabled.

Return to Integrating Shape Defense



  • Shape Defense for Mobile



After your app is released and there is live user traffic, confirm that Shape Defense is working as expected.

Specifically, confirm the following:

  1. Low or non-existent rate of requests with no Shape headers from the new application and requests with headers are marked as Human.
  2. Configuration fetch requests are made at an expected rate.

Although this documentation provides some guidance, this is a creative process. Please explore your traffic reports and examine anything unexpected. Resolve all issues before you turn on mitigation.


Access Shape Defense Summary




Step 1. False Positive Analysis

In this step, determine if the Shape solution ever marks legitimate traffic as non-human.

On the Silverline Reports page, filter traffic by the application version marker in the User-Agent. Observe the classification for the resulting traffic:

Is any traffic marked as non-human?  If yes:

  1. What is the Automation Type of the non-human Traffic?
  2. If the Automation Type is Token or Payload Missing, look at the distribution of IPs. Does the traffic look like user traffic, or some sort of automation? Is the traffic limited to a particular platform (iOS or Android)?
    • If the flagged traffic is an expected automation (i.e. monitoring service), consider allowlisting the IPs.
    • If the IP distribution looks organic, this may signify an SDK integration problem. Examine the endpoints which are being mitigated.
  3. If the Automation Type is something other than Payload Missing, this is unexpected behavior, please contact SOC ( to investigate further.


Step 2: Configuration Fetch Behavior

Configuration fetch occurs at particular times during the application lifecycle, including at application launch, at mitigation, and after four hours (if the application is in the foreground). Normally, you would see one configuration fetch per active user session.

Since some users launch an app but do not proceed further, and others have two sessions within the same four-hour period, you could see 0.5-2 sessions per configuration fetch on average.

Using Shape Defense Summary, confirm that for each platform, the ratio of configuration fetches to number of user sessions is at 0.5-2.

For example:

  1. Number of configuration fetches on iOS is 100.
  2. Number of login requests on iOS is 80.
  3. Configuration Fetch Ratio on iOS is 100/80 or 1.25 - within norm.

A higher configuration fetch ratio doesn't affect the efficacy of SDK operation; however, it does imply sub-optimal performance. Contact SOC ( if this ratio does not match expectations.


If the false positive analysis did not uncover any problems, you can turn on mitigation by switching from Flag action to Block or Redirect.


Related Content

Return to Integrating Shape Defense

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request