Leaked credentials detection

The leaked credentials traffic detection scans incoming requests for credentials (usernames and passwords) previously leaked from data breaches .

When you turn on leaked credentials detection, Cloudflare scans incoming HTTP requests for usernames and passwords. The scan checks authentication patterns from common web applications and any custom detection locations you configure.

Detected credentials are compared against a database of known leaked credentials. This database consists of:

• The Have I Been Pwned (HIBP) matched passwords dataset (passwords only)
• Cloudflare-collected credentials (usernames)
• Leaked credentials pairs (username and password)

Based on the results, Cloudflare populates leaked credentials fields for scanned requests. You can use these fields in two ways:

• Analyze traffic: Review detection results in the Security Analytics dashboard to understand how often leaked credentials appear in your traffic.
• Create rules: Use the fields in custom rules or rate limiting rules to challenge or block requests that contain compromised credentials.

Leaked credentials can appear in your traffic for different reasons. An attacker may be performing a credential stuffing attack, or a legitimate user may be reusing a previously leaked password.

Leaked credentials detection provides a managed transform that adds an Exposed-Credential-Check request header to matching requests. The header value indicates what was leaked for example, 1 if both username and password were a leaked pair, 2 if the username was leaked, or 4 if only the password was leaked.

You can use this header at your origin server to warn users and prompt them to reset their password.

For details on available features per plan, refer to Availability in the traffic detections page.

Leaked credentials detection includes rules for identifying credentials in HTTP requests for the following well-known web applications:

• Drupal
• Joomla
• Ghost
• Magento
• Plone
• WordPress
• Microsoft Exchange OWA

Additionally, the scan includes generic rules for other common web authentication patterns.

You can also configure custom detection locations to address the specific authentication mechanism used in your web applications. A custom detection location tells the Cloudflare WAF where to find usernames and passwords in HTTP requests of your web application.

The default scan covers common web applications, but your application may send credentials in a different format or field name. Custom detection locations allow you to tell Cloudflare exactly where to find usernames and passwords in HTTP requests.

For example, if the JSON body of an HTTP request authenticating a user looks like the following:

{ "user": "<username>", "secret": "<password>" }

You could configure a custom detection location with the following settings:

• Custom location for username:
  lookup_json_string(http.request.body.raw, "user")
• Custom location for password:
  lookup_json_string(http.request.body.raw, "secret")

When specifying a custom detection location, only the location of the username field is required.

The following table includes example detection locations for different request types:

Expressions used to specify custom detection locations can include the following fields and functions:

• Fields:
  • http.request.body.form
  • http.request.body.multipart
  • http.request.body.raw
  • http.request.headers
  • http.request.uri.args
  • http.request.uri.query
• Functions:
  • lookup_json_string()
  • url_decode()

For instructions on configuring a custom detection location, refer to Get started.

The following fields indicate the type of leaked credential match Cloudflare detected. Use these fields in custom rules or rate limiting rules to act on requests containing compromised credentials.