Adjust `limit` Parameter

[dkoeni]

Right now, the limit parameter type is defined by an int32. This allows to request up to 2^32 list entries which are way more than would ever exist for a single user (e.g. payments of last year). This potentially inserts a security flaw like Heartbleed, if the API's backend is not able to handle that big numbers. To avoid this (theoretic) risk one could strip this parameter to a usable max value. For example, the limit parameter could be extended by a maximum: 1000 value, which prevents this kind of attack. The specific usable value, that is aligned to everyday use case, needs to be discussed with @SIX and other TPPs.

[dkoeni]

This discussion should be extended to the whole paging mechanism, because the right now implemented paging mechanism may not cover all use cases since it is not flexible enough.

As an idea the paging can be implemented similarly to the approach of the OpenWealth: Cursors at Slack: https://slack.engineering/evolving-api-pagination-at-slack/

[juergen-petry]

Feedback on behalf of UBS: If reliable, realistic values can be provided for the minimum and the maximum, then they should be specified for a matter of principle. However, we don’t see a concrete added value in terms of security.

[svenbiellmann]

We will need to define a procedure for how we deal with backlog items in general.