Assess Rules

Assess Rules allow you to detect specific types of vulnerabilities, such as SQL Injection or Cross site scripting, in an application. These rules are language specific, and can be turned on or off for each environment and each application.

How It Works

Contrast provides out-of-the-box rules that can be applied to your applications. Organization or Rules Admins can configure Assess Rules, and also see the rules applied across your portfolio from the Policy Management page or an application's details page. Each rule is categorized with a Severity and Description to provide more information in the Asses Rules grid.

Manage Rules

Policy Management

View Assess Rules by going to the User menu > Policy Management > Assess Rules tab. In the Assess Rules grid, thermometer charts show the number of applications that have each rule applied for each environment. Hover over the charts to see a list of the application names for each number count.

Rule configuration

Click on a rule for a grid view of the applications to which the rule can apply. Use the toggles to turn each rule on or off for each application per environment. To update multiple environments at once, use the checkboxes to select the appropriate applications, and click the button to Change Mode; in the dialog that appears, use the toggles to turn the rule on or off for each environment. Click the Done button to save your changes.

To update rule settings, click the settings icon, and complete the following steps in the dialog that appears.

  • Use the dropdown menus to choose the Likelihood, Impact and Confidence Level of the vulnerabilities for which this rule is intended.

    • Select the checkbox to Override to enable to option to update these fields after the configuration is saved.
  • In the Risk Description field, enter additional information regarding potential consequences of exposure to this vulnerability. You can also provide a Recommendation.

  • In the References field, enter a link to an external reference related to the specific vulnerability to provide more context for the rule.

Default policy

Click the link above the grid to configure the default policy, if you want set default rules for new applications. Use the toggles to turn the rules on or off for each environment. Contrast will automatically apply all rules enabled per environment to each new application.

Application page

View Assess Rules by going to the Applications page grid > Policy tab > Assess button. Use the toggles to turn each rules on or off per environment. To update multiple environments at once, use the checkboxes to select the appropriate rules, and click the button to Change Mode; in the dialog that appears, use the toggles to turn the rule on or off for each environment.

Note: When more advanced rules are required, ask Contrast's Customer Support team for help with setup.

Security Controls

About Security Controls

Security controls are methods in your code that make sure data is safe to use. Only users assigned an organizational role of Rules_Admin or higher can view or modify security controls.

There are two types of security controls:

  • Input Validators are methods that accept a user input and take corrective action if unsafe data is received.

  • Sanitizers are methods that clean the data passed in, rendering it safe for consumption by any interpreter. Many sanitizers may prevent one type of attack, but not necessarily another.

Create and Manage Security Controls

Policy Management

Access security controls by navigating from the User menu > Policy Management > Security Controls tab. If there are existing security controls, click on the name in the grid to edit further details or delete it altogether. You can also edit the API directly in the grid.

To create a new security control, click the Add Security Control button.

After choosing a Name, Type and Language, specify the API and choose the vulnerability rules to which you'd like to apply the control. You can choose All, or select one or more individual vulnerabilities.


  • Servers may require restart. Contrast provides a list of servers affected by your selection.

Vulnerability Details

The Details tab is available for specific vulnerabilities for which Contrast captured runtime data flow. If Contrast notices a potential security control or an interesting event, it's shown in the tab as a low severity (green) event. After expanding the details of this event, you can click a button to add a security control.

If you mark a vulnerability as Not A Problem with the reason "Goes through an internal security control", you have the option to define that security control at this time.

In both vulnerability contexts, the Add Security Control dialog gives you the option to immediately create another control in your current location.

API Guidelines

When specifying the API, it's important to consider the following conventions:

  • Java must include method name and parameters. Use fully qualified types, intended to target only java.lang.String parameters (not boolean, int, long, short double, float, etc.).

  • .NET must include return type (or void), method name and parameters. Use fully qualified types, intended to target only System.String parameters.

  • Node must include the function to be marked and the package module name. For individual files in a package, include the file path relative to the application's root directory.

  • Mark the parameters that are going to be validated or sanitized with an asterisk ( * ).

Suggested Security Controls

If Contrast recognizes potential security controls, they're automatically populated in a Suggestions section in the Security Controls grid. (You can hide the section by clicking on the caret in the header row.) Suggestions are governed by Enterprise Access Control, which allows a user to see suggestions from applications only if they have a View role or higher.

Contrast names suggested security controls with the class and method; however, you can edit the Name, API and Type fields inline before adding it as an active security control. Hovering over the API gives the name of each application in which it was discovered, which links directly to the Vulnerabilities tab in the application's Details page.

