Using Cloudflare with your API

Cloudflare offers many security features to help defend against attacks. Some of these features are designed to limit access from potentially harmful visitors to your domain by either adding an interstitial delay to the request or by requiring the request to be made from a web browser.

As requests to an API are typically made outside of a browser, we advise creating a page rule for your API's URL pattern to ensure that these features do not limit access to your API.

Please keep in mind that disabling or lowering security features does provide a potential attacker with a less secure location where they might attack the domain if the origin for the API is the normal website's origin.

The first step is to set the URL pattern to encompass all requests to your API. For example, if your API functions similarly to the Cloudflare v4 API, all requests are made to one URL (https://www.cloudflare.com/api_json.html) so this is the URL needed for the pattern. If your API uses multiple URLs, you can use an asterisk (*) as a wildcard character to have the pattern match multiple URLs. For example, requests to Zendesk's v2 API begin with https://{subdomain}.zendesk.com/api/v2/ where a wildcard can be used for both the subdomain and the files requested after /v2/, like: https://*.zendesk.com/api/v2/* .

The second step is to configure Cloudflare's features to minimize any impact on the API.

  • Since each request and response can be expected to be different, setting the caching level to bypass cache prevents any responses returned to the visitor from being cached.
  • Always Online is a feature that returns cached content when the origin appears offline. Disabling Always Online for the API rule ensures that responses aren't served from Cloudflare's cache.
  • Disabling SmartErrors for API calls ensures that if a HTTP 404 response is returned from the origin, a 200 isn't seen with relevant search results instead.
  • The Security setting controls our web application firewall (WAF) which is available to domains with a paid subscription. It is possible that some calls to the API could trigger rules in the WAF and result in either blocked or challenged requests. We recommend leaving the WAF enabled, at least initially, to see if these requests are triggering WAF rules. You're able to see which rules are triggered and which visitors had an action applied to them by the WAF by visiting the WAF settings and events pages here: https://www.cloudflare.com/waf-settings?z=example.com , replacing example.com with your root level domain.
    If you find that requests to the API are being caught by the WAF, you can either disable the individual rule or rules on the WAF settings page that are capturing API requests, or you can disable the WAF entirely for the API by disabling this option in the page rules interface. It is important to note that disabling rules in the WAF settings is applied to the entire domain, not just the API URL pattern.
  • The Security level controls Cloudflare's basic protection level for the URL pattern. When this feature is set to "I'm Under Attack" either in the Cloudflare settings or in a page rule, each visitor is presented with an interstitial page with a 5 second delay before the request is redirected to its destination. We advise specifying this to anything but "I'm Under Attack" so that there is never a delay applied to API requests.
  • Browser Integrity Check looks for common HTTP headers abused most commonly by spammers and denies access to the visitor. Since API calls made programmatically typically do not specify the same headers a web browser does, we recommend disabling the browser integrity check for the API URL pattern so that calls made outside of a browser are not blocked.
Still not finding what you need?

The CloudFlare team is here to help. 95% of questions can be answered using the search tool, but if you can’t find what you need, submit a support request.

Powered by Zendesk