Guides
Sign Up
Start typing to search…

Flow deployments on Cloudflare (Beta)

Deploy Fingerprint identification and protection to the edge without touching your application's code.

🚧

Feature in Beta

This feature is currently in an open Beta testing phase. We recommend testing it inside an isolated staging environment. All feedback is welcome! If you encounter any issues, please contact our support team.

Pre-requisites

  • A Fingerprint account with an Admin role.
  • A website proxied (not DNS-only) through Cloudflare.

Flow is a no-code Fingerprint deployment method, currently supported for websites hosted on Cloudflare.

The Flow worker sits between the browser accessing your website and the origin server. It automatically handles all the steps required to identify visitors on your website and protect sensitive actions:

  • It injects the JavaScript agent into the pages you define.
  • For the API endpoints you define, it triggers visitor identification. Optionally, it can protect those endpoints using the Rules engine.
  • Requests are naturally same-site, no need for a separate proxy integration to deal with ad blockers.

For a more detailed conceptual overview, see How Cloudflare Flow deployments work.

There are two ways to use Flow workers:

Using a Flow worker with the Rules Engine

The Rules Engine allows you to define rules evaluated against the Fingerprint identification events. For example, you can define a ruleset that prevents browsers in incognito mode from creating accounts in your application. See Rules engine for more details.

One way of using the ruleset is by deploying it using a Flow worker. For example, you can protect the POST api.yourwebsite.com/create-account API, called from the yourwebsite.com/signup page.

Quick note: You cannot protect the signup page itself, only the API endpoint it calls. Calling the protected API endpoint from the identification page is necessary to trigger visitor identification.

  1. Open your ruleset and switch to the Settings tab.
  2. Under Deployment, click Deploy with Cloudflare.
  3. Enter your Cloudflare Account ID, your Cloudflare Token, and click Validate.
    1. You can get your Cloudflare Account ID from the Cloudflare Dashboard -> Workers and Pages, on the bottom right corner of the page.
    2. You need to get or create a Cloudflare token with the following permissions:

      1. Account:Workers Scripts:Edit

      2. Zone:Workers Routes:Edit for the zone the worker will use

      3. Zone:DNS:Read for the zone you want to deploy to

  4. Pick the environment of the Public and Secret API keys generated for the deployment.
  5. Define at least one page for identifying visitors. For example, to identify visitors on your sign-up page, add:
    1. [no subdomain]
    2. yourwebsite.com
    3. /signup
  6. Define at least one API endpoint to protect with your ruleset. These protected APIs need to be called from the pages in the last step. They can be on a different subdomain, but must be inside the same zone. See How Cloudflare Flow deployments work for more details. For example, to protect the sign-up endpoint, add:
    1. api.
    2. yourwebsite.com
    3. POST
    4. /create-account.
  7. Define the Failure mode. By default, the worker will Fail open, meaning it will let requests through if an unexpected identification error occurs. We recommend starting with this configuration for the initial testing, then switching to Fail closed for security use cases.
  8. Click Create Cloudflare worker.

Within a few seconds, the Flow worker is deployed into your Cloudflare account.

  • You can open your Cloudflare dashboard to confirm.
  • You can navigate to the identification page in Incognito mode and try triggering the protected API. You will be blocked by the ruleset and receive the response you defined in your rule action.
🚧

Note: The Flow worker will start intercepting protected requests and applying rules immediately after deployment. If the failure mode is set to Fail closed, any errors in the request instrumentation (e.g., missing or corrupted browser data) will be treated as tampering attempts and blocked with a 403 Error response from the Flow worker.

  • We recommend testing your ruleset and Flow deployment in a separate staging environment before applying it to production.
  • You can deploy the Flow worker set to Fail open for the initial test of your configuration.
  • You can deploy an empty or disabled ruleset first to test the Flow worker without applying any rules.
  • You can delete the Flow deployment at any time using the Fingerprint Dashboard, or even manually remove the worker from your Cloudflare dashboard if needed.

Editing Flow deployments

You can update your Flow deployment any time:

  1. Navigate to <Your ruleset> > Settings tab.
  2. Under Deployment, click ⋯ (More actions), then Edit worker.
  3. Add, remove, or update the identification pages and protected APIs.
  4. Click Save and redeploy to save your changes.

This redeploys the Flow worker with the updated configuration. Do not make manual changes to the worker code or environment variables directly through Cloudflare as they will be overwritten by Fingerprint on the next redeployment.

📘

Rules are part of the Ruleset, not the Flow deployment

  • The Flow worker only knows its Ruleset ID. Rulesets are stored and evaluated inside the Fingerprint platform, not on Cloudflare.
  • To update rules, make changes to the Ruleset and save it. It might take up to 60 seconds for the changes to take effect on your website.
  • We recommend testing your rule changes in a separate staging ruleset and staging web environment before applying them to production.

Deleting Flow deployment

To delete the Flow deployment:

  1. Navigate to <Your ruleset> > Settings tab.
  2. Under Deployment, click ⋯ (More actions), then Delete worker.
  3. Confirm by typing your domain name and clicking Delete deployment.

This completely removes the Flow worker and its associated routes from your Cloudflare account. The ruleset itself remains stored in your Fingerprint workspace. Note that you cannot delete a deployed ruleset without removing the Flow deployment first.

