2

I'm working with a basic REST API, through user interaction on the UI, the JSON object is built up, including Arrays and a POST is sent to an endpoint using this object as the request body. For example:

"data": {
    "id": "424",
    "types": [ "01", "02" ]
}

So this data object is part of the body that will be sent to the endpoint. My concern relates to the types array. My understanding is that it should realistically never exceed five items. In which case, should we add validation to reject when it's over five elements? Or perhaps accept and just throw away anything over the five elements?

My concern is this being used as an attack vector or at least as a nuisance. I wonder if limiting this is safer or given REST request size limits, should we just leave it as it is?

Improve this question
4
  • 1
    It's not an attack vector unless you have a vulnerability in your software or the software is compelled to process the entire JSON object. Limiting its size seems to me like a reasonable validation step if you know it should never be larger than a certain size. There's no limit to the size of a POST request body; it's defined by your implementation. See stackoverflow.com/questions/1495541/rest-payload-max-size
    – Robert Harvey
    May 11, 2022 at 21:18
  • Are you going to read the entire array before checking whether it's longer than 5 items?
    – user253751
    May 12, 2022 at 10:01
  • @RobertHarvey Typically you only process any JSON if the whole document is valid, so you need to read the whole document.
    – gnasher729
    May 13, 2022 at 11:24
  • @gnasher729: I meant something like "Post request body shall never exceed 5K in size." You're not obliged to process a document you don't accept.
    – Robert Harvey
    May 13, 2022 at 12:45

2 Answers 2

Reset to default
3

The size of a posted JSON array is unlikely to be the thing that causes issues by itself, because reading and parsing of json objects, regardless of size, in almost any language is essentially a solved problem with very very well tested implementations

You may run into issues, however, if the size of the array you receive leads to the response time and memory usage of your api growing much faster than the size of the request. In such a case it may make sense to limit the number of elements in the array that are allowed to be processed - eg, if you somewhere use an algorithm that performs n^2 to the size of that array in memory or time, this could cause problems.

You may also wish to limit requests if you are running in a tightly constrained environment, such as using serverless functions, where you set the amount of memory and execution time available, and cannot exceed that amount, or if you are using an api proxy / load balancer that itself has a request or response size limit and you need to make sure that you stay within those bounds.

If you know, for an absolute fact, that the array should never contain more than 5 elements (or any other number) then it would make sense to limit the size. But if it is because most people shouldn't require larger requests in most cases, that is usually not a good reason to limit requests (either by throwing an error or only processing the first X number of elements) because there will exist people who have less than common use-cases

Improve this answer
2

Don't set limits without it being forced.

Check what happens with 10,000 items in the array. If your app crashes, fix the crash and try again. If it becomes slow - just because YOU think there should be only five items, your users might find a use for an array with hundreds of items. Disabling that for no good reason is not nice. The user would rather have five hundred slow items than a hard limit. If it gets too slow, you will get complaints, then you fix it.

(From personal experience, some array in software I worked on never had more than 500 items. So my test code checked that it worked with 2,000. A year later, a customer told us that they needed 250,000 items in that array).

Improve this answer
1
  • I agree with what you're saying completely. In the scenario above, this doesn't come from the user, it is built via our JS based on user input which is limited. I've only seen data for two elements thus far, I cannot fathom five even being possible. However as you say, this could change in future. However, we'd be aware of that up front. My concern is someone using dev tools to then change that array considerably and potentially impact performance etc
    – shicky
    May 17, 2022 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.