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.

Restrict Licenses

Check the Restrict licenses box to set a policy on open source licenses that you want to restrict. If an open source license is restricted, then any libraries that use the restricted license will be marked as a policy violation by Contrast.

The license policy lists open source licenses in SPDX format, listed by short identifier and followed by the full name. Any license type that you want to restrict must be selected. Contrast includes any ‘or later’ licenses it identifies in your portfolio. For example, if you restrict by GPL-3.0-only, any licenses that are GPL-3.0-or-later will be included in that restriction.

License policy is available to OSS customers only. Contact your Organization Admin to enable OSS.

Library Compliance Failure

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.

Vulnerability Management

Note: This Vulnerability Management page consolidates the information regarding the Vulnerability Behavior section, which was previously included as part of the Applications Settings page. Additionally, the Remediation Policy page no longer exists and has been replaced by this page.

Control how remediation happens. Define if vulnerabilities of a certain severity require approval to have their statuses change, or if you’d rather Contrast close them automatically for you. Go to the User menu > Policy Management > Vulnerability Management to get started.

Vulnerability Behavior

Check the box to Require administrative approval when closing vulnerabilities in your organization. In the fields below, choose the statuses and severities of vulnerabilities that should automatically go into a Pending state when a user moves to close them. When a user requests to close any qualifying vulnerabilities, Contrast will notify you that your review is needed.

Note: To qualify for administrative approval, both a status and severity that you select in this configuration must apply to the vulnerability being closed.

Each vulnerability status will remain pending until you submit your review of the closure. If you deny the closure of a vulnerability, you must provide a reason for denial. Once confirmed, your feedback appears in the vulnerability's Discussion tab. If you disable the feature, any pending closures are automatically approved.

Note: While in a Pending state, the vulnerability's previous status still applies for the purpose of organizational reports and statistics.

See Manage Vulnerabilities for more information about Pending states and workflows.

Vulnerability 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 mark them Remediated - Auto-Verified.

How It Works

Administrators can define requirements for vulnerability remediation based on any vulnerability rule, severity, application(s) and route which should comply. Contrast then marks any vulnerabilities that are in violation or Remediated - Auto-Verified 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 > Vulnerability Management tab to create new policies and view existing ones in the tabbed grid. Auto-Verification policies will automatically change the status of vulnerability to Remediated - Auto-Verified. Violation policies will mark a vulnerability as being in violation of a policy. Either can be created to be triggered based on time or route.

Add Policies

To create a new policy, select the grid tab for the type of policy desired and click the Add Policy button. In the Add Remediation Policy form, define 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 rules. You can also add multiple applications by importance or select individual names.


In the Triggers section, use the checkboxes to select the time-based and/or route-based trigger. If a time-based trigger is selected, also input the number of days after which the trigger should fire.

Note: When using a policy with a route-based trigger, it is recommended to also use define a time-based trigger to account for those vulnerabilities which have been remediated in such a way that cannot be associated back to the original finding in Contrast. Typically, these cases only arise when the code was deleted, and therefore cannot be re-exercised, or redefined such that it occurs on a different route.

If multiple policies affect the same vulnerability, the following rules determine Contrast's course of action:

  • Between two time-based triggers, the action with the closest deadline applies first. For example, if a violation deadline applies first, the vulnerability is flagged and then auto-verified when the later deadline applies.
  • Auto-verification policies take precedence over violation policies. For example, if an auto-verification deadline applies first, the vulnerability is closed and never flagged.

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

Edit Policies

Click the name of an existing policy in the grid to see its detail view and update it. Click the trashcan icon 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, if you’d like to re-use the policy again later.

Policy Violations and Auto-Verifications

If a Violation policy has been triggered, Contrast adds a warning note to the Vulnerabilities thermometer in the dashboard and flags the associated 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 an Auto-Verification policy has been triggered, its status is updated to Remediated - Auto-Verified 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.

Sensitive Data Masking

Take advantage of Contrast's data masking feature to limit risk to your organization and meet compliance requirements.

How It Works

Contrast's data masking feature protects sensitive data in your applications by redacting it in Contrast vulnerability and attack reports that are sent to the Contrast UI, syslog or security log.

Sensitive data masking is part of policy management by default for organizations with at least one active Assess or Protect license. Contrast offers several categories of sensitive data, or data types, that are comprised of specific keywords that the agent automatically identifies and redacts in reports. Org Admins and Rules Admins can manage data types in the Contrast UI.

Agent identification and masking

Contrast agents mask sensitive data in query parameters, request headers, cookies and body. Your agent identifies sensitive data by searching for specific keywords used in the input name. If the agent finds a match, it redacts the value for that input, and replaces it with a placeholder with the format contrast-redacted-{datatype}, where datatype is the category of sensitive data to which the keyword belongs.

Contrast agents do not mask individual fields in request bodies with a content type other than application/x-www-form-urlencoded; however, you can configure the agent to mask the entire request body. Contrast agents also do not mask data that appears in the data flow portion of a vulnerability report, if using Assess, or in the vector of an attack event, if using Protect.

Note: Contrast agents make a “best effort” attempt to avoid printing sensitive data in Contrast log statements; however, it’s possible that sensitive data could appear in the Contrast log, if the log level is set to DEBUG or lower. Whenever possible, you should avoid setting production systems to log at DEBUG or lower. If a system that deals with sensitive data is set to log at DEBUG or lower, you should take steps to ensure that those logs are not being sent to an external system to avoid leaking any sensitive data.


The following sample HTTP request sent by an agent as part of a vulnerability report shows two inputs that the agent identified as sensitive as well as the placeholders it used to mask the values of the input before sending the report to the Contrast UI, syslog server or security log.

PUT /employee/5 HTTP/1.1 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 30 
apikey: contrast-redacted-authentication-info 


In this case, the header value is masked because "apikey" matches a keyword in the "Authentication Info" data type, and the form parameter is redacted because "ssn" matches a keyword in the "Government ID" data type for your Contrast organization. (Keyword matches are case insensitive.)

Manage Sensitive Data Types

Go to the user menu > Policy Management > Sensitive Data tab to view and edit the sensitive data types for your organization. In the Sensitive Data grid, data types and associated keywords are listed alphabetically. To quickly find data types by name or keywords, use the search field above the grid.

To enable redaction of the entire HTTP request body, check the box to Mask entire body. This will apply to all applications in your organization.

Critical data types and keywords determined by Contrast apply to all applications in your organization by default, and can't be edited or disabled. For data types that Contrast has not determined to be critical, you may use the toggle in the grid to enable or disable them for the organization.

Edit data types

Click on the name of the data type in the grid to add custom keywords. In the Edit Sensitive Data Type form, use the Custom Keywords field to add more keywords and specify the applications to which they apply. Default Keywords aren't editable, and apply to all applications.