Using a Flow worker on its own (Monitoring mode)

You can deploy a Flow worker without a ruleset. This allows you to identify visitors on your website and collect data about your traffic without applying any protective actions.

To deploy a Flow worker in monitoring mode:

  1. In the Fingerprint Dashboard, navigate to Libraries & integrations -> Cloudflare No-Code Worker.
  2. Click New worker.
  3. Provide your Cloudflare credentials, define the Identification pages and API endpoints.
    1. It works the same as when using Flow with the Rules engine; see that section above for more details. The only difference is that there is no ruleset associated with the Flow worker.
    2. Note that you still need to define the API endpoints even if you are not using any ruleset. The identification page calling the API endpoint is what triggers visitor identification and sends the data to the worker, even if no protection is applied.
    3. In Monitoring mode, we recommend keeping the Failure mode set to Fail open to let requests through if an unexpected identification error occurs.
  4. Click Create Cloudflare worker to deploy.

You can switch to the Workers tab to see all your workers, whether they are using rulesets or not.

Clicking on a worker opens the worker detail, where you can view, manage, or delete the worker.


How Cloudflare Flow deployments work

Cloudflare Flow allows you to integrate Fingerprint protection into your website without touching your application's code. It replaces the need to install the JavaScript agent on your website, set up a proxy to avoid ad-blockers, integrate Fingerprint Server API into your backend, and write custom protection logic based on Fingerprint results.

📘

Importantly, Cloudflare Flow deployment is different from the Cloudflare Proxy Integration, which only proxies requests between your website and Fingerprint when integrating Fingerprint manually.

Here is how it works in detail:

  • Using your Cloudflare API token and credentials, Fingerprint deploys a Cloudflare worker on your domain, which intercepts HTTP requests between browsers accessing your website and the origin server.
  • When serving the pages that identify visitors (for example, yourwebsite.com/signup page), the worker injects the Fingerprint JavaScript agent and an instrumentation script into the page markup.
    • Fingerprint creates a Public API key and a Secret API key used only by the Flow worker and the injected JavaScript agent.
  • For HTTP requests to APIs you want to protect (for example, the POST api.yourwebsite.com/create-account request), the instrumentation script collects information about the browser configuration and attaches it to the request as a custom header, fp-data.
  • The Flow worker intercepts the protected request and sends the browser information to the Fingerprint Identification API. If the worker is using a ruleset, the request also includes the ruleset ID.
  • In return, the worker receives the full identification event and (if applicable) the rule action produced by evaluating your ruleset.
  • If using a ruleset, the Flow worker processes the rule action by blocking the protected request or allowing it to reach the origin server.
  • The Flow worker code is open-sourced on GitHub.

Route pattern matching

The identification pages and protected APIs are converted to Cloudflare worker route patterns and follow the same format and matching behavior.

  • Each Cloudflare route can only be served by one Cloudflare worker. If you try to use a route pattern already served by another worker, your deployment will fail.
  • You can use a wildcard (*) at the end of the path but not in the middle of it.
  • Using a wildcard suffix (/path*) is required to match requests with query parameters like path?query=value.

Note: You might encounter edge cases where Cloudflare caching interacts with wildcard route matching in a way that produces unexpected behavior. In that case, do not hesitate to contact our support team. Defensively using both the base and wildcard variants of the path (path and path*) can help.

Current limitations

  • You can only protect API calls (actions, transactions) made by the visitor on the identification page. You cannot protect the page itself.
    • For example, you cannot block bots from visiting the sign-up page, but you can block the create-account API call made by the page if the bot clicks "Create account".
  • You can define a maximum of 10 identification pages and 10 protected APIs per Flow deployment.
  • You must define at least one identification page and one API endpoint per Flow deployment, even if you are using the worker in Monitoring mode. The identification page calling the API endpoint is what triggers visitor identification.
  • Customizations of the JavaScript agent behavior, such as tags, linked IDs, custom timeout, etc., are not supported at this time.
  • At the moment, you cannot rotate the Public and Secret API keys used by the worker. The secret API key is encrypted in both the Fingerprint and Cloudflare dashboards, so exposing it is unlikely. If you need to replace either key anyway, you need to delete your Flow deployment and recreate it. Alternatively, you can contact our support team for assistance.

Troubleshooting

If you encounter any issues with your Flow deployment, you can:

  • Use the Fingerprint Dashboard > Identification page to confirm that Flow deployment is generating identification events as expected. Note that any Smart Signals not enabled for your workspace will always evaluate to false.

  • Hard reload the identification page of your website to ensure you are getting the latest version from the Flow worker. Look for instrumentor.iife.js in the Network tab of your browser's developer tools to confirm.

  • Make sure the protected API is actually called from the identification page you defined. Use the browser's developer tools to confirm that the fp-data header is being attached to the request.

  • Navigate to your Cloudflare dashboard to confirm the worker configuration matches your Flow deployment (worker code, environment variables, routes, etc.).

  • Enable Worker logs and examine them for errors. Any error returned from the Fingerprint Identification API will only be visible here, not propagated to your application.

  • Most common errors include Request filtering blocking identification requests by origin.

  • Contact our support team. Include relevant logs or screenshots of the above to aid troubleshooting.


Updated about 10 hours ago