Cloudflare Block for Incoming Webhooks - Edge Functions

[pedrohssales]

Describe the bug

I am encountering an Access Denied (403) error when my Supabase Edge Function named asaas_webhook attempts to receive payment webhooks. The error message indicates that access is being restricted by Cloudflare based on the browser's signature.

To Reproduce

Steps to reproduce the behavior:

Steps to reproduce the behavior:

1. Create an account at Asaas Sandbox.
2. Create a generic Edge Function in Supabase to handle payment webhooks.
3. Navigate to "Integrações" > "Webhooks" > "Cobranças" in the Asaas dashboard.
4. Insert the endpoint URL of the Supabase Edge Function into the webhook configuration.
5. Trigger a payment event in Asaas to send a webhook to the Edge Function's endpoint.
6. Observe the Access Denied (403) error in the response.

Expected behavior

I expect the Edge Function to successfully receive and process the payment webhook data without encountering an Access Denied error.

Screenshots

Null

System information

• OS: Windows

Additional context

Asaas has indicated that the Cloudflare configuration of Supabase might be blocking the IPs of their service. The list of IPs mentioned are: 52.67.12.206, 18.230.8.159, 54.94.136.112, 54.94.183.101, 54.207.175.46, 54.94.35.137.

The webhooks do not even appear in the log of the Edge Function, which indicates that they are being blocked by the Cloudflare of Supabase. Additionally, I have tested sending the Asaas webhook to various other services such as Make and Zapier, and the webhook arrives normally in those cases. The issue only occurs with Supabase.

This Cloudflare block is a known issue. Asaas suggests that the IPs mentioned above should be unblocked in the Cloudflare WAF settings. (https://docs.asaas.com/docs/bloqueio-do-firewall-na-cloudflare)

As an additional measure, the error message I received indicated that access was being restricted based on the browser's signature. I suspect this might be related to the User-Agent: Java/1.8.0_275 header that Asaas uses when sending webhooks. If possible, adjusting the filter for this User-Agent in Cloudflare's security settings could potentially resolve the problem.

This problem is critical as it prevents my application from receiving and processing payment webhooks, which is essential for its functionality.

[mztmoraes]

@pedrohssales , Hi!

Did you manage to get around the limitation (apparently a bug) of supabase? Did you actually manage to integrate supabase with Asaas?

Best

[danielkv]

I'm having the same problem! @pedrohssales did you manage to make it work?

[danielkv]

I'm still with this issue. @kiwicopple @awalias we need help with this. It doesn't look something to serious, pls give us at least a direction.

[pedrohssales]

@mztmoraes @danielkv

The Supabase team has not returned any solution to me so far. But, I found out that the problem is in the header User-Agent: Java/1.8.0_275

The supabase firewall (cloudflare) is blocking requests with this type of user-agent.

What I did, while there is no solution:

1. I created a "middle of the road".
2. I used the hookdeck platform (hookdeck.com) to create an endpoint and receive the asaas webhooks, then I used the hookdeck transform tool to change the User-Agent: Java/1.8.0_275 header to User-Agent: Custom-User-Agent/1.0

Now, then, I retransmitted the webhooks, already with the treatment in the User-Agent header, to Supabase, it seems that I achieved a successful "bypass", and the firewall does not block my webooks.

Hope this helps while Supabase doesn't deploy a solution.

[mztmoraes]

@pedrohssales , thanks.

In fact, supabase returned this information to me:

"The issue is that this provider is blocked by Cloudflare which we also use for DNS provider. Our team is very strict with security and they won't allow to whitelist a range of IP addresses.

If Stripe was getting banned by Cloudflare, then it would be the same situation. But with stripe, Cloudflare is happy to pass their webhooks along. Maybe this is something for your provider to reach out to Cloudflare about it."

So I decided to use N8N to solve this problem and not wait for a resolution from either side, neither supabase or asaas. Lack of interest, to say the least. It's not possible that they don't know how to solve this!

[TechAppSystem]

Guys, all blz, I can solve this block if anyone needs it! My payment application connected to Asaas is 100%, if anyone still has this block call me on telegram and I will solve it for you! Telegram @TechAppSystem

NOTE: Before some curious people like some came looking for me, I inform you that I charge fees for resolution!

There are some guys that I won't mention names that come looking for me to solve for free and still judge me thinking I'm interested in data from his server lol. Detail, I didn't request any data from him and he was already judging hahaha!

[iveshenry18]

I believe I am getting a similar false-positive 403 from an opaque Cloudflare security layer, happening when I try to upload images to either Supabase Edge Functions or Supabase Storage.

Since this technically doesn't have to do with the open-source libraries but rather has to do with the specific configuration of the paid Supabase service, I have submitted a support request to Supabase and am awaiting their response.

I will share updates and may open issues in the storage and edge function repos if necessary.

Here's the description of the issue I sent to Supabase support.

TLDR: When uploading images to an Edge Function (as multipart/form-data) or Storage (using supabase.storage.from(...).upload(...)), I am getting a 403 with an HTML response from Cloudflare, likely due to a false-positive spam filter.

~~~ I have implemented an image moderation server that accepts a multipart/form-data request with an image to upload, detects explicit content in the image, and then uploads it to Supabase Storage if the image is safe.

I first implemented this using Hono running in a Supabase Edge Function and got it working locally using the Supabase CLI. However, when I deployed the edge function to production and tested it, the request I sent from the client (a React Native app) returned a 403, with an HTML response from Cloudflare describing that the request had been blocked by their security service (attached). The request did not appear in my Edge Function logs or invocations, telling me the request was blocked before it got to the Edge Function runtime.

Since I don't seem to have any visibility or control over the Cloudflare layer of my Supabase deployment, I decided to abandon Supabase Edge Functions. I ported my server code to a Cloudflare Worker, made sure it was working locally (using a local Cloudflare Worker sending data to my local Supabase container), and deployed that to production. Now, my client is able to send the image to the Cloudflare Worker, and the Cloudflare Worker is able to receive data from my Supabase backend, but when the Cloudflare Worker tries to upload the image to Supabase Storage (using supabase.storage.from(...).upload(...)), I get the same Cloudflare 403 response with the same HTML response. Same as before, the request doesn't show up in Supabase Storage logs, telling me the request is being blocked before it gets to the Supabase layer.

I have tried to modify the headers, including changing the User-Agent to something generic. I have also tried different image sizes. Again, both versions were working locally, so the issue seems to have to do with the specific deployment of the Supabase service. It is somewhat fruitless to debug this further, as the layer where the issue is happening is opaque to me. Let me know if there is a way to access this Cloudflare configuration, or if there is another workaround. Thanks!

[pmadalozzo]

Existe uma forma simples de resolver esse problema... basta utilizar um webhook em php por exemplo para fazer o repasse do json. O problema esta no Asaas com o Supabase.