In which layer request parameter limit should be for an external endpoint?

Question

I have a batch endpoint of the form

POST /entities
["id1", "id2", ...]

Where the endpoint takes an array of ids and returns a batch response.

Now I want to set a maximum value to number of the entities to prevent service from processing huge requests. But I am not sure if this belongs to the controller or service layer. When I say controller layer I mean the part where it handles request/protocol related logic and service layer handles the business logic.

Which place this limiting belongs?

Answer 1

There isn't a singular spot where you guard against large requests. Broadly speaking, there are a few kinds of attacks your system needs to guard against:

1. Sending HTTP requests with a large amount of data.
2. Sending HTTP requests that are a reasonable size, but cause too much processing on the server.
3. Sending a large number of reasonably sized requests that, individually, aren't too much to process, but together can overwhelm the system.

All of these cases would be classified as a Denial-of-Service attack.

By the time your controller or programming framework starts to execute, you've already fallen victim to attack #1 and #3. Your program has no means to mitigate this. Instead, your web server should have a configuration setting allowing you to specify the max size for the request body. This helps guard against attack #1.

Guarding against attack #2 involves inspecting the request body, which means you need to parse this data. Parsing this data takes memory and CPU resources, so you want to set the max request size small enough that you can still parse the max size without the server slowing down. Once the request body has been parsed into something usable, you need another check to ensure the client has not exceeded some maximum number of records in the batch. Typically this check goes in the controller, service layer, or validation layer.

The last attack to mitigate is #3, which can also be the most difficult one. In this scenario the attacker sends reasonably sized requests, which might even be semantically correct. The number of requests is so large that the system bogs down. This is where rate limiting your API becomes valuable. Rate limiting is typically enforced as a server configuration, load balancer configuration, or the API gateway for micro services environments.

Your question is a good example of how a single problem in cyber security can have many facets. A successful solution will need to address many ways that an attacker can bring your system down. Solutions will not exist in one spot within your application architecture. Multiple layers are vulnerable in different ways, requiring their own unique strategies.

• Greg Burghardt: I may have given a broader answer than the OP was asking for, but this problem is bigger, and much more complicated than simply limiting the batch size.
• Aiono: Thanks for the detailed context I didn't think that much about it. My question specifically about #2. You say it goes to controller, service or validation layer. Do you think any one of them is more appropriate then the others? Or it doesn't matter where it's put?
• Greg Burghardt: @f.smith: no single place is better than the other. This sort of limit is use case specific, so don't feel like you need to place this logic where it is easy to reuse. Keep it simple at first.

Answer 2

But I am not sure if this belongs to the controller or service layer

Both and none. This value (limit) sounds like a configuration to me. In other words, a cross-cutting concern.

For simplicity, let's assume this value won't change in the runtime. So it's static and loaded only once. If that were the case, both service and controller will be created (hopefully only once) with this value already set.

The service sizes the pool, queue, stack, etc, accordingly. The controller compares the size of the input with this limit.

The same parameter is involved in two different "logics", validation and load management.