Customize "Under Attack Mode" HTTP status code...?

#1

Question: Is it possible for us to customize the HTTP status code of the “under attack” browser validation screen? Eg: Change it from 503, to say, 504, or 520.

I know this may seem completely random, but here’s some background as to why…

We operate a system in which we want to run “under attack mode” constantly to force browser validation and keep the CloudFlare on as aggressive of a security stance as possible (fintech). Our current “API Gateway” throws 503 errors whenever its unable to communicate with upstream services. We’d like to begin using service workers, and/or to allow our Ajax calls to detect when the browser needs revalidation. Currently, whenever our front-end detects a 503 we can’t tell if it’s from you, or from our API Gateway, so we currently just trigger a full page browser reload when this occurs. This has the negative side-effect of if one of our backend services are down, instead of handling this gracefully on our frontend we currently infinite loop page reload.

Our current solutions involve one of three things, from easiest to hardest.

1: Ask you if you can customize (for us) the HTTP response code, eg: change it to 504.
2: Dig into the ajax library we’re using to try to detect the 503 in our frontend to distinguish it from our 503s. We’ve tried this briefly and been unable to succeed, but may need more effort.
3: Modify the source code of our api gateway to throw a different response code, eg: 504

Related: https://support.cloudflare.com/hc/en-us/articles/115003011431/

#2

I really doubt it’s possible to do, I would recommend a different approach. For APIs the best option is to use Rate-Limiting. The Under-Attack mode requires a full browser. I would split the API path from the main path and separate the protection type.

#3

We also heavily use rate limiting in addition to having the full browser validation from under attack mode. Our industry tolerates this extra time as a layer of protection and its acceptable, but we need to be able to detect this.

Secondarily, what you suggest splitting the API path from the main path and separating the protection type doesn’t work, because if our API path is behind a “under attack” browser validation and our actual frontend isn’t, then the browser never gets to go to the browser validation page, our frontend only makes API calls that 503 constantly.

Unless you know of some way that this could work differently?

#4

You could detect it by matching the response text. Search for the ray-id of the request, for example.

I would have proposed the opposite, frontend under attack mode, API rate limiting.

#5

We are investigating doing this, the library we use is only returning us the status code at this time, but we are investigating…

When we tried this approach we were hit by numerous DDOS attacks against our API, API rate limiting only applies per source-IP. We had 10’s of thousands of IPs hitting us in slow enough fashion to completely evade CloudFlare’s rate limiting and it avoided their “normal” DDoS detection. I spoke to CloudFlare support and they confirmed we needed to under attack our API. Only when we enabled the “under attack” for our API did it begin to actually detect and block these DDoS attacks. Fun times. :stuck_out_tongue:

#6

I see, that could be a problem, but there are a ton of alternatives.

Well, that is a problem, I seriously don’t know how to do anything. The solution would be changing the library at this point.

closed #7

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