API requests blocked (403 error)

Hi,
I’ve got a Cloudflare Worker that is doing api requests to Mautic.
Suddenly the api requests just started to get error 403 errors (Fetch failed with status 403 (Forbidden)). The DNS for my Mautic instance is managed in Cloudflare.

Root cause analysis:

  1. I send the same api requests from a Wordpress, with the same credentials and these ones are still working fine.
  2. I restored a backup of my Mautic instance from a date where the api requests from Cloudflare Worker were working fine. I still got the same error messages.

I suspect that Cloudflare DNS could block the API requests for security reason.
Or maybe the Mautic hosting service could block the API requests.

Any idea what could be the problem?
How can I solve it?

Thanks for helping.
Christian

Hi @christian.ritter.pro

Try to follow this guide:

You can search for a blocked or challenged request in the Security app under the Overview tab in the Firewall Events section of your Cloudflare Dashboard.

Understanding Cloudflare Firewall Analytics

The Cloudflare WAF contains mainly 2 packages:

  • Cloudflare Managed Ruleset: These rules are managed by Cloudflare WAF Engineers.
  • OWASP ModSecurity Core Rule Set: These rules are not managed by Cloudflare. They are created by the OWASP Group and Cloudflare integrates with this OWASP package as part of our WAF for additional security.

For “security reasons”, we don’t provide the rule patterns, as this would increase the likelihood that a malicious party could learn to bypass the rules. However, If you would like to know why a WAF rule has triggered, you can enable the payload logging feature. This feature is only available for customers on an Enterprise plan. It allows you to log the request information that triggered a specific rule of a Managed Ruleset. This information is known as the payload. Payload logging is especially useful when diagnosing the behavior of WAF rules. Since the values that triggered a rule may contain sensitive data, they are encrypted with a customer-provided public key so that only you can examine them later.

If you’re encountering false positive due to the legacy WAF, there are 5 actions that you could take here:

  1. Add the IP(s) doing the request to the IP Access Rules in the allowlist, if the users connecting to your backend are always using the same IP address.
    This is the best solution as it does not affect the site security.
    How do I control IP access to my site?

  2. Disable the affected WAF rule(s)
    This will reduce the security of the site, but will stop the requests from getting blocked/challenged.
    How do I configure the WAF?

  3. Skip the WAF with a Firewall Rule
    You can create a Firewall Rule with the skip action for the WAF to be deactivated for a specific combination of parameters. You could for example only bypass the WAF for a specific URL and a specific IP or user-agent:
    Firewall rules actions · Cloudflare Firewall Rules (deprecated) docs

  4. Disable the Web Application Firewall from the requested endpoint (not recommended!)
    This will result in lower security, as the WAF will no longer be applicable on that location.
    This action is done by using Page Rules:
    Understanding and Configuring Cloudflare Page Rules (Page Rules Tutorial)

  5. If the rule blocking is 981176 (legacy OWASP), it means it was blocked by the OWASP rules. You need then to decrease the OWASP sensitivity: a request was blocked by rule 981176, what does that mean?. If decreasing the OWASP sensitivity doesn’t solve the issue, you might need to apply one of the other actions described above (1, 2, 3 or 4).

If you’re encountering false positive due to the new WAF, there are two actions that you could take here:

  1. Add WAF Exception
    You can define WAF exceptions in the Cloudflare dashboard or using the Rulesets API.

  2. If the rule blocking is 949110 (new OWASP), it means it was blocked by the OWASP rules. You need then to decrease the OWASP Anomaly Score Threshold or lower the OWASP Paranoia Level.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.