How To Configure Silverline Shape Defense Protected URLs


  • In this article, you will learn how to configure Silverline Shape Defense Protected URLs on the Silverline Portal
  • This article assumes that you have already enabled a Proxy Service for your Application and are now enabling Silverline Shape Defense.

Return to Integrating Silverline Shape Defense



  • Silverline Shape Defense


Procedure for Defining the Protected URLs

Best Practices:
  • We suggest running through the configuration procedure with a non-production (e.g. QA) application first to test that everything is working as expected
  • Once you have migrated to a production application, set the Action to FLAG
  • Do not mention "automation", Shape, or Silverline in the mitigation response body to not expose additional information to the attackers and keep it anonymous to the client.
  • Do not configure more than 10 different endpoint matchers. See Q&A: What are the Silverline Portal Configuration Limits?


Silverline portal provides an interface to specify all URLs which need Shape Defense protection. 


Accessing Shape Defense UI

To access the Protected Endpoints screen:

  1. Navigate to Configs > Proxy / App Management
  2. For a particular application, click Edit.
  3. Choose: HTTPS (443/443) HTTP (80/80)
  4. Choose Shape Defense tab


Protected URLs

For each URL, we must specify: Path, Application Type, Method, and Action.





Defines a path matcher for the protected requests.  The field contents must meet these requirements:

    • start with / 
    • can use glob patterns: * ? [ ]
    • must close any open bracket [ with ]
    • brackets must include only valid URL characters
    • will not specify /* as a protected URL 
    • use / to protect the root

Example 1: /application/version[0-9]/login

Example 2: /myapp/service/*

Example 3: /*/login.aspx

Example 4: /api/*/connection/*/*

Example 5: /api/connection/[a-zA-Z0-9_]*/set*


Application Type

Specifies if this is a Web, Mobile, or Web Scraping URL.

Shape Defense uses different algorithms for Web, Mobile and Web Scraping requests. When defining a protected URL, we must specify which Application Type it belongs to. If the same URL is used with both Web and Mobile applications then chose Web & Mobile.

For the Web & Mobile type, you must provide a header which distinguishes Mobile requests from Web. The specified header value can use a wildcard (*) to match a substring.


For example:

Would Match:
User-Agent: Android 10; MyApp/1.0
User-Agent: Android 9; MyApp/2.0


Would Match:
X-App-Version: 4.1
X-App-Version: 4.3



Defines which method types should be evaluated by Shape Defense engine.

  • Supported Methods: POST, GET, PUT, DELETE


Controls what action Silverline will take when request is deemed malicious.

  • FLAG - traffic will be permitted to proceed to the application. It will be marked as malicious on the Shape Defense reports.
    • Optionally, an HTTP header can be passed to the application specifying Automation Type. If the header name value is empty, or request was legitimate, no header will be sent.mceclip5.png
  • REDIRECT - If the traffic is determined to be automated, the proxy will respond with a 302 Redirect, and the specified location. mceclip1.png
  • BLOCK - If the traffic is determined to be automated, the proxy will respond back with a 200 OK HTTP Response code and the specified response body content. Maximum blocking message size is 2,048 characters for a custom blocking message.
    • mceclip6.png
  • Force Action checkbox is used when validating Shape Mobile SDK Integration. When checked, Silverline forces mitigation of all traffic to the endpoint, regardless of telemetry. This option is intended for testing mitigation, and not for production use.

Additional Protected URLs and Order of Matching

  1. For additional Endpoints, click Add and provide the required information (Path, Application Type,  Method, Action). Do not configure more than 10 different URL matchers (see Q&A: What are the Silverline Portal Configuration Limits?)
  2. After all matchers are defined for all URLs, move the matchers within the interface to adjust their order. When the request matches one of the entries starting from the top, none of the remaining entries are evaluated.


Related Content

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