Add SpeedCurve to your WAF or bot manager allowlist

If you are experiencing issues with your website blocking traffic from SpeedCurve, you may need to configure your firewall (WAF) or bot manager (Akamai, CloudFlare, etc) to allow our servers to reach your site

Customers often use one of the following ways to allow SpeedCurve traffic through their WAF / Bot Manager:

• User Agent sniffing
• Custom HTTP Header
• Custom Cookie

User Agent String

Configuring a WAF to allow our agent access via user-agent sniffing is the simplest way to allow SpeedCurve traffic.

To identify us our agent includes PTST/SpeedCurve in the user agent string

Instructions for CloudFlare

1. Log into your CloudFlare dashboard and navigate to the WAF page under the Security section.
2. Click on Create firewall rule.
3. Set the rule name to SpeedCurve.
4. For the incoming request match rule, set the field to User Agent and the Operator to contains. Set the value to PTST/SpeedCurve.
5. Set the action to Allow.

6. Click on Deploy firewall rule.

Instructions for all other WAF & bot manager providers

Most firewall and bot manager providers have a facility to allow traffic based on user-agent. You should configure the allowlist of your firewall or bot manager provider to allow traffic where the User-Agent header contains PTST/SpeedCurve.

The following links may be useful:

• AWS WAF: Creating a web ACL

Custom HTTP Header

Each URL being tested can have a script associated with it, and within these scripts it's possible to set a custom HTTP header.

For example, the following script sets a header with the name of name and the value of value, and then it loads the URL that's configured for the test:

setHeader	name:value	%ORIGIN%/*
navigate	%URL%

name and value should be swapped for a header name and value that can be configured in your WAF

To restrict which requests a header applies to setHeader supports a URL Pattern filter.

In the above example, is the page being tested is https://example.com then %ORIGIN%/* will be replaced by https://example.com/* when the script runs

setHeader can also be used without a URL Pattern but this means the header is applied to all requests and this may lead to some CORS requests failing.

Custom Cookie

Cookies are safe header from a CORS perspective so some customers use one as the token for their WAF

For example, this script sets a cookie on the origin of the page being tested with the name of name and the value of value, it then loads the URL that's configured for the text:

setCookie	%ORIGIN%	name=value
navigate	%URL