Click the Add icon in the row to accept the suggestion and move it up in the grid as a Rule. Anyone with a Rules_Admin role can then view or edit it. Click the Delete icon to remove the suggestion (with option to Undo it). Contrast doesn't repeat suggestions, so once it's deleted, an API is never suggested again. There is no way to view historical suggestions or get them back.


Auto-discovered security controls generate notifications OnEvent in Contrast the very first time they are discovered, regardless of the application. If a control is discovered for an application for which a user doesn't have View role or higher, they won't receive the notification.

Protect Rules

Protect Rules allow you to set applications to monitor for attacks. Every rule corresponds to an attack type, such as SQL Injection or Cross-Site Scripting, that seeks to exploit any vulnerabilities in both custom code and third-party libraries.

Contrast ships with the following built-in protection rules:

  • Bean Classloader Overwriting: Carefully crafted inputs can be used to abuse some bean libraries into loading malicious class loaders, which can then load evil arbitrary code.
  • Command Injection: Carefully crafted inputs can execute tainted commands.
  • Cross Site Request Forgery: A CSRF attack can be used to trick a legitimate user into making an illegitimate request.
  • Cross-Site Scripting: A web application vulnerability that allows users to run arbitrary JavaScript in other user's browsers.
  • Expression Language Injection: Many frameworks and custom code vulnerabilities around accidentally evaluating user inputs as expression languages like OGNL, SpEL, or JSP EL.
  • Method Tampering: An attack against authentication or authorization systems that have implicit "allow all" settings in their security configuration.
  • Padding Oracle: A high-volume attack that abuses the presence of error conditions when processing inputs with bad padding, which can be used to decrypt and encrypt ciphertext.
  • Path Traversal / Local File Include: A vulnerability that allows users to control which files are opened and read by application.
  • Regular Expression DoS: A DoS attack that allows carefully crafted inputs to trick innocent but regular expressions to run indefinitely.
  • SQL and NoSQL Injection: Carefully crafted inputs can alter the SQL or NoSQL queries the application uses, and steal data or execute code.
  • Untrusted Deserialization: A web application vulnerability that allows users to pass arbitrary objects to a deserializer, allowing for remote code execution.
  • XML External Entity Processing: A vulnerability in XML processing that can lead to file read/writes and remote code execution.

Configure a Protect Rule

You can enable a Protect Rule on an application within the application's details page or from the Protect Rules tab in the Policy Management page.

Application page

Click on an application name in the Applications page grid, and go to the Policy tab to configure Protect Rules. Search for a rule by name or use the dropdown menu above the grid to filter for protect rules only.

For each rule, you can define one configuration per environment. Click the dropdown menu(s) in the grid row to set the status of the appropriate environment(s), and choose from the following options:

  • OFF disables the rule altogether.
  • MONITOR enables the agent to identify attacks and report them.
  • BLOCK enables the agent to identify attacks, report them and block the attack.
  • BLOCK AT PERIMETER BLOCK (P) allows the agent to make a blocking decision before the application is able to process the request. This option is not available for all rules.

Note: By enabling a different configuration per environment, you can test different policies in preproduction environments without disrupting production defenses.

To manage Protect Rules in bulk, check the box in the row for each rule that you want to edit, and then click the button to Change Mode. In the dialog that appears, select which environments to modify and which mode to apply, and then hit Save.

Across applications

Organization and Rules Administrators can also manage Protect Rules by going to the User menu > Policy Management > Protect Rules tab. The grid displays how your Protect Rules are being applied across your portfolio. Use the search field to find a rule by name or use the dropdown menu to filter the rules by language.

Click on a rule to configure settings for all associated applications. Click the dropdown menu(s) in each grid row to set the status of the appropriate environment(s), as described in the previous section.

Virtual Patches

Virtual patches are short-term, custom defense rules that protect against specific, newly discovered vulnerabilities in your code. You can specify the criteria for each attack event, to which application(s) the patch applies and in which environments the patch is enabled.

Manage Virtual Patches

Organization and Policy (Rules) Administrators can view and manage their virtual patches by going to the User menu > Policy Management > Virtual Patches tab. Find virtual patches by using the language filters in the dropdown menu or entering the rule name in the search field above the grid.

Add a virtual patch

To create a new virtual patch, complete the following steps:

  • Click the button to Add Virtual Patch above the grid.

  • In the Add Virtual Patch form, add a Name and Description for the patch.

  • In the Apply to section, use the radio button to choose whether the rule applies to specific Applications, an Application language or an Application technology. After clicking the appropriate button, use the multiselect field that appears to further refine your choice.

  • Use the dropdown menus to define the Conditions under which the patch should apply to your application selection(s). Select the link to Add another condition in a separate row, if necessary.

  • Click the Add button to save the configuration.

