DoS protection in appfarm for app (not services)

Hi
Is there any built in protection against DoS attack against for a public app that allows unauthenticated users to create objects?
Due to a significant difference in performance I would like a few object classes to be allowed for create and update by the unauthenticated user role, but then it could open up for a DoS attack by allowing an attacker to fill up the database with those objects. Is it possible to avoid this without using a service with rate limiting?

The objects are not containing sensitive information of any kind and what I would like was some kind of built in rate limiting for the app itself and not only on the services. Implementing as a service gives a significantly more sluggish feeling as compared to persisting objects in the app directly.

I understand it could possibly be solved by using runtime objects and reference data sources but that also means changes are not persisted underway.

Thanks,

You have some device information like Client IP and Device OS in App Variables.
You could probably make some logic that checks how many times an IP address and device have attempted to Create Objects in the database.

Rate Limiting in Services essentially does the same thing by checking how many requests an IP address is making to your endpoint.

// Erik

Hi
I´m afraid I don´t understand your suggestion. The check/enforcement would have to be server side since the attacker would bypass any logic on the client. Or could you explain how to implement your suggestion if I misunderstood what you meant?

Thanks

Maybe I misunderstood your question?

If I understood correctly, you want to protect your unauthenticated app against bots from spamming your database.

While we dont have any serverside rate limiting for apps, I believe you can create this logic yourself. You could possibly keep track of IP-addresses that access your app and database in a log. Before the IP address is allowed to do database operations, you can check how many times they have attempted to access the database, before deciding if they should have access or not.

You would have to model this logging and checking yourself however, as we do not have built-in support for this.

Did I understand the question correctly :slightly_smiling_face:

// Erik