Edit a virtual patch

Click on a name to edit the rule configuration. Click the trashcan icon below the Edit Virtual Patch form or in the grid row to delete a rule. You can also use the toggles in the grid to enable or disable each environment.

Log Enhancers

Log Enhancers are instrumentation instructions that allow the Contrast agent to log additional parameters and data in the application without requiring any source code changes. By using these deep security instrumentation techniques, a user can specify the API and parameter to log, and the Contrast agent adds this information to the security.log file as part of RASP logging.

Manage Log Enhancers

Organization and Policy (Rules) Administrators can manage Log Enhancers by going to the User menu > Policy Management > Log Enhancers tab.

To find an existing rule, use the dropdown menu to filter them by language or type the rule name in the search field above the grid.

Add a Log Enhancer

To create a Log Enhancer, complete the following steps:

  • Click the button to Add Log Enhancer above the grid.

  • In the form, add a Name and Description for this Log Enhancer.

  • In the dropdown fields, choose a Log Level and Log Type.

  • In the API to Log section:

    • Choose a Language from the dropdown menu.

    • Then enter the API in the structure <class_name>.<method_name>(<argument_types>). Example:

      public boolean com.acme.Authenticator.authenticate(String user, String password)
    • Enter the log description in the Format field, including relevant data from the function call. You can include any of the following placeholders in your message:

      • {O}: Print the String-ified version of the Object on which this call is made. If the method is static, this may be null or empty.
      • {Pn}: Print the given parameter at index n. Note that n is zero-based.
      • {P1}: Print the the first parameter into the message.
      • {R}: Print the return value of the function.
  • Click the Add button to save the rule.

Edit a Log Enhancer

Click the name in the grid to go to the Edit Log Enhancer form, where you can adjust the log level using the dropdown menu. Use the toggles in the grid row to enable or disable the rule in each environment.

Application Exclusions

How It Works

Exclusions are used to suppress events that you don't want to hear about for one reason or another – usually because there's a compensating control that isn't visible from the application perspective. For example:

  • As an administrator, you need to change the HTML that shows up on your web page, even though this qualifies as a Cross-Site Scripting (XSS) vulnerability. In this case, you can create an exclusion that prevents these changes from being reported.

  • You use an edge device to place the correct headers on outbound HTTP responses to stop Clickjacking attacks. However, it's very likely that Contrast will appropriately report the issue because the application never provided the required protection. By using an exclusion, you prevent your developers from having to worry about understanding a complicated security issue that you've handled upstream.

  • When you’re testing beta rules or rolling out new rules, exclusions can be used to suppress false positives.

Types of Exclusions

Exclusions can apply to an input, URLs or code. Contrast won’t process any inputs that match the exclusion criteria, and each exclusion only applies to the application for which it was created. Review the following options for the type of exclusion you would like to set up.


Contrast allows you to specify a particular type of input. Any findings using this input will be suppressed.

  • For Parameter, Header and Cookie: You must specify the name of the particular input for which you wish to suppress findings. You can use wildcard .* to suppress all findings from the selected input type.
  • QueryString and Body: These will suppress findings from the entire QueryString and Body, respectively. The QueryString and Body may only be excluded in conjunction with the URL exclusion pattern defined below.

In conjunction with the input type, you must choose how to apply URLs:

  • All URLs: Findings using the specified input type and name will be suppressed regardless of where they’ve come from.

  • These URLs (allows regex): Specify a set of URLs to which to apply the exclusion.

Note: Slash followed by wildcard /.* is an acceptable substitute for listing all URLs.

Example Input Regular Expressions

Type Desired Effect Regular Expression Effect
Cookie Exclude cookies names starting with a value ^App Excludes all cookie names starting with App
Parameter Exclude parameter names ending with a value testing$ Excludes all parameter names ending with testing
Header Exclude explicitly named header ignore Excludes the header ignore only

See the table below for a Regular Expression Quick Reference.


This type of exclusion allows you to focus on a list of specific URLs to be ignored using These URLs. In this field, you can list the specific URLs to exclude, resulting in any findings from these URLs being suppressed.

Note: Slash followed by wildcard /.* is an acceptable substitute for listing all URLs.

Example URL Regular Expressions

Desired Effect Regular Expression Effect
Exclude all subpaths /myapp/.* Excludes all paths with the initial URL of /myapp/
Exclude one subpath explicitly ^/myapp/thispath$ Excludes only /myapp/thispath
Exclude path ending .*ignore$ Excludes all path ending in ignore
Exclude paths containing .*value.* Excludes all paths containing value
Exclude paths containing digits /myapp/\d+ Excludes all paths like /myapp/1234
Exclude paths containing non-digits /myapp/\D+ Excludes all paths like /myapp/word

See the table below for a Regular Expression Quick Reference.


Choosing Code (allows regex) will allow you to specify a list of method signatures. Any findings involving these methods will be suppressed. The entire method signature must be present and not include a trailing parameter definition or any other extra characters. For example:

  • If you have a method doLegacySecurity() inside a class called com.acme.OldSecurity that is being reported for using insecure cryptographic algorithms, you can ignore it by entering this line into the exclusion code block:

  • We’ll match this method signature against the stacktrace for any vulnerabilities found and suppress any that contain a match.

Create a New Exclusion

  1. From within the application to which you wish to apply a new exclusion, click on the Exclusions tab and select Add Exclusion.

    Note: You must have Admin or Rules Admin privileges in order to create exclusions.

  2. Enter the Exclusion Name. Use something you’ll remember easily.

  3. Select the Exclusion Type. (More fields will become available once you make your choice. Add the information that is necessary for each one.)
  4. Applicable Vulnerability Rules allows you to specify the scope of rules affected by the exclusion.

    • All Rules applies the exclusion to all vulnerabilities found in both Assess and Protect mode.
    • All Assessment Rules applies to all vulnerabilities found in Assess mode.
    • All Protection Rules applies to all attack events in Protect mode.

This can be narrowed down by selecting individual Assess or Protect rules. We’ll only apply the exclusion to vulnerabilities found by the selected rules in the corresponding mode.

Note: To help you understand what your exclusion will do, a summarized sentence is displayed at the bottom of the wizard.

Create a new exclusion from an existing attack event

When viewing the details of an existing attack event, an Add Exclusion button will appear in the top right hand corner of the Event tab. Selecting this button prepopulates the exclusion fields based on the details of this specific event. Once created, this exclusion is managed in the same way as if it were created manually.

Enable or Disable Exclusions

Each exclusion can be enabled or disabled for either Assess or Protect mode, depending on which rules are covered by the exclusion. From the Exclusions tab within an application overview, you can see a list of all existing exclusions for that application. These can be toggled on or off for both Assess and Protect.

Alternatively, you can see a global list of existing exclusions across all applications under Policy Management > Application Exclusions via the user menu. Each exclusion can also be edited and toggled off for each mode on this page.

Regular Expression Quick Reference

Effect Pattern Example Pattern Example Match
Start of a string ^ ^w+ Start of a string
End of a string $ w+$ End of a string
A single character of: a, b or c [abc] [abc]+ a bb ccc
A character except: a, b or c [^abc] [^abc]+ Anythingbutabc.
A character in the range: a-z [a-z] [a-z]+ Only a-z
A character not in the range: a-z [^a-z] [^a-z]+ Anything but a-z.
A character in the range of: a-z or A-Z [a-zA-Z] [a-zA-Z]+ abc123DEF
Any single character . .+ a b c
Any whitespace character \s \s any whitespace character
Any non-whitespace character \S \S+ any non-whitespace
Any digit \d \d not 1 not 2
Any non-digit \D \D+ not 1 not 2
Matcher either a or b (a|b) (a|b) beach
Zero or one of a a? ba? ba b a
Zero or more of a a* ba* a ba baa aaa ba b
One or more of a a+ a+ a aa aaa aaaa bab baab
Exactly 3 of a a{3} a{3} a aa aaa aaaa
3 or more of a a{3,} a{3,} a aa aaa aaaa aaaaaa
Between 3 and 6 of a a{3,6} a{3,6} a aa aaa aaaa aaaaaaaaaa

Compliance Policy

As your organization grows, let Contrast flag applications that no longer meet your security criteria.

How it Works

Administrators can define policies for application compliance within their organization based on Policy Criteria, including Assess Rules and vulnerability severity, and specific applications. If any designated applications violate this policy, Contrast marks them in the interface so you can quickly find them and fix them. (Administrators are notified of violations both in the product and by email.) Contrast also provides default policies based on standard security rules that your company may need to follow.

Set Up Policies

Go to the User menu > Policy Management > Compliance Policy tab to get started. Find current policies in the grid or enter a policy name in the search field above it.

Add policies

To add a new policy, click the Add policy button above the grid.

In the Add Compliance Policy form, enter a name for the policy and click in the multiselect fields to choose Policy Criteria and Applications. Select vulnerabilities by severity level(s), Security Standards and Assess Rules to include in the Policy Criteria. Select applications by level(s) of importance and individual name. Click the Add button to save the policy.

Edit policies

Click on a policy name in the Compliance Policy grid to edit your criteria. In the Edit Compliance Policy form, click in the multiselect fields to change your selections.

Note: The Name and Policy Criteria fields are locked for default policies. However, you can modify application selections by clicking in the field and then clicking the Save button.

To delete a policy, click the trashcan icon below the form or in the grid row. You can also enable or disable policies, including default policies, using the toggle in each grid row.

Filter applications by policy

In the Applications page, click the Advanced link to filter application by Compliance Policy. (This filter is only available when one or more policies are enabled, and only displays enabled policies.)

Policy Violations

If an applicable vulnerability isn't remediated, or applicable Security Standards and Assess Rules are being violated, Contrast flags the corresponding applications in the Applications page. Hover over the warning symbol in the Applications grid or go to the application's details page for a link to the violated policy.

Library Policy

As Contrast assesses your applications, it can also flag libraries that don't meet your organization's criteria to ensure your applications are secure.

How It Works

If a library is restricted or used in an application that's below a specific version, it's marked as a policy violation by Contrast. You can also tell Contrast to automatically grade any library that violates the policy with the letter "F" to flag it in the Contrast interface. (Administrators are notified of violations in both the product and by email.)

Set Up Policies

To set a library policy, go to the User menu > Policy Management > Library Policy tab.

Check the box to Restrict libraries and click on the multiselect field to choose which libraries you want to exclude from your portfolio. Check the box to Enable version requirements and click on the multiselect field to choose one or multiple libraries that must be within your given number of versions. Click the Add another requirement link to create version requirements for additional library groupings.

Fail libraries

By checking the box to Fail libraries in violation of policy, you allow Contrast to automatically assign a failing score to any library that violates a set policy. If a library fails to comply with a set policy, the name, a warning icon and the library grade are highlighted in red in the Libraries page. Hover over the icon or go the the library's details page for more information about the violation.

If you choose to automatically fail libraries, Contrast alerts you when adjusting Score Settings in the Organization Management page. To learn more about scoring libraries, go to the Score Settings article.

Remediation Policy

Create policies for vulnerabilities in your organization, and Contrast will clean up your view of security risks. As Contrast assesses your applications, it can either flag vulnerabilities that are in violation of the policy or automatically remediate them.

How It Works

Administrators can define requirements for vulnerability remediation based on any vulnerability type, severity and application(s) which should comply. Contrast then marks any vulnerabilities that are in violation or auto-remediated based on this policy with a notification in the interface. (Administrators are also notified of violations in the product and by email.)

Set Up Policies

Go to the User menu > Policy Management > Remediation Policy tab to create new policies and view existing ones in the grid.

Add policies

To create a new policy, click the Add Policy button. In the Add Remediation Policy form, choose a Name for the policy, and click in the multiselect fields to choose the Vulnerability Rules, Applications and Environments to which Contrast should apply the policy. You can add multiple vulnerabilities by Severity or select individual names. You can also add multiple applications by Importance or select individual names.

Automatic actions

In the Action section, use the radio buttons and corresponding number control fields to either flag vulnerabilities as a violation or automatically remediate them after a given number of days. If multiple policies affect the same vulnerability, the following rules determine Contrast's course of action:

  • The most severe action (i.e. the action with the closest deadline) applies first.
  • If a violation deadline applies first, the vulnerability is flagged and then auto-remediated when the later deadline applies.
  • If an auto-remediation deadline applies first, the vulnerability is closed and never flagged.

Note: If Contrast rediscovers a legitimate vulnerability that was auto-remediated, Contrast will report the vulnerability as usual.

Edit policies

Click the name of an existing policy in the grid to see more details and update your selections in the Edit Remediation Policy form. Click the trashcan icon below the form or in the grid to permanently delete the policy. Once deleted, Contrast won't notify you of vulnerabilities that were within the scope of this policy. You can also use the toggles in the grid to enable or disable individual policies.

Policy Violations and Remediations

If a vulnerability isn't remediated within the given number of days, Contrast adds a warning note to the Vulnerabilities thermometer in the dashboard and flags the vulnerabilities in the Vulnerabilities grid. Hover over the warning icon for each vulnerability in the grid, or go to the vulnerability details page for more information about the violation.

If a vulnerability has been auto-remediated, its status is updated to "Auto-Remediated" in the Vulnerabilities grids. Hover over the status text, or go the auto-generated comment in the vulnerability's Discussion tab for more information about the applicable